㈠ 對稱密鑰加密技術的工作流程
SQL Server 2005一個令人激動的特性是內置了加密的功能。在這個新版的SQL Server中，開發團隊直接在T-SQL中加入了加密工具、證書創建和密鑰管理的功能。對於因為法律要求或商業需求而需要加密表中的數據的人來說，這是一個好禮物。對於猶豫是否用加密來保證數據安全的人來說，做決定也更容易了。這篇文章介紹新的加密功能是怎麼工作，怎麼使用。
TSQL現在支持使用對稱密鑰和非對稱密鑰，證書和密碼。本文介紹如何創建、管理和使用對稱密鑰和證書。
根據涉及的內容，我決定把本文分為三節：
第一部分：服務主密鑰和資料庫主密鑰
第二部分：證書
第三部分：對稱密鑰
1. 服務主密鑰和資料庫主密鑰
圖：SQL Server 2005加密層次結構
1.1 服務主密鑰
當第一次需要使用服務主密鑰對鏈接伺服器密碼、憑據或資料庫主密鑰進行加密時，便會自動生成服務主密鑰。服務主密鑰為 SQL Server 加密層次結構的根。服務主密鑰直接或間接地保護樹中的所有其他密鑰和機密內容。使用本地計算機密鑰和 Windows 數據保護 API 對服務主密鑰進行加密。該 API 使用從 SQL Server 服務帳戶的 Windows 憑據中派生出來的密鑰。
因為服務主密鑰是自動生成且由系統管理的，它只需要很少的管理。服務主密鑰可以通過BACKUP SERVICE MASTER KEY語句來備份，格式為：
BACKUP SERVICE MASTER KEY TO FILE = 'path_to_file' ENCRYPTION BY PASSWORD = 'password'
'path_to_file' 指定要將服務主密鑰導出到的文件的完整路徑（包括文件名）。此路徑可以是本地路徑，也可以是網路位置的 UNC 路徑。
'password' 用於對備份文件中的服務主密鑰進行加密的密碼。此密碼應通過復雜性檢查。
應當對服務主密鑰進行備份，並將其存儲在另外一個單獨的安全位置。創建該備份應該是首先在伺服器中執行的管理操作之一。
如果需要從備份文件中恢復服務主密鑰，使用RESTORE SERVICE MASTER KEY語句。
RESTORE SERVICE MASTER KEY FROM FILE = 'path_to_file'
DECRYPTION BY PASSWORD = 'password' [FORCE]
'path_to_file' 指定存儲服務主密鑰的完整路徑（包括文件名）。path_to_file 可以是本地路徑，也可以是網路位置的 UNC 路徑。
PASSWORD = 'password' 指定對從文件中導入的服務主密鑰進行解密時所需的密碼。
FORCE 即使存在數據丟失的風險，也要強制替換服務主密鑰。
註：如果你在使用RESTORE SERVICE MASTER KEY時不得不使用FORCE選項，你可能會遇到部分或全部加密數據丟失的情況。
如果你的服務主密鑰泄露了，或者你想更改SQL Server服務帳戶，你可以通過ALTERSERVICE MASTER KEY語句重新生成或者恢復服務主密鑰。它的用法請參考聯機叢書。
因為服務主密鑰是SQL Server自動生成的，所以，它沒有對應的CREATE和DROP語句。
1.2 資料庫主密鑰
正如每個SQL Server有一個服務主密鑰，每個資料庫有自己的資料庫主密鑰。資料庫主密鑰通過CREATE MASTER KEY語句生成：
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password'
這個語句創建資料庫主密鑰，使用指定的密碼加密它，並保存在資料庫中。同時，資料庫主密鑰也被使用服務主密鑰加密之後保存在master資料庫中，這就是所謂的「自動密鑰管理」。這個特性我們待會再講。
象服務主密鑰一樣，你可以備份和恢復資料庫主密鑰。使用BACKUP MASTER KEY備份資料庫主密鑰。語法類似於備份服務主密鑰：
BACKUP MASTER KEY TO FILE = 'path_to_file'
ENCRYPTION BY PASSWORD = 'password'
恢復資料庫主密鑰使用RESTORE MASTER KEY語句，它需要使用DECRYPTION BY PASSWORD子句提供備份時指定的加密密碼，還要使用ENCRYPTION BY PASSWORD子句，SQL Server使用它提供的密碼來加密資料庫主密鑰之後保存在資料庫中。
RESTORE MASTER KEY FROM FILE = 'path_to_file'
DECRYPTION BY PASSWORD = 'password'
ENCRYPTION BY PASSWORD = 'password'
[ FORCE ]
同樣，FORCE表示你將忽略在解密過程中的錯誤。
建議你在創建了資料庫主密鑰之後立即備份資料庫主密鑰，並把它保存到一個安全的地方。同樣，使用FORCE語句可能導致已加密數據的丟失。
要刪除資料庫主密鑰，使用DROP MASTER KEY語句，它刪除當前資料庫的主密鑰。在執行之前，確定你在正確的資料庫上下文中。
1.3 自動密鑰管理
當創建資料庫主密鑰時，它被使用提供的密碼加密然後被保存到當前資料庫中。同時，它被使用服務主密鑰加密並保存到master資料庫中。這份保存的資料庫主密鑰允許伺服器在需要的時候解密資料庫主密鑰，這就是自動密鑰管理。沒有自動密鑰管理的話，你必須在每次使用證書或密鑰加密或解密數據（它需要使用資料庫主密鑰）時使用OPEN MASTER KEY語句同時提供加密的密碼。使用自動密鑰管理，你不需要執行OPEN MASTER KEY語句，也不需要提供密碼。
自動密鑰管理的缺點就是每個sysadmin角色的成員都能夠解密資料庫主密鑰。你可以通過ALTER MASTER KEY語句的DROP ENCRYPTION BY SERVICE MASTER KEY子句，從而不使用自動密鑰管理。ALTER MASTER KEY的使用方法參見聯機叢書。
㈡ 加密技術
對稱加密就是指，加密和解密使用同一個密鑰的加密方式。需要用到的有加密演算法和加密秘鑰。例如加密演算法可以類似這樣的加密規則(a ->b，b->w，c->a)
發送方使用密鑰將明文數據加密成密文，然後發送出去，接收方收到密文後，使用同一個密鑰將密文解密成明文讀取。
優點：加密計算量小、速度快，效率高，適合對大量數據進行加密的場景。
缺點：（1）密鑰不適合在網上傳輸（容易被截取），（2）密鑰維護麻煩
DES 、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES。
數據加密標准DES屬於常規密鑰密碼體制，是一種分組密碼。加密前，先對整個明文進行分組，每一組長為64位，然後對每一個64位二進制數據進行加密處理，產生一組64位密文數據。最後將各組密文串接起來，即得出整個的密文。使用的密鑰為64位（實際密鑰長度為56位，有8位用於奇偶檢驗）
DES的保密性取決於密鑰的保密，而演算法是公開的。盡管人們在破譯DES方面取得了許多進展，但至今仍未能找到比窮舉搜索密鑰更有效的方法。DES是世界上第一個公認的實用密碼演算法標准，它曾對密碼學的發展做出了重大貢獻。目前較為嚴重的問題是DES的密鑰長度，現在已經設計出搜索DES密鑰的專用晶元。
DES演算法安全性取決於密鑰長度，56位密鑰破解需要3.5到21分鍾，128位密鑰破解需要5.4 * 10^18次方年
注意的是：這里是沒有密鑰的情況下，直接窮舉密鑰嘗試破解。如果密鑰在傳送過程中被人截取了，就相當於直接知道加密規則了，根本不需要破解，因此密鑰在網路中傳送還是不安全。
與對稱加密演算法不同，非對稱加密演算法需要密鑰對，即兩個密鑰：公開密鑰（公鑰）和私有密鑰（私鑰）。
公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種演算法叫作非對稱加密演算法。
公鑰和私鑰是怎麼來的？
操作系統隨機生成一個隨機數，將這個隨機數通過某個函數進行運算，分成兩部分，公鑰和私鑰
優點：安全性高
缺點：加密與解密速度慢。
RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）。
答案是不能
鑒於非對稱加密的機制，我們可能會有這種思路：伺服器先把公鑰直接明文傳輸給瀏覽器，之後瀏覽器向伺服器傳數據前都先用這個公鑰加密好再傳，這條數據的安全似乎可以保障了！ 因為只有伺服器有相應的私鑰能解開這條數據 。
然而 由伺服器到瀏覽器的這條路怎麼保障安全？ 如果伺服器用它的的私鑰加密數據傳給瀏覽器，那麼瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，這個公鑰被誰劫持到的話，他也能用該公鑰解密伺服器傳來的信息了。所以 目前似乎只能保證由瀏覽器向伺服器傳輸數據時的安全性 （其實仍有漏洞，下文會說）。
1、先通過非對稱加密技術，把對稱加密的密鑰X傳給對方，使得這個對稱加密的密鑰X是安全的
2、後面再通過對稱加密技術進行數據傳輸
詳細流程
（1）伺服器端擁有用於非對稱加密的 公鑰A 、 私鑰A』 。
（2）客戶端向網站伺服器請求，伺服器先把 公鑰A 明文給傳輸瀏客戶端
（3）客戶端隨機生成一個用於對稱加密的 密鑰X ，用 公鑰A 加密後傳給伺服器端。
（4）伺服器端拿到後用 私鑰A』 解密得到 密鑰X 。
（5）這樣雙方就都擁有 密鑰X 了，且別人無法知道它。之後雙方所有數據都用 密鑰X 加密解密。
數字簽名是基於公鑰密碼體制（非對稱密鑰密碼體制）的。
數字簽名必須保證以下三點：
上圖位用戶A使用數字簽名向用戶B傳輸一份文件的過程：
什麼時候使用這種不對文件加密，而對文件的摘要加密（對文件進行簽名）的技術呢？
注意： 這里強調的是只有「A公鑰」 上有認證機構CA的數字簽名，意思是CA用它的私鑰對「A公鑰」的內容進行單向散列函數得到的 加密摘要（數字簽名） ，該簽名放在「A公鑰」中（左上角那個），對於B用戶來說，它從可靠的路徑拿到CA的公鑰，使用CA的公鑰解密「A公鑰」的內容得到的128位的摘要 和 「A公鑰」的內容通過單向散列函數計算出來的是否一致，如果是表示認可這個「A公鑰」
當用戶A遺失或泄露了CA頒發的證書後，為了避免他人使用該證書冒充用戶A，用戶A向認證機構CA "掛失" 該證書。於是認證機構CA把該證書放入該認證機構的證書吊銷列表（CRL）中，並在網上公示。
用戶B在收到用戶A的公鑰時，除了要驗證該公鑰是否位認證機構頒發的，還要登錄認證機構的網站查看該公鑰是否已被認證機構吊銷變為無效證書。
認證機構CA的作用：
1、http連接很簡單，是無狀態的，明文傳輸。https協議 = http協議 + SSL，可以進行加密傳輸，身份認證
2、http連接的是80埠，https連接的是443埠
3、https協議需要伺服器端到CA申請SSL證書，即客戶端請求的時候，伺服器端發送SSL證書給客戶端，SSL證書內容包括公鑰、CA機構的數字簽名。驗證了伺服器端的身份以及公鑰的可靠性。 （注意：混合加密那裡「將公鑰A給客戶端」，嚴格的來說是把SSL證書給客戶端）
SSL提供以下三個功能
1、 SSL伺服器鑒別。允許用戶證實伺服器的身份。 具有SSL功能的瀏覽器維持一個表，上面有一些可信賴的認證中心CA和它們的公鑰
2、 SSL客戶鑒別。允許伺服器證實客戶的身份。
3、 加密的SSL會話，通過混合加密實現的 。客戶和伺服器交互的所有數據都是發送方加密，接受方解密
SSL的位置
（1）方法：get，post，head，put，delete，option，trace，connect
（2）URL欄位
（3）HTTP協議版本
User-Agent：產生請求的瀏覽器類型
Aceept：客戶端可識別的內容類型列表
Host：主機地址
200：請求被成功處理
301：永久性重定向
302：臨時性重定向
403：沒有訪問許可權
404：沒有對應資源
500：伺服器錯誤
503：伺服器停機
HTTP協議的底層使用TCP協議，所以HTTP協議的長連接和短連接在本質上是TCP層的長連接和短連接。由於TCP建立連接、維護連接、釋放連接都是要消耗一定的資源，浪費一定的時間。所對於伺服器來說，頻繁的請求釋放連接會浪費大量的時間，長時間維護太多的連接的話又需要消耗資源。所以長連接和短連接並不存在優劣之分，只是適用的場合不同而已。長連接和短連接分別有如下優點和缺點：
注意： 從HTTP/1.1版本起，默認使用長連接用以保持連接特性。 使用長連接的HTTP協議，會在響應消息報文段加入: Connection: keep-alive。TCP中也有keep alive，但是TCP中的keep alive只是探測TCP連接是否活著，而HTTP中的keep-alive是讓一個TCP連接獲得更久一點。
㈢ 數據加密原理是什麼 數據解密原理介紹【詳解】
數據加密和解密,數據加密和解密原理是什麼?
隨著Internet 的普及,大量的數據、文件在Internet 傳送,因此在客觀上就需要一種強有力的安全措施來保護機密數據不被竊取或篡改。我們有幾種方法來加密數據流。所有這些方法都可以用軟體很容易的實現,但是當我們只知道密文的時候,是不容易破譯這些加密演算法的(當同時有原文和密文時,破譯加密演算法雖然也不是很容易,但已經是可能的了) 。最好的加密演算法對系統性能幾乎沒有影響,並且還可以帶來其他內在的優點。例如,大家都知道的pkzip ,它既壓縮數據又加密數據。又如,dbms 的一些軟體包總是包含一些加密方法以使復制文件這一功能對一些敏感數據是無效的,或者需要用戶的密碼。所有這些加判啟悔密演算法都要有高效的加密和解密能力。幸運的是,在所有的加密演算法中最簡單的一種就是“置換表”演算法,這種演算法也能很好達到加密的需要。每一個數據段(總是一個位元組) 對應著“置換表”中的一個偏移量,偏移量所對應的值就輸出成為加密後的文件。加密程序和解密程序都需要一個這樣的“置換表”。事實上,80x86 cpu 系列就有一個指令‘xlat’在硬體級來完成這樣的工作。這種加密演算法比較簡單,加密解密速度都很快,但是一旦這個“置換表”被對方獲得,那這個加密方案就完全被識破了。更進一步講,這種加密演算法對於黑客破譯來講是相當直接的,只要找到一個“置換表”就可以了。對這種“置換表”方式的一個改進就是使用2 個或者更多的“置換表”,這些表都是基於數據流中位元組的位置的,或者基於數據流本身。這時,破譯變的更加困難,因為黑客必須正確的做幾旁皮次變換。通過使用更多的“置換表”,並且按偽隨機的方式使用每個表,這種改進的加密方法已經變的很難破譯。比如,我們可以對所有的偶數位置的數據使用a 表,對所有的奇數位置使用b 表,即使黑客獲得了明文和密文,他想破譯這個加密方案也是非常困難的,除非黑客確切的知道用了兩張表。與使用“置換表”相類似“, 變換數據位置”也在計算機加密中使用。但是,這需要更多的執行時間。從輸入中讀入明文放到一個buffer 中,再在buffer 中對他們重排序,然後按這個順序再輸出。解密程序按相反的順序還原數據。這種方法總是和一些別的加密演算法混合使用,這就使得破譯變的特別的困難,幾乎有些不可能了。例如,有這樣一個詞,變換起字母的順序,slient 可以變為listen ,但所有的字母都沒有變化,沒有增加也沒有減少,但是字母之間的順序已經變化了。但是,還有一種更好的加密演算法,只有計算機可以做,就是字/ 位元組循環移位和xor 操作。如果我們把一個字或位元組在一個數據流內做循環移位,使用多個或變化的方向(左移或右移) ,就可以迅速的產生一個加密的數據流。這種方法是很好的,破譯它就更加困難! 而且,更進一步的是,如果再使用xor操作,按位做異或操作,就就使破譯密碼更加困難了。如果再使用偽隨機的方法,這涉及到要產生一系列的數字,我們可以使用fibbonaci 數列。對數列所產生的數做模運算(例如模3) ,得到一個結果,然後循環移位這個結果的次數,將使破譯次密碼變的幾乎不可能! 但是,使用fibbonaci 數列這種偽隨機的掘正方式所產生的密碼對我們的解密程序來講是非常容易的。在一些情況下,我們想能夠知道數據是否已經被篡改了或被破壞了,這時就需要產生一些校驗碼,並且把這些校驗碼插入到數據流中。這樣做對數據的防偽與程序本身都是有好處的。但是感染計算機程序的病毒才不會在意這些數據或程序是否加過密,是否有數字簽名。所以,加密程序在每次load 到內存要開始執行時,都要檢查一下本身是否被病毒感染,對與需要加、解密的文件都要做這種檢查! 很自然,這樣一種方法體制應該保密的,因為病毒程序的編寫者將會利用這些來破壞別人的程序或數據。因此,在一些反病毒或殺病毒軟體中一定要使用加密技術。
循環冗餘校驗是一種典型的校驗數據的方法。對於每一個數據塊,它使用位循環移位和xor 操作來產生一個16 位或32 位的校驗和,這使得丟失一位或兩個位的錯誤一定會導致校驗和出錯。這種方式很久以來就應用於文件的傳輸,例如xmodem - crc。這是方法已經成為標准,而且有詳細的文檔。但是,基於標准crc 演算法的一種修改演算法對於發現加密數據塊中的錯誤和文件是否被病毒感染是很有效的。
一個好的加密演算法的重要特點之一是具有這種能力:可以指定一個密碼或密鑰,並用它來加密明文,不同的密碼或密鑰產生不同的密文。這又分為兩種方式:對稱密鑰演算法和非對稱密鑰演算法。所謂對稱密鑰演算法就是加密解密都使用相同的密鑰,非對稱密鑰演算法就是加密解密使用不同的密鑰。非常著名的pgp公鑰加密以及rsa 加密方法都是非對稱加密演算法。加密密鑰,即公鑰,與解密密鑰,即私鑰,是非常的不同的。從數學理論上講,幾乎沒有真正不可逆的演算法存在。例如,對於一個輸入‘a’執行一個操作得到結果‘b’,那麼我們可以基於‘b’,做一個相對應的操作,導出輸入‘a’。在一些情況下,對於每一種操作,我們可以得到一個確定的值,或者該操作沒有定義(比如,除數為0) 。對於一個沒有定義的操作來講,基於加密演算法,可以成功地防止把一個公鑰變換成為私鑰。因此,要想破譯非對稱加密演算法,找到那個唯一的密鑰,唯一的方法只能是反復的試驗,而這需要大量的處理時間。
rsa 加密演算法使用了兩個非常大的素數來產生公鑰和私鑰。即使從一個公鑰中通過因數分解可以得到私鑰,但這個運算所包含的計算量是非常巨大的,以至於在現實上是不可行的。加密演算法本身也是很慢的,這使得使用rsa 演算法加密大量的數據變的有些不可行。這就使得一些現實中加密演算法都基於rsa 加密演算法。pgp 演算法(以及大多數基於rsa 演算法的加密方法) 使用公鑰來加密一個對稱加密演算法的密鑰,然後再利用一個快速的對稱加密演算法來加密數據。這個對稱演算法的密鑰是隨機產生的,是保密的,因此,得到這個密鑰的唯一方法就是使用私鑰來解密。
我們舉一個例子: 假定現在要加密一些數據使用密鑰‘12345’。利用rsa 公鑰,使用rsa 演算法加密這個密鑰‘12345’,並把它放在要加密的數據的前面(可能後面跟著一個分割符或文件長度,以區分數據和密鑰) ,然後,使用對稱加密演算法加密正文,使用的密鑰就是‘12345’。當對方收到時,解密程序找到加密過的密鑰,並利用rsa 私鑰解密出來,然後再確定出數據的開始位置,利用密鑰‘12345’來解密數據。這樣就使得一個可靠的經過高效加密的數據安全地傳輸和解密。但並不是經過加密的數據就是絕對安全的,數據加密是肯定可以被破解的,但我們所想要的是一個特定時期的安全,也就是說,密文的破解應該是足夠的困難,在現實上是不可能的,尤其是短時間內。
㈣ 密碼技術（十一）之密鑰
——秘密的精華
在使用對稱密碼、公鑰密碼、消息認證碼、數字簽名等密碼技術使用，都需要一個稱為 密鑰 的巨大數字。然而，數字本身的大小並不重要，重要的是 密鑰空間的大小 ，也就是可能出現的密鑰的總數量，因為密鑰空間越大，進行暴力破解就越困難。密鑰空間的大小是由 密鑰長度 決定的。
對稱密碼DES的密鑰的實質長度為56比特（7個位元組）。
例如，
一個DES密鑰用二進制可以表示為：
01010001 11101100 01001011 00010010 00111101 01000010 00000011
用十六進制則可以表示為：
51 EC 4B 12 3D 42 03
而用十進制則可以表示為：
2305928028626269955
在對稱密碼三重DES中，包括使用兩個DES密鑰的DES-EDE2和使用三個DES密鑰的DES-EDE3這兩種方式。
DES-EDE2的密鑰長度實質長度為112比特（14位元組），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F
DES-EDE3的密鑰的實質長度為168比特（21位元組），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
對稱密碼AES的密鑰長度可以從128、192和256比特中進行選擇，當密鑰長度為256比特時，比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
B9 42 DC FD A0 AE F4 5D 60 51 F1
密鑰和明文是等價的 。假設明文具有100萬的價值，那麼用來加密這段明文的密鑰也就是具有100萬元的價值；如果明文值1億元，密鑰也就值1億元；如果明文的內容是生死攸關的，那麼密鑰也同樣是生死攸關的。
在對稱密碼中，加密和解密使用同一個密鑰。由於發送者和接收者需要共享密鑰，因此對稱密碼又稱為共享密鑰密碼。對稱密碼中所使用的密鑰必須對發送者和接收者以外的人保密，否則第三方就能夠解密了。
在消息認證碼中，發送者和接收者使用共享的密鑰來進行認證。消息認證碼只能由持有合法密鑰的人計算出來。將消息認證碼附加在通信報文後面，就可以識別通信內容是否被篡改或偽裝，由於「持有合法的密鑰」就是發送者和接收者合法身份的證明，因此消息認證碼的密鑰必須對發送者以外的人保密，否則就會產生篡改和偽裝的風險。
在數字簽名中，簽名生成和驗證使用不同的密鑰，只有持有私鑰的本人才能夠生成簽名，但由於驗證簽名使用的是公鑰，因此任何人都能夠驗證簽名。
對稱密碼和公鑰密碼的密鑰都是用於確保機密性的密鑰。如果不知道用於解密的合法密鑰，就無法得知明文的內容。
相對地，消息認證碼和數字簽名所使用的密鑰，則是用於認證的密鑰。如果不知道合法的密鑰，就無法篡改數據，也無法偽裝本人的身份。
當我們訪問以https://開頭的網頁時，Web伺服器和瀏覽器之間會進行基於SSL/TLS的加密通信。在這樣的通信中所使用的密鑰是僅限於本次通信的一次密鑰，下次通信時就不能使用了，想這樣每次通信只能使用一次的密鑰稱為 會話密鑰 。
由於會話密鑰只在本次通信中有效，萬一竊聽者獲取了本次通信的會話密鑰，也只能破譯本次通信的內容。
雖然每次通信都會更換會話密鑰，但如果用來生成密鑰的偽隨機數生成器品質不好，竊聽者就有可能預測出下次生成會話密鑰，這樣就會產生通信內容被破譯的風險。
相對於每次通信更換的會話密鑰，一直被重復使用的密鑰稱為 主密鑰 。
一般來說，加密的對象是用戶直接使用的信息，這樣的情況下所使用的密鑰稱為CEK(Contents Encryting Key，內容加密密鑰)；相對地，用於加密密鑰的密鑰則稱為KEK（Key Encryting Key，密鑰加密密鑰）。
在很多情況下，之前提到的會話密鑰都是被作為CEK使用的，而主密鑰則是被作為KEK使用的。
生成密鑰的最好方法就是使用隨機數，因為米喲啊需要具備不易被他人推測的性質。在可能的情況下最好使用能夠生成密碼學上的隨機數的硬體設備，但一般我們都是使用偽隨機數生成器這一專門為密碼學用途設計的軟體。
在生成密鑰時，不能自己隨便寫出一些像「3F 23 52 28 E3....」這樣的數字。因為盡管你想生成的是隨機的數字，但無論如何都無法避免人為偏差，而這就會成為攻擊者的目標。
盡管生成偽隨機數的演算法有很多種，但密碼學用途偽隨機生成器必須是專門針對密碼學用途而設計的。例如，有一些偽隨機數生成器可以用於游戲和模擬演算法，盡管這些偽隨機數生成器所生成的數列看起也是隨機的，但只要不是專門為密碼學用途設計的，就不能用來生成密鑰，因為這些偽隨機數生成器不具備不可預測性這一性質。
有時候我們也會使用人類的可以記住的口令（pasword或passphrase）來生成密鑰。口令指的是一種由多個單片語成的較長的password。
嚴格來說，我們很少直接使用口令來作為密鑰使用，一般都是將口令輸入單向散列函數，然後將得到的散列值作為密鑰使用。
在使用口令生成密鑰時，為了防止字典攻擊，需要在口令上附加一串稱為鹽（salt）的隨機數，然後在將其輸入單向散列函數。這種方法稱為「基於口令的密碼（Password Based Encryption，PBE）」。
在使用對稱密碼時，如何在發送者和接收者之間共享密鑰是一個重要的問題，要解決密鑰配送問題，可以採用事先共享密鑰，使用密鑰分配中心，使用公鑰密碼等方法，除了上述方法，之前還提到一種解決密鑰配送的問題的方法稱為Diffie-Hellman密鑰交換。
有一種提供通信機密性的技術稱為 密鑰更新 （key updating），這種方法就是在使用共享密鑰進行通信的過程中，定期更改密鑰。當然，發送者和接收者必須同時用同樣的方法來改變密鑰才行。
在更新密鑰時，發送者和接收者使用單向散列函數計算當前密鑰的散列值，並將這個散列值用作新的密鑰。簡單說，就是 用當前密鑰散列值作為下一個密鑰 。
我們假設在通信過程中的某個時間點上，密鑰被竊聽者獲取了，那麼竊聽者就可以用這個密鑰將之後的通信內容全部解密。但是，竊聽者卻無法解密更新密鑰這個時間點之前的內容，因為這需要用單向散列函數的輸出反算出單向散列函數的輸入。由於單向散列函數具有單向性，因此就保證了這樣的反算是非常困難的。
這種防止破譯過去的通信內容機制，稱為 後向安全 （backward security）。
由於會話密鑰在通信過程中僅限於一次，因此我們不需要保存這種秘密。然而，當密鑰需要重復使用時，就必須要考慮保存密鑰的問題了。
人類是 無法記住具有實用長度的密鑰 的。例如，像下面這樣一個AES的128比特的密鑰，一般人是很難記住的。
51 EC 4B 12 3D 42 03 30 04 DB 98 95 93 3F 24 9F
就算勉強記住了，也只過不是記住一個密鑰而已。但如果要記住多個像這樣的密鑰並且保證不忘記，實際上是非常困難的。
我們記不住密鑰，但如果將密鑰保存下來又可能會被竊取。這真是一個頭疼的問題。這個問題很難得到徹底解決，但我們可以考慮一些合理的解決方法。
將密鑰保存生文件，並將這個文件保存在保險櫃等安全地方。但是放在保險櫃里的話，出門就無法使用了。這種情況，出門時就需要隨身攜帶密鑰。而如果將密鑰放在存儲卡隨身攜帶的話，就會產生存儲卡丟失、被盜等風險。
萬一密鑰被盜，為了能夠讓攻擊者花更多的時間才能真正使用這個密鑰，我們可以使用將密鑰加密後保存的方法，當然，要將密鑰加密，必須需要另一個密鑰。像這樣用於密碼加密的密鑰，一般稱為KEK。
對密鑰進行加密的方法雖然沒有完全解決機密性的問題，但在現實中卻是一個非常有效地方法，因為這樣做可以減少需要保管密鑰的數量。
假設計算機上有100萬個文件，分別使用不同的密鑰進行加密生成100萬個密文，結果我們手上就產生了100萬個密鑰，而要保管100萬個密鑰是很困難的。
於是，我們用一個密鑰（KEK）將這100萬個密鑰進行加密，那麼現在我們只要保管者一個KEK就可以了，這一個KEK的價值相當於簽名的100萬個密鑰的價值的總和。
用1個密鑰來代替多個密鑰進行保管的方法，和認證機構的層級化非常相似。在後者中，我們不需要信任多個認證機構，而只需要信任一個根CA就可以了。同樣的，我們也不需要確保多個密鑰的機密性，而只需要確保一個KEK的機密性就可以了。
密鑰的作廢和生成是同等重要的，這是因為密鑰和明文是等價的。
假設Alice向Bob發送了一封加密郵件。Bob在解密之後閱讀了郵件的內容，這時本次通信所使用的密鑰對於Alice和Bob來說就不需要了。不在需要的密鑰必須妥善刪除，因為如果被竊聽者Eve獲取，之前發送的加密郵件就會被解密。
如果密鑰是計算機上的一個文件，那麼僅僅刪除這個文件是不足以刪除密鑰的，因為有一些技術能夠讓刪除的文件「恢復」。此外，很多情況下文件的內容還會殘留在計算機的內存中，因此必須將這些痕跡完全抹去。簡而言之，要完全刪除密鑰，不但要用到密碼軟體，還需要在設計計算機系統時對信息安全進行充分的考慮
如果包含密鑰的文件被誤刪或者保管密鑰的筆記本電腦損壞了，會怎麼樣？
如果丟失了對稱密鑰密碼的共享密鑰，就無法解密密文了。如果丟失了消息認證碼的密鑰，就無法向通信對象證明自己的身份了。
公鑰密碼中，一般不太會發送丟失公鑰的情況，因為公鑰是完全公開的，很有可能在其他電腦上存在副本。
最大的問題是丟失公鑰密碼的私鑰。如果丟失了公鑰密碼的私鑰，就無法解密用公鑰密碼加密的密文了。此外，如果丟失了數字簽名的私鑰，就無法生成數字簽名了。
Diffie-Hellman密鑰交換（Diffie-Hellman key exchange）是1976年由Whitfield Diffie和Martin Hellman共同發明的一種演算法。使用這種演算法，通信雙方僅通過交換一些可以公開的信息就能夠生成共享秘密數字，而這一秘密數字就可以被用作對稱密碼的密鑰。IPsec 中就使用了經過改良的Diffie-Hellman密鑰交換。
2 Alice 生成一個隨機數A
A是一個1 ~ P-2之間的整數。這個數是一個只有Alice知道的密碼數字，沒有必要告訴Bob，也不能讓Eve知道。
Alice計算出的密鑰=Bob計算出的密鑰
在步驟1-7中，雙方交換數字一共有4個，P、G、G A mod P 和 G B mod P。根據這4個數字計算出Alice和Bob的共享密鑰是非常困難的。
如果Eve能歐知道A和B的任意一個數，那麼計算G A*B 就很容易了，然而僅僅根據上面的4個數字很難求出A和B的。
根據G A mod P 計算出A的有效演算法到現在還沒有出現，這問題成為有限域(finite field) 的 離散對數問題 。
Diffie-Hellman密鑰交換是利用了「離散對數問題」的復雜度來實現密鑰的安全交換的，如果將「離散對數問題」改為「橢圓曲線上離散對數問題」，這樣的演算法就稱為 橢圓曲線Diffie-Hellman 密鑰交換。
橢圓曲線Diffie-Hellman密鑰交換在總體流程上是不變的，只是所利用的數學問題不同而已。橢圓曲線Diffie-Hellman密鑰交換能夠用較短的密鑰長度實現較高的安全性。
基於口令密碼（password based encryption，PBE）就是一種根據口令生成密鑰並用該密鑰進行加密的方法。其中加密和解密使用同一個密鑰。
PBE有很多種實現方法。例如RFC2898和RFC7292 等規范中所描述的PBE就通過java的javax.crypto包等進行了實現。此外，在通過密碼軟體PGP保存密鑰時，也會使用PBE。
PBE的意義可以按照下面的邏輯來理解。
想確保重要消息的機制性。
↓
將消息直接保存到磁碟上的話，可能被別人看到。
↓
用密鑰（CEK）對消息進行加密吧。
↓
但是這次又需要確保密鑰（CEK）的機密性了。
↓
將密鑰（CEK）直接保存在磁碟上好像很危險。
↓
用另一個密鑰（KEK）對密鑰進行加密（CEK）吧。
↓
等等！這次又需要確保密鑰（KEK）的機密性了。進入死循環了。
↓
既然如此，那就用口令來生成密鑰（KEK）吧。
↓
但只用口令容易遭到字典攻擊
↓
那麼就用口令和鹽共同生成密鑰（KEK）吧。
↓
鹽可以和加密後的密鑰（CEK）一切保存在磁碟上，而密鑰（KEK）可以直接丟棄。
↓
口令就記在自己的腦子里吧。
PBE加密包括下列3個步驟：
鹽是由偽隨機數生成器生成的隨機數，在生成密鑰（KEK）時會和口令一起被輸入單向散列函數。
密鑰（KEK）是根據秘密的口令生成的，加鹽好像沒有什麼意義，那麼鹽到底起到什麼作用呢？
鹽是用來防禦字典攻擊的 。字典攻擊是一種事先進行計算並准備好候選密鑰列表的方法。
我們假設在生成KEK的時候沒有加鹽。那麼主動攻擊者Mallory就可以根據字典數據事先生成大量的候選KEK。
在這里，事先是很重要的一點。這意味著Mallory可以在竊取到加密會話的密鑰之前，就准備好了大量的候選KEK。當Mallory竊取加密的會話密鑰後，就需要嘗試將它解密，這是准備好了大量事先生成的候選KEK，就能夠大幅度縮短嘗試的時間，這就是 字典攻擊 （dictionary attack）。
如果在生成KEK時加鹽，則鹽的長度越大，候選KEK的數量也會隨之增大，事先生成的的候選KEK就會變得非常困難。只要Mallory還沒有得到鹽，就無法生成候選KEK。這是因為加鹽之後，候選KEK的數量會變得非常巨大。
具有充足長度的密鑰是無法用人腦記憶的。口令也是一樣，我們也無法記住具有充足比特數的口令。
在PBE中，我們通過口令生成密鑰（KEK），在用這個密鑰來加密會話密鑰（CEK）。由於通過口令生成的密鑰（KEK）強度不如由偽隨機數生成器生成的會話密鑰（CEK），這就好像是將一個牢固的保險櫃的鑰匙放在了一個不怎麼牢固的保險櫃保管，因此在使用基於口令的密鑰時，需要將鹽和加密後的CEK通過物理方法進行保護。例如將鹽和加密後的CEK保存到存儲卡隨身攜帶。
在生成KEK時，通過多次使用單向散列函數就可以提高安全性。例如，將鹽和口令輸入單向散列函數，進行1000次的散列函數所得到的散列值作為KEK來使用，是一個不錯的方法。
像這樣將單向散列函數進行多次迭代的方法稱為 拉伸 （stretching）。
該系列的主要內容來自《圖解密碼技術第三版》
我只是知識的搬運工
文章中的插圖來源於原著