演算法套件標識
DES (Data Encryption Standard)是分組對稱密碼演算法。
DES演算法利用 多次組合替代演算法 和 換位演算法 ，分散和錯亂的相互作用，把明文編製成密碼強度很高的密文，它的加密和解密用的是同一演算法。
DES演算法，是一種 乘積密碼 ，其在演算法結構上主要採用了 置換 、 代替 、 模二相加 等函數，通過 輪函數 迭代的方式來進行計算和工作。
DES演算法也會使用到數據置換技術，主要有初始置換 IP 和逆初始置換 IP^-1 兩種類型。DES演算法使用置換運算的目的是將原始明文的所有格式及所有數據全部打亂重排。而在輪加密函數中，即將數據全部打亂重排，同時在數據格式方面，將原有的32位數據格式，擴展成為48位數據格式，目的是為了滿足S盒組對數據長度和數據格式規范的要求。
一組數據信息經過一系列的非線性變換以後，很難從中推導出其計算的過程和使用的非線性組合；但是如果這組數據信息使用的是線性變換，計算就容易的多。在DES演算法中，屬於非線性變換的計算過程只有S盒，其餘的數據計算和變換都是屬於線性變換，所以DES演算法安全的關鍵在於S盒的安全強度。此外，S盒和置換IP相互配合，形成了很強的抗差分攻擊和抗線性攻擊能力，其中抗差分攻擊能力更強一些。
DES演算法是一種分組加密機制，將明文分成N個組，然後對各個組進行加密，形成各自的密文，最後把所有的分組密文進行合並，形成最終的密文。
DES加密是對每個分組進行加密，所以輸入的參數為分組明文和密鑰，明文分組需要置換和迭代，密鑰也需要置換和循環移位。在初始置換IP中，根據一張8*8的置換表，將64位的明文打亂、打雜，從而提高加密的強度；再經過16次的迭代運算，在這些迭代運算中，要運用到子密鑰；每組形成的初始密文，再次經過初始逆置換 IP^-1 ，它是初始置換的逆運算，最後得到分組的最終密文。
圖2右半部分，給出了作用56比特密鑰的過程。DES演算法的加密密鑰是64比特，但是由於密鑰的第n*8(n=1,2…8)是校驗(保證含有奇數個1)，因此實際參與加密的的密鑰只有 56比特 。開始時，密鑰經過一個置換，然後經過循環左移和另一個置換分別得到子密鑰ki，供每一輪的迭代加密使用。每輪的置換函數都一樣，但是由於密鑰位的重復迭代使得子密鑰互不相同。
DES演算法 利用多次組合替代演算法和換位演算法，分散和錯亂的相互作用，把明文編製成密碼強度很高的密文，它的加密和解密用的是同一演算法。
DES演算法詳述：DES對64位明文分組(密鑰56bit)進行操作。
1、 初始置換函數IP：64位明文分組x經過一個初始置換函數IP，產生64位的輸出x0，再將分組x0分成左半部分L0和右半部分R0：即將輸入的第58位換到第一位，第50位換到第2位，…，依次類推，最後一位是原來的第7位。L0、R0則是換位輸出後的兩部分，L0是輸出的左32位，R0是右32位。例，設置換前的輸入值為D1D2D3…D64，則經過初始置換後的結果為：L0=D58D50…D8；R0=D57D49…D7.其置換規則如表1所示。
DES加密過程最後的逆置換 IP^-1 ，是表1的 逆過程 。就是把原來的每一位都恢復過去，即把第1位的數據，放回到第58位，把第2位的數據，放回到第50位。
2、 獲取子密鑰 Ki ：DES加密演算法的密鑰長度為56位，一般表示為64位(每個第8位用於奇偶校驗)，將用戶提供的64位初始密鑰經過一系列的處理得到K1,K2,…,K16，分別作為 1~16 輪運算的 16個子密鑰 。
(1). 將64位密鑰去掉8個校驗位，用密鑰置換 PC-1 (表2)置換剩下的56位密鑰；
(2). 將56位分成前28位C0和後28位D0，即 PC-1(K56)=C0D0 ;
(3). 根據輪數，這兩部分分別循環左移1位或2位，表3：
(4). 移動後，將兩部分合並成56位後通過壓縮置換PC-2(表4)後得到48位子密鑰，即Ki=PC-2(CiDi).
子密鑰產生如圖2所示：
3、 密碼函數F(非線性的)
(1). 函數F的操作步驟：密碼函數F 的輸入是32比特數據和48比特的子密鑰：
A．擴展置換(E):將數據的右半部分Ri從32位擴展為48位。位選擇函數(也稱E盒)，如表5所示：
B．異或：擴展後的48位輸出E(Ri)與壓縮後的48位密鑰Ki作異或運算；
C．S盒替代：將異或得到的48位結果分成八個6位的塊，每一塊通過對應的一個S盒產生一個4位的輸出。
(2)、D、P盒置換：將八個S盒的輸出連在一起生成一個32位的輸出，輸出結果再通過置換P產生一個32位的輸出即：F(Ri,Ki)，F(Ri,Ki)演算法描述如圖3，最後，將P盒置換的結果與最初的64位分組的左半部分異或，然後，左、右半部分交換，開始下一輪計算。
4、密文輸出：經過16次迭代運算後，得到L16、R16，將此作為輸入，進行逆置換，即得到密文輸出。逆置換正好是初始置的逆運算。例如，第1位經過初始置換後，處於第40位，而通過逆置換，又將第40位換回到第1位，其逆置換規則如表8所示：
圖4為DES演算法加密原理圖：
DES演算法加密和解密過程採用相同的演算法，並採用相同的加密密鑰和解密密鑰，兩者的區別是：(1)、DES加密是從L0、R0到L15、R15進行變換，而解密時是從L15、R15到L0、R0進行變換的；(2)、加密時各輪的加密密鑰為K0K1…K15，而解密時各輪的解密密鑰為K15K14…K0；(3)、加密時密鑰循環左移，解密時密鑰循環右移。
DES加密過程分析：
(1)、首先要生成64位密鑰，這64位的密鑰經過「子密鑰演算法」換轉後，將得到總共16個子密鑰。將這些子密鑰標識為Kn(n=1,2,…,16)。這些子密鑰主要用於總共十六次的加密迭代過程中的加密工具。
(2)、其次要將明文信息按64位數據格式為一組，對所有明文信息進行分組處理。每一段的64位明文都要經過初試置換IP，置換的目的是將數據信息全部打亂重排。然後將打亂的數據分為左右兩塊，左邊一塊共32位為一組，標識為L0；右邊一塊也是32位為一組，標識為R0.
(3)、置換後的數據塊總共要進行總共十六次的加密迭代過程。加密迭代主要由加密函數f來實現。首先使用子密鑰K1對右邊32位的R0進行加密處理，得到的結果也是32位的；然後再將這個32位的結果數據與左邊32位的L0進行模2處理，從而再次得到一個32位的數據組。我們將最終得到的這個32位組數據，作為第二次加密迭代的L1，往後的每一次迭代過程都與上述過程相同。
(4)、在結束了最後一輪加密迭代之後，會產生一個64位的數據信息組，然後我們將這個64位數據信息組按原有的數據排列順序平均分為左右兩等分，然後將左右兩等分的部分進行位置調換，即原來左等分的數據整體位移至右側，而原來右等分的數據則整體位移至左側，這樣經過合並後的數據將再次經過逆初始置換IP^-1的計算，我們最終將得到一組64位的密文。
DES解密過程分析：DES的解密過程與它的加密過程是一樣的，這是由於DES演算法本身屬於對稱密碼體制演算法，其加密和解密的過程可以共用同一個過程和運算。
DES加密函數f：在DES演算法中，要將64位的明文順利加密輸出成64位的密文，而完成這項任務的核心部分就是加密函數f。加密函數f的主要作用是在第m次的加密迭代中使用子密鑰Km對Km-1進行加密操作。加密函數f在加密過程中總共需要運行16輪。
十六輪迭代演算法：它先將經過置換後的明文分成兩組，每組32位；同時密鑰也被分成了兩組，每組28位，兩組密鑰經過運算，再聯合成一個48位的密鑰，參與到明文加密的運算當中。S盒子，它由8個4*16的矩陣構成，每一行放著0到15的數據，順序各個不同，是由IBM公司設計好的。經過異或運算的明文，是一個48位的數據，在送入到S盒子的時候，被分成了8份，每份6位，每一份經過一個S盒子，經過運算後輸出為4位，即是一個0到15的數字的二進製表示形式。具體運算過程為，將輸入的6位中的第1位為第6位合並成一個二進制數，表示行號，其餘4位也合並成一個二進制數，表示列號。在當前S盒子中，以這個行號和列號為准，取出相應的數，並以二進制的形式表示，輸出，即得到4位的輸出，8個S盒子共計32位。
DES演算法優缺點：
(1)、產生密鑰簡單，但密鑰必須高度保密，因而難以做到一次一密；
(2)、DES的安全性依賴於密鑰的保密。攻擊破解DES演算法的一個主要方法是通過密鑰搜索，使用運算速度非常高的計算機通過排列組合枚舉的方式不斷嘗試各種可能的密鑰，直到破解為止。一般，DES演算法使用56位長的密鑰，通過簡單計算可知所有可能的密鑰數量最多是2^56個。隨著巨型計算機運算速度的不斷提高，DES演算法的安全性也將隨之下降，然而在一般的民用商業場合，DES的安全性仍是足夠可信賴的。
(3)、DES演算法加密解密速度比較快，密鑰比較短，加密效率很高但通信雙方都要保持密鑰的秘密性，為了安全還需要經常更換DES密鑰。
參考鏈接 ： https://blog.csdn.net/fengbingchun/article/details/42273257
⑵ 國密演算法是什麼呢
國密演算法是國家密碼局制定標準的一系列演算法。其中包括了對稱加密演算法，橢圓曲線非對稱加密演算法，雜湊演算法。具體包括SM1、SM2、SM3、SMS4等，其中：
SM1：對稱加密演算法，加密強度為128位，採用硬體實現。
SM2：國家密碼管理局公布的公鑰演算法，其加密強度為256位。其它幾個重要的商用密碼演算法包括：
SM3：密碼雜湊演算法，雜湊值長度為32位元組，和SM2演算法同期公布，參見《國家密碼管理局公告（第 22 號）》。
SMS4：對稱加密演算法，隨WAPI標准一起公布，可使用軟體實現，加密強度為128位。
案例
例如：在門禁應用中，採用SM1演算法進行身份鑒別和數據加密通訊，實現卡片合法性的驗證，保證身份識別的真實性。安全是關系國家、城市信息、行業用戶、百姓利益的關鍵問題。國家密碼管理局針對現有重要門禁系統建設和升級改造應用也提出指導意見，加強晶元、卡片、系統的標准化建設。
⑶ 文本、語音相似度演算法
前段時間公司項目用到了語音識別,圖像識別,視頻識別等,其實不能說是識別,應該說是相似度對比吧,畢竟相似度對比還上升不了到識別哈,等以後有了更深的理解再來討論修改下!這次就當做一個總結吧!
其實它的原理和視頻圖像相似度演算法類似，將一系列的向量,特徵,權重,進行合並,然後降維降到一維,其實這個演算法也就是採用降維技術,將所有的特徵都用一個唯一標識來表示.然後這個標識是經過這個演算法內部的計算,再利用海明距離計算相似度，視頻和圖片是經過漢明距離計算的
文本我們是採用simhash演算法：
1.我們給文本裡面的詞進行分詞,我們是用ik演算法,這個演算法就是while循環,讀取一行,然後調用ik智能分詞的類,智能去切割裡面的分詞;
2.根據裡面的詞頻,simhash演算法會加一個權重,當然,得詞頻達到多少個的時候才會有有權重,這也是它的缺點,一般文本數據較少的時候,他是不準確的,一般數據量在500+;演算法內部的話會將一系列的向量,特徵,權重,進行合並,然後降維降到一維,其實這個演算法也就是採用降維技術,將所有的特徵都用一個唯一標識來表示.然後這個標識是經過這個演算法內部的計算,然後得到的一個指紋簽名；
3.然後對比兩個文本的相似度就是將兩個指紋簽名進行海明距離計算,如果海明距離<8(根據業務和場景去判斷這個值，8是建議，參考)的話,表示兩個相似,小於3的話.表示兩個文本重復.
simhash演算法我們還可以做語音相似度,它的基本原理就是根據傅里葉變換處理得到聲波的形狀。
語音的坡度如果向上我們就用1表示,向下我們就用0表示,這樣的話,我們也可以用二進制碼去描述一首歌曲.得到一個唯一的指紋簽名,對比兩個音頻的相似度就是將兩個指紋簽名進行海明距離計算<8的話,我們就默認兩個音頻相似.
總結：都是把特徵降到一維，然後採用海明距離計算。計算的值小於多少時，就當做是相似。我這邊講的太淺了，實在領悟有限，時間有限，觸摸不深，等下次有新的領悟再來補充！
⑷ OpenSSL 入門：密碼學基礎知識
本文是使用 OpenSSL 的密碼學基礎知識的兩篇文章中的第一篇，OpenSSL 是在 Linux 和其他系統上流行的生產級庫和工具包。（要安裝 OpenSSL 的最新版本，請參閱 這里 。）OpenSSL 實用程序可在命令行使用，程序也可以調用 OpenSSL 庫中的函數。本文的示常式序使用的是 C 語言，即 OpenSSL 庫的源語言。
本系列的兩篇文章涵蓋了加密哈希、數字簽名、加密和解密以及數字證書。你可以從 我的網站 的 ZIP 文件中找到這些代碼和命令行示例。
讓我們首先回顧一下 OpenSSL 名稱中的 SSL。
安全套接字層 (Secure Socket Layer)（SSL）是 Netscape 在 1995 年發布的一種加密協議。該協議層可以位於 HTTP 之上，從而為 HTTPS 提供了 S： 安全(secure)。SSL 協議提供了各種安全服務，其中包括兩項在 HTTPS 中至關重要的服務：
SSL 有多個版本（例如 SSLv2 和 SSLv3），並且在 1999 年出現了一個基於 SSLv3 的類似協議 傳輸層安全性(Transport Layer Security)（TLS）。TLSv1 和 SSLv3 相似，但不足以相互配合工作。不過，通常將 SSL/TLS 稱為同一協議。例如，即使正在使用的是 TLS（而非 SSL），OpenSSL 函數也經常在名稱中包含 SSL。此外，調用 OpenSSL 命令行實用程序以 openssl 開始。
除了 man 頁面之外，OpenSSL 的文檔是零零散散的，鑒於 OpenSSL 工具包很大，這些頁面很難以查找使用。命令行和代碼示例可以將主要主題集中起來。讓我們從一個熟悉的示例開始（使用 HTTPS 訪問網站），然後使用該示例來選出我們感興趣的加密部分進行講述。
此處顯示的 client 程序通過 HTTPS 連接到 Google：
可以從命令行編譯和執行該程序（請注意 -lssl 和 -lcrypto 中的小寫字母 L）：
該程序嘗試打開與網站 www.google.com 的安全連接。在與 Google Web 伺服器的 TLS 握手過程中，client 程序會收到一個或多個數字證書，該程序會嘗試對其進行驗證（但在我的系統上失敗了）。盡管如此，client 程序仍繼續通過安全通道獲取 Google 主頁。該程序取決於前面提到的安全工件，盡管在上述代碼中只著重突出了數字證書。但其它工件仍在幕後發揮作用，稍後將對它們進行詳細說明。
通常，打開 HTTP（非安全）通道的 C 或 C++ 的客戶端程序將使用諸如文件描述符或網路套接字之類的結構，它們是兩個進程（例如，這個 client 程序和 Google Web 伺服器）之間連接的端點。另一方面，文件描述符是一個非負整數值，用於在程序中標識該程序打開的任何文件類的結構。這樣的程序還將使用一種結構來指定有關 Web 伺服器地址的詳細信息。
這些相對較低級別的結構不會出現在客戶端程序中，因為 OpenSSL 庫會將套接字基礎設施和地址規范等封裝在更高層面的安全結構中。其結果是一個簡單的 API。下面首先看一下 client 程序示例中的安全性詳細信息。
在與 Web 伺服器握手期間，client 程序會接收一個或多個數字證書，以認證伺服器的身份。但是，client 程序不會發送自己的證書，這意味著這個身份驗證是單向的。（Web 伺服器通常配置為 不 需要客戶端證書）盡管對 Web 伺服器證書的驗證失敗，但 client 程序仍通過了連接到 Web 伺服器的安全通道繼續獲取 Google 主頁。
為什麼驗證 Google 證書的嘗試會失敗？典型的 OpenSSL 安裝目錄為 /etc/ssl/certs，其中包含 ca-certificates.crt 文件。該目錄和文件包含著 OpenSSL 自帶的數字證書，以此構成 信任庫(truststore)。可以根據需要更新信任庫，尤其是可以包括新信任的證書，並刪除不再受信任的證書。
client 程序從 Google Web 伺服器收到了三個證書，但是我的計算機上的 OpenSSL 信任庫並不包含完全匹配的證書。如目前所寫，client 程序不會通過例如驗證 Google 證書上的數字簽名（一個用來證明該證書的簽名）來解決此問題。如果該簽名是受信任的，則包含該簽名的證書也應受信任。盡管如此，client 程序仍繼續獲取頁面，然後列印出 Google 的主頁。下一節將更詳細地介紹這些。
讓我們從客戶端示例中可見的安全工件（數字證書）開始，然後考慮其他安全工件如何與之相關。數字證書的主要格式標準是 X509，生產級的證書由諸如 Verisign 的 證書頒發機構(Certificate Authority)（CA）頒發。
數字證書中包含各種信息（例如，激活日期和失效日期以及所有者的域名），也包括發行者的身份和數字簽名（這是加密過的加密哈希值）。證書還具有未加密的哈希值，用作其標識指紋。
哈希值來自將任意數量的二進制位映射到固定長度的摘要。這些位代表什麼（會計報告、小說或數字電影）無關緊要。例如， 消息摘要版本 5(Message Digest version 5)（MD5）哈希演算法將任意長度的輸入位映射到 128 位哈希值，而 SHA1（ 安全哈希演算法版本 1(Secure Hash Algorithm version 1)）演算法將輸入位映射到 160 位哈希值。不同的輸入位會導致不同的（實際上在統計學上是唯一的）哈希值。下一篇文章將會進行更詳細的介紹，並著重介紹什麼使哈希函數具有加密功能。
數字證書的類型有所不同（例如根證書、中間證書和最終實體證書），並形成了反映這些證書類型的層次結構。顧名思義，根證書位於層次結構的頂部，其下的證書繼承了根證書所具有的信任。OpenSSL 庫和大多數現代編程語言都具有 X509 數據類型以及處理此類證書的函數。來自 Google 的證書具有 X509 格式，client 程序會檢查該證書是否為 X509_V_OK。
X509 證書基於 公共密鑰基礎結構(public-key infrastructure)（PKI），其中包括的演算法（RSA 是佔主導地位的演算法）用於生成密鑰對：公共密鑰及其配對的私有密鑰。公鑰是一種身份： Amazon 的公鑰對其進行標識，而我的公鑰對我進行標識。私鑰應由其所有者負責保密。
成對出現的密鑰具有標准用途。可以使用公鑰對消息進行加密，然後可以使用同一個密鑰對中的私鑰對消息進行解密。私鑰也可以用於對文檔或其他電子工件（例如程序或電子郵件）進行簽名，然後可以使用該對密鑰中的公鑰來驗證簽名。以下兩個示例補充了一些細節。
在第一個示例中，Alice 將她的公鑰分發給全世界，包括 Bob。然後，Bob 用 Alice 的公鑰加密郵件，然後將加密的郵件發送給 Alice。用 Alice 的公鑰加密的郵件將可以用她的私鑰解密（假設是她自己的私鑰），如下所示：
理論上可以在沒有 Alice 的私鑰的情況下解密消息，但在實際情況中，如果使用像 RSA 這樣的加密密鑰對系統，則在計算上做不到。
現在，第二個示例，請對文檔簽名以證明其真實性。簽名演算法使用密鑰對中的私鑰來處理要簽名的文檔的加密哈希：
假設 Alice 以數字方式簽署了發送給 Bob 的合同。然後，Bob 可以使用 Alice 密鑰對中的公鑰來驗證簽名：
假若沒有 Alice 的私鑰，就無法輕松偽造 Alice 的簽名：因此，Alice 有必要保密她的私鑰。
在 client 程序中，除了數字證書以外，這些安全性都沒有明確展示。下一篇文章使用使用 OpenSSL 實用程序和庫函數的示例填充更多詳細的信息。
同時，讓我們看一下 OpenSSL 命令行實用程序：特別是在 TLS 握手期間檢查來自 Web 伺服器的證書的實用程序。調用 OpenSSL 實用程序可以使用 openssl 命令，然後添加參數和標志的組合以指定所需的操作。
看看以下命令：
該輸出是組成 加密演算法套件(cipher suite)()的相關演算法的列表。下面是列表的開頭，加了澄清首字母縮寫詞的注釋：
下一條命令使用參數 s_client 將打開到 www.google.com 的安全連接，並在屏幕上顯示有關此連接的所有信息：
諸如 Google 之類的主要網站通常會發送多個證書進行身份驗證。
輸出以有關 TLS 會話的摘要信息結尾，包括加密演算法套件的詳細信息：
client 程序中使用了協議 TLS 1.2，Session-ID 唯一地標識了 openssl 實用程序和 Google Web 伺服器之間的連接。Cipher 條目可以按以下方式進行解析：
加密演算法套件正在不斷發展中。例如，不久前，Google 使用 RC4 流加密演算法（RSA 的 Ron Rivest 後來開發的 Ron』s Cipher 版本 4）。 RC4 現在有已知的漏洞，這大概部分導致了 Google 轉換為 AES128。
我們通過安全的 C Web 客戶端和各種命令行示例對 OpenSSL 做了首次了解，使一些需要進一步闡明的主題脫穎而出。 下一篇文章會詳細介紹 ，從加密散列開始，到對數字證書如何應對密鑰分發挑戰為結束的更全面討論。
via: https://opensource.com/article/19/6/cryptography-basics-openssl-part-1
作者： Marty Kalin 選題： lujun9972 譯者： wxy 校對： wxy
⑸ TLS 詳解
SSL (Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本後發展成了標准安全協議 - TLS (Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。
TLS 在實現上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規范協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)
只需配置瀏覽器和伺服器相關設置開啟 TLS，即可實現 HTTPS，TLS 高度解耦，可裝可卸，與上層高級應用層協議相互協作又相互獨立。
TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。
TLS 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密演算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。
例如，在 HTTPS 協議中，客戶端發出請求，服務端會將公鑰發給客戶端，客戶端驗證過後生成一個密鑰再用公鑰加密後發送給服務端（非對稱加密），雙方會在 TLS 握手過程中生成一個協商密鑰（對稱密鑰），成功後建立加密連接。通信過程中客戶端將請求數據用協商密鑰加密後發送，服務端也用協商密鑰解密，響應也用相同的協商密鑰。後續的通信使用對稱加密是因為對稱加解密快，而握手過程中非對稱加密可以保證加密的有效性，但是過程復雜，計算量相對來說也大。
記錄協議負責在傳輸連接上交換的所有底層消息，並且可以配置加密。每一條 TLS 記錄以一個短標頭開始。標頭包含記錄內容的類型 (或子協議)、協議版本和長度。原始消息經過分段 (或者合並)、壓縮、添加認證碼、加密轉為 TLS 記錄的數據部分。
記錄層將信息塊分割成攜帶 2^14 位元組 (16KB) 或更小塊的數據的 TLSPlaintext 記錄。
記錄協議傳輸由其他協議層提交給它的不透明數據緩沖區。如果緩沖區超過記錄的長度限制（2^14），記錄協議會將其切分成更小的片段。反過來也是可能的，屬於同一個子協議的小緩沖區也可以組合成一個單獨的記錄。
壓縮演算法將 TLSPlaintext 結構轉換為 TLSCompressed 結構。如果定義 CompressionMethod 為 null 表示不壓縮
流加密（BulkCipherAlgorithm）將 TLSCompressed.fragment 結構轉換為流 TLSCiphertext.fragment 結構
MAC 產生方法如下：
seq_num（記錄的序列號）、hash（SecurityParameters.mac_algorithm 指定的哈希演算法）
塊加密（如 RC2 或 DES），將 TLSCompressed.fragment 結構轉換為塊 TLSCiphertext.fragment 結構
padding: 添加的填充將明文長度強制為塊密碼塊長度的整數倍。填充可以是長達 255 位元組的任何長度，只要滿足 TLSCiphertext.length 是塊長度的整數倍。長度大於需要的值可以阻止基於分析交換信息長度的協議攻擊。填充數據向量中的每個 uint8 必須填入填充長度值 (即 padding_length)。
padding_length: 填充長度應該使得 GenericBlockCipher 結構的總大小是加密塊長度的倍數。合法值范圍從零到 255（含）。 該長度指定 padding_length 欄位本身除外的填充欄位的長度
加密塊的數據長度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的總和加一
加密和 MAC 功能將 TLSCompressed 結構轉換為 TLSCiphertext。記錄的 MAC 還包括序列號，以便可以檢測到丟失，額外或重復的消息。
記錄協議需要一種演算法，從握手協議提供的安全性參數生成密鑰、 IV 和 MAC secret.
主密鑰 (Master secret): 在連接中雙方共享的一個 48 位元組的密鑰
客戶隨機數 (client random): 由客戶端提供的 32 位元組值
伺服器隨機數 (server random): 由伺服器提供的 32 位元組值
握手是 TLS 協議中最精密復雜的部分。在這個過程中，通信雙方協商連接參數，並且完成身 份驗證。根據使用的功能的不同，整個過程通常需要交換 6~10 條消息。根據配置和支持的協議擴展的不同，交換過程可能有許多變種。在使用中經常可以觀察到以下三種流程：(1) 完整的握手， 對伺服器進行身份驗證；(2) 恢復之前的會話採用的簡短握手；(3) 對客戶端和伺服器都進行身份驗證的握手。
握手協議消息的標頭信息包含消息類型（1 位元組）和長度（3 位元組），餘下的信息則取決於消息類型：
每一個 TLS 連接都會以握手開始。如果客戶端此前並未與伺服器建立會話，那麼雙方會執行一次完整的握手流程來協商 TLS 會話。握手過程中，客戶端和伺服器將進行以下四個主要步驟:
下面介紹最常見的握手規則，一種不需要驗證客戶端身份但需要驗證伺服器身份的握手:
這條消息將客戶端的功能和首選項傳送給伺服器。
是將伺服器選擇的連接參數傳回客戶端。
這個消息的結構與 ClientHello 類似，只是每個欄位只包含一個選項，其中包含服務端的 random_S 參數 (用於後續的密鑰協商)。伺服器無需支持客戶端支持的最佳版本。如果伺服器不支持與客戶端相同的版本，可以提供某個其他版本以期待客戶端能夠接受
圖中的 Cipher Suite 是後續密鑰協商和身份驗證要用的加密套件，此處選擇的密鑰交換與簽名演算法是 ECDHE_RSA，對稱加密演算法是 AES-GCM，後面會講到這個
還有一點默認情況下 TLS 壓縮都是關閉的，因為 CRIME 攻擊會利用 TLS 壓縮恢復加密認證 cookie，實現會話劫持，而且一般配置 gzip 等內容壓縮後再壓縮 TLS 分片效益不大又額外佔用資源，所以一般都關閉 TLS 壓縮
典型的 Certificate 消息用於攜帶伺服器 X.509 證書鏈 。
伺服器必須保證它發送的證書與選擇的演算法套件一致。比方說，公鑰演算法與套件中使用的必須匹配。除此以外，一些密鑰交換演算法依賴嵌入證書的特定數據，而且要求證書必須以客戶端支持的演算法簽名。所有這些都表明伺服器需要配置多個證書（每個證書可能會配備不同的證書鏈）。
Certificate 消息是可選的，因為並非所有套件都使用身份驗證，也並非所有身份驗證方法都需要證書。更進一步說，雖然消息默認使用 X.509 證書，但是也可以攜帶其他形式的標志；一些套件就依賴 PGP 密鑰
攜帶密鑰交換需要的額外數據。ServerKeyExchange 是可選的，消息內容對於不同的協商演算法套件會存在差異。部分場景下，比如使用 RSA 演算法時，伺服器不需要發送此消息。
ServerKeyExchange 僅在伺服器證書消息（也就是上述 Certificate 消息）不包含足夠的數據以允許客戶端交換預主密鑰（premaster secret）時才由伺服器發送。
比如基於 DH 演算法的握手過程中，需要單獨發送一條 ServerKeyExchange 消息帶上 DH 參數:
表明伺服器已經將所有預計的握手消息發送完畢。在此之後，伺服器會等待客戶端發送消息。
客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證內容包括如下:
由 PKI 體系 的內容可知，對端發來的證書簽名是 CA 私鑰加密的，接收到證書後，先讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性；然後去查詢證書的吊銷情況等
合法性驗證通過之後，客戶端計算產生隨機數字的預主密鑰（Pre-master），並用證書公鑰加密，發送給伺服器並攜帶客戶端為密鑰交換提供的所有信息。這個消息受協商的密碼套件的影響，內容隨著不同的協商密碼套件而不同。
此時客戶端已經獲取全部的計算協商密鑰需要的信息: 兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，然後得到協商密鑰(用於之後的消息加密)
圖中使用的是 ECDHE 演算法，ClientKeyExchange 傳遞的是 DH 演算法的客戶端參數，如果使用的是 RSA 演算法則此處應該傳遞加密的預主密鑰
通知伺服器後續的通信都採用協商的通信密鑰和加密演算法進行加密通信
Finished 消息意味著握手已經完成。消息內容將加密，以便雙方可以安全地交換驗證整個握手完整性所需的數據。
這個消息包含 verify_data 欄位，它的值是握手過程中所有消息的散列值。這些消息在連接兩端都按照各自所見的順序排列，並以協商得到的主密鑰 (enc_key) 計算散列。這個過程是通過一個偽隨機函數（pseudorandom function，PRF）來完成的，這個函數可以生成任意數量的偽隨機數據。
兩端的計算方法一致，但會使用不同的標簽（finished_label）：客戶端使用 client finished，而伺服器則使用 server finished。
因為 Finished 消息是加密的，並且它們的完整性由協商 MAC 演算法保證，所以主動網路攻擊者不能改變握手消息並對 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的長度默認是 12 位元組（96 位），並且允許密碼套件使用更長的長度。在此之前的版本，除了 SSL 3 使用 36 位元組的定長消息，其他版本都使用 12 位元組的定長消息。
伺服器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，同樣計算得到協商密鑰: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;
同樣計算之前所有收發信息的 hash 值，然後用協商密鑰解密客戶端發送的 verify_data_C，驗證消息正確性;
服務端驗證通過之後，伺服器同樣發送 change_cipher_spec 以告知客戶端後續的通信都採用協商的密鑰與演算法進行加密通信（圖中多了一步 New Session Ticket，此為會話票證，會在會話恢復中解釋）;
伺服器也結合所有當前的通信參數信息生成一段數據 (verify_data_S) 並採用協商密鑰 session secret (enc_key) 與演算法加密並發送到客戶端;
客戶端計算所有接收信息的 hash 值，並採用協商密鑰解密 verify_data_S，驗證伺服器發送的數據和密鑰，驗證通過則握手完成;
開始使用協商密鑰與演算法進行加密通信。
HTTPS 通過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能。加密過程中，需要用到非對稱密鑰交換和對稱內容加密兩大演算法。
對稱內容加密強度非常高，加解密速度也很快，只是無法安全地生成和保管密鑰。在 TLS 協議中，最後的應用數據都是經過對稱加密後傳輸的，傳輸中所使用的對稱協商密鑰(上文中的 enc_key)，則是在握手階段通過非對稱密鑰交換而來。常見的 AES-GCM、ChaCha20-Poly1305，都是對稱加密演算法。
非對稱密鑰交換能在不安全的數據通道中，產生只有通信雙方才知道的對稱加密密鑰。目前最常用的密鑰交換演算法有 RSA 和 ECDHE。
RSA 歷史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（橢圓曲線）的 DH（Diffie-Hellman）演算法，計算速度快，且支持 PFS。
在 PKI 體系 一節中說明了僅有非對稱密鑰交換還是無法抵禦 MITM 攻擊的，所以需要引入了 PKI 體系的證書來進行身份驗證，其中服務端非對稱加密產生的公鑰會放在證書中傳給客戶端。
在 RSA 密鑰交換中，瀏覽器使用證書提供的 RSA 公鑰加密相關信息，如果服務端能解密，意味著服務端擁有與公鑰對應的私鑰，同時也能算出對稱加密所需密鑰。密鑰交換和服務端認證合並在一起。
在 ECDH 密鑰交換中，服務端使用私鑰 (RSA 或 ECDSA) 對相關信息進行簽名，如果瀏覽器能用證書公鑰驗證簽名，就說明服務端確實擁有對應私鑰，從而完成了服務端認證。密鑰交換則是各自發送 DH 參數完成的，密鑰交換和服務端認證是完全分開的。
可用於 ECDHE 數字簽名的演算法主要有 RSA 和 ECDSA - 橢圓曲線數字簽名演算法 ，也就是目前密鑰交換 + 簽名有三種主流選擇:
比如我的網站使用的加密套件是 ECDHE_RSA，可以看到數字簽名演算法是 sha256 哈希加 RSA 加密，在 PKI 體系 一節中講了簽名是伺服器信息摘要的哈希值加密生成的
內置 ECDSA 公鑰的證書一般被稱之為 ECC 證書，內置 RSA 公鑰的證書就是 RSA 證書。因為 256 位 ECC Key 在安全性上等同於 3072 位 RSA Key，所以 ECC 證書體積比 RSA 證書小，而且 ECC 運算速度更快，ECDHE 密鑰交換 + ECDSA 數字簽名是目前最好的加密套件
以上內容來自本文: 開始使用 ECC 證書
關於 ECC 證書的更多細節可見文檔: ECC Cipher Suites for TLS - RFC4492
使用 RSA 進行密鑰交換的握手過程與前面說明的基本一致，只是沒有 ServerKeyExchange 消息，其中協商密鑰涉及到三個參數 (客戶端隨機數 random_C、服務端隨機數 random_S、預主密鑰 Premaster secret)，
其中前兩個隨機數和協商使用的演算法是明文的很容易獲取，最後一個 Premaster secret 會用伺服器提供的公鑰加密後傳輸給伺服器 (密鑰交換)，如果這個預主密鑰被截取並破解則協商密鑰也可以被破解。
RSA 演算法的細節見: wiki 和 RSA演算法原理（二）- 阮一峰
RSA 的演算法核心思想是利用了極大整數 因數分解 的計算復雜性
而使用 DH(Diffie-Hellman) 演算法 進行密鑰交換，雙方只要交換各自的 DH 參數(在 ServerKeyExchange 發送 Server params，在 ClientKeyExchange 發送 Client params)，不需要傳遞 Premaster secret，就可以各自算出這個預主密鑰
DH 的握手過程如下，大致過程與 RSA 類似，圖中只表達如何生成預主密鑰:
伺服器通過私鑰將客戶端隨機數 random_C，服務端隨機數 random_S，服務端 DH 參數 Server params 簽名生成 signature，然後在 ServerKeyExchange 消息中發送服務端 DH 參數和該簽名；
客戶端收到後用伺服器給的公鑰解密驗證簽名，並在 ClientKeyExchange 消息中發送客戶端 DH 參數 Client params；
服務端收到後，雙方都有這兩個參數，再各自使用這兩個參數生成預主密鑰 Premaster secret，之後的協商密鑰等步驟與 RSA 基本一致。
關於 DH 演算法如何生成預主密鑰，推薦看下 Wiki 和 Ephemeral Diffie-Hellman handshake
其核心思想是利用了 離散對數問題 的計算復雜性
演算法過程可以抽象成下圖:
雙方預先商定好了一對 P g 值 (公開的)，而 Alice 有一個私密數 a(非公開，對應一個私鑰)，Bob 有一個私密數 b(非公開，對應一個私鑰)
對於 Alice 和 Bob 來說通過對方發過來的公鑰參數和自己手中的私鑰可以得到最終相同的密鑰
而第三方最多知道 P g A B，想得到私鑰和最後的密鑰很困難，當然前提是 a b P 足夠大 (RFC3526 文檔中有幾個常用的大素數可供使用)，否則暴力破解也有可能試出答案，至於 g 一般取個較小值就可以
如下幾張圖是實際 DH 握手發送的內容:
可以看到雙方發給對方的參數中攜帶了一個公鑰值，對應上述的 A 和 B
而且實際用的加密套件是 橢圓曲線 DH 密鑰交換 (ECDH) ，利用由橢圓曲線加密建立公鑰與私鑰對可以更進一步加強 DH 的安全性，因為目前解決橢圓曲線離散對數問題要比因式分解困難的多，而且 ECC 使用的密鑰長度比 RSA 密鑰短得多(目前 RSA 密鑰需要 2048 位以上才能保證安全，而 ECC 密鑰 256 位就足夠)
關於 橢圓曲線密碼學 - ECC ，推薦看下 A Primer on Elliptic Curve Cryptography - 原文 - 譯文
盡管可以選擇對任意一端進行身份驗證，但人們幾乎都啟用了對伺服器的身份驗證。如果伺服器選擇的套件不是匿名的，那麼就需要在 Certificate 消息中跟上自己的證書。
相比之下，伺服器通過發送 CertificateRequest 消息請求對客戶端進行身份驗證。消息中列出所有可接受的客戶端證書。作為響應，客戶端發送自己的 Certificate 消息（使用與伺服器發送證書相同的格式），並附上證書。此後，客戶端發送 CertificateVerify 消息，證明自己擁有對應的私鑰。
只有已經過身份驗證的伺服器才被允許請求客戶端身份驗證。基於這個原因，這個選項也被稱為相互身份驗證（mutual authentication）。
在 ServerHello 的過程中發出，請求對客戶端進行身份驗證，並將其接受的證書的公鑰和簽名演算法傳送給客戶端。
它也可以選擇發送一份自己接受的證書頒發機構列表，這些機構都用其可分辨名稱來表示:
在 ClientKeyExchange 的過程中發出，證明自己擁有的私鑰與之前發送的客戶端證書中的公鑰匹配。消息中包含一條到這一步為止的所有握手消息的簽名：
最初的會話恢復機制是，在一次完整協商的連接斷開時，客戶端和伺服器都會將會話的安全參數保存一段時間。希望使用會話恢復的伺服器為會話指定唯一的標識，稱為會話 ID(Session ID)。伺服器在 ServerHello 消息中將會話 ID 發回客戶端。
希望恢復早先會話的客戶端將適當的 Session ID 放入 ClientHello 消息，然後提交。伺服器如果同意恢復會話，就將相同的 Session ID 放入 ServerHello 消息返回，接著使用之前協商的主密鑰生成一套新的密鑰，再切換到加密模式，發送 Finished 消息。
客戶端收到會話已恢復的消息以後，也進行相同的操作。這樣的結果是握手只需要一次網路往返。
Session ID 由伺服器端支持，協議中的標准欄位，因此基本所有伺服器都支持，伺服器端保存會話 ID 以及協商的通信信息，佔用伺服器資源較多。
用來替代伺服器會話緩存和恢復的方案是使用會話票證（Session ticket）。使用這種方式，除了所有的狀態都保存在客戶端（與 HTTP Cookie 的原理類似）之外，其消息流與伺服器會話緩存是一樣的。
其思想是伺服器取出它的所有會話數據（狀態）並進行加密 (密鑰只有伺服器知道)，再以票證的方式發回客戶端。在接下來的連接中，客戶端恢復會話時在 ClientHello 的擴展欄位 session_ticket 中攜帶加密信息將票證提交回伺服器，由伺服器檢查票證的完整性，解密其內容，再使用其中的信息恢復會話。
這種方法有可能使擴展伺服器集群更為簡單，因為如果不使用這種方式，就需要在服務集群的各個節點之間同步會話。
Session ticket 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。
⑹ Hello，密碼學：第三部分，公鑰密碼（非對稱密碼）演算法
在 《Hello，密碼學：第二部分，對稱密碼演算法》 中講述了對稱密碼的概念，以及DES和AES兩種經典的對稱密碼演算法原理。既然有對稱密碼的說法，自然也就有非對稱密碼，也叫做公鑰密碼演算法。 對稱密碼和非對稱密碼兩種演算法的本質區別在於，加密密鑰和解密密鑰是否相同 ：
公鑰密碼產生的初衷就是為了解決 密鑰配送 的問題。
Alice 給遠方的 Bob 寫了一封情意慢慢的信，並使用強悍的 AES-256 進行了加密，但她很快就意識到，光加密內容不行，必須要想一個安全的方法將加密密鑰告訴 Bob，如果將密鑰也通過網路發送，很可能被技術高手+偷窺癖的 Eve 竊聽到。
既要發送密鑰，又不能發送密鑰，這就是對稱密碼演算法下的「密鑰配送問題」 。
解決密鑰配送問題可能有這樣幾種方法：
這種方法比較高效，但有局限性：
與方法一不同，密鑰不再由通信個體來保存，而由密鑰分配中心（KDC）負責統一的管理和分配。 雙方需要加密通信時，由 KDC 生成一個用於本次通信的通信密鑰交由雙方，通信雙方只要與 KDC 事先共享密鑰即可 。這樣就大大減少密鑰的存儲和管理問題。
因此，KDC 涉及兩類密鑰：
領略下 KDC 的過程：
KDC 通過中心化的手段，確實能夠有效的解決方法一的密鑰管理和分配問題，安全性也還不錯。但也存在兩個顯著的問題：
使用公鑰密睜衡碼，加密密鑰和解密密鑰不同，只要擁有加密密鑰，所有人都能進行加密，但只有擁有解密密鑰的人才能進行解密。於是就出現了這個過程：
密鑰配送的問題天然被解決了。當然，解密密鑰丟失而導致信息泄密，這不枯脊屬於密鑰配送的問題。
下面，再詳細看下這個過程。
公鑰沒早滲密碼流程的核心，可以用如下四句話來概述：
既然加密密鑰是公開的，因此也叫做 「公鑰（Public Key）」 。
既然解密密鑰是私有的，因此也叫做 「私鑰（Private Key） 。
公鑰和私鑰是一一對應的，稱為 「密鑰對」 ，他們好比相互糾纏的量子對， 彼此之間通過嚴密的數學計算關系進行關聯 ，不能分別單獨生成。
在公鑰密碼體系下，再看看 Alice 如何同 Bob 進行通信。
在公鑰密碼體系下，通信過程是由 Bob 開始啟動的：
過程看起來非常簡單，但為什麼即使公鑰被竊取也沒有關系？這就涉及了上文提到的嚴密的數學計算關系了。如果上一篇文章對稱密鑰的 DES 和 AES 演算法進行概述，下面一節也會對公鑰體系的數學原理進行簡要說明。
自從 Diffie 和 Hellman 在1976年提出公鑰密碼的設計思想後，1978年，Ron Rivest、Adi Shamir 和 Reonard Adleman 共同發表了一種公鑰密碼演算法，就是大名鼎鼎的 RSA，這也是當今公鑰密碼演算法事實上的標准。其實，公鑰密碼演算法還包括ElGamal、Rabin、橢圓曲線等多種演算法，這一節主要講述 RSA 演算法的基本數學原理。
一堆符號，解釋下，E 代表 Encryption，D 代表 Decryption，N 代表 Number。
從公式種能夠看出來，RSA的加解密數學公式非常簡單（即非常美妙）。 RSA 最復雜的並非加解密運算，而是如何生成密鑰對 ，這和對稱密鑰演算法是不太一樣的。 而所謂的嚴密的數學計算關系，就是指 E 和 D 不是隨便選擇的 。
密鑰對的生成，是 RSA 最核心的問題，RSA 的美妙與奧秘也藏在這裡面。
1. 求N
求 N 公式：N = p × q
其中， p 和 q 是兩個質數 ，而且應該是很大又不是極大的質數。如果太小的話，密碼就容易被破解；如果極大的話，計算時間就會很長。比如 512 比特的長度（155 位的十進制數字）就比較合適。
這樣的質數是如何找出來的呢？ 需要通過 「偽隨機數生成器（PRNG）」 進行生成，然後再判斷其是否為質數 。如果不是，就需要重新生成，重新判斷。
2. 求L
求 L 公式：L = lcm(p-1, q-1)
lcm 代表 「最小公倍數（least common multiple）」 。注意，L 在加解密時都不需要， 僅出現在生成密鑰對的過程中 。
3. 求E
E 要滿足兩個條件：
1）1 < E < L
2）gcd(E,L) = 1
gcd 代表 「最大公約數（greatest common divisor）」 。gcd(E,L) = 1 就代表 「E 和 L 的最大公約數為1，也就是說， E 和 L 互質 」。
L 在第二步已經計算出來，而為了找到滿足條件的 E， 第二次用到 「偽隨機數生成器（PRNG）」 ，在 1 和 L 之間生成 E 的候選，判斷其是否滿足 「gcd(E,L) = 1」 的條件。
經過前三步，已經能夠得到密鑰對種的 「公鑰：{E, N}」 了。
4. 求D
D 要滿足兩個條件：
1）1 < D < L
2）E × D mod L = 1
只要 D 滿足上面的兩個條件，使用 {E, N} 進行加密的報文，就能夠使用 {D, N} 進行解密。
至此，N、L、E、D 都已經計算出來，再整理一下
模擬實踐的過程包括兩部分，第一部分是生成密鑰對，第二部分是對數據進行加解密。為了方便計算，都使用了較小的數字。
第一部分：生成密鑰對
1. 求N
准備兩個質數，p = 5，q = 7，N = 5 × 7 = 35
2. 求L
L = lcm(p-1, q-1) = lcm (4, 6) = 12
3. 求E
gcd(E, L) = 1，即 E 和 L 互質，而且 1 < E < L，滿足條件的 E 有多個備選：5、7、11，選擇最小的 5 即可。於是，公鑰 = {E, N} = {5, 35}
4. 求D
E × D mod L = 1，即 5 × D mod 12 = 1，滿足條件的 D 也有多個備選：5、17、41，選擇 17 作為 D（如果選擇 5 恰好公私鑰一致了，這樣不太直觀），於是，私鑰 = {D, N} = {17, 35}
至此，我們得到了公私鑰對：
第二部分：模擬加解密
明文我們也使用一個比較小的數字 -- 4，利用 RSA 的加密公式：
密文 = 明文 ^ E mod N = 4 ^ 5 mod 35 = 9
明文 = 密文 ^ D mod N = 9 ^ 17 mod 35 = 4
從這個模擬的小例子能夠看出，即使我們用了很小的數字，計算的中間結果也是超級大。如果再加上偽隨機數生成器生成一個數字，判斷其是否為質數等，這個過程想想腦仁兒就疼。還好，現代晶元技術，讓計算機有了足夠的運算速度。然而，相對於普通的邏輯運算，這類數學運算仍然是相當緩慢的。這也是一些非對稱密碼卡/套件中，很關鍵的性能規格就是密鑰對的生成速度
公鑰密碼體系中，用公鑰加密，用私鑰解密，公鑰公開，私鑰隱藏。因此：
加密公式為：密文 = 明文 ^ E mod N
破譯的過程就是對該公式進行逆運算。由於除了對明文進行冪次運算外， 還加上了「模運算」 ，因此在數學上， 該逆運算就不再是簡單的對數問題，而是求離散對數問題，目前已經在數學領域達成共識，尚未發現求離散對數的高效演算法 。
暴力破解的本質就是逐個嘗試。當前主流的 RSA 演算法中，使用的 p 和 q 都是 1024 位以上，這樣 N 的長度就是 2048 位以上。而 E 和 D 的長度和 N 差不多，因此要找出 D，就需要進行 2048 位以上的暴力破解。即使上文那個簡單的例子，算出（ 蒙出 ） 「9 ^ D mod 35 = 4」 中的 D 也要好久吧。
因為 E 和 N 是已知的，而 D 和 E 在數學上又緊密相關（通過中間數 L），能否通過一種反向的演算法來求解 D 呢？
從這個地方能夠看出，p 和 q 是極為關鍵的，這兩個數字不泄密，幾乎無法通過公式反向計算出 D。也就是說， 對於 RSA 演算法，質數 p 和 q 絕不能被黑客獲取，否則等價於交出私鑰 。
既然不能靠搶，N = p × q，N是已知的，能不能通過 「質因數分解」 來推導 p 和 q 呢？或者說， 一旦找到一種高效的 「質因數分解」 演算法，就能夠破解 RSA 演算法了 。
幸運的是，這和上述的「離散對數求解」一樣，當下在數學上還沒有找到這種演算法，當然，也無法證明「質因數分解」是否真的是一個困難問題 。因此只能靠硬算，只是當前的算力無法在可現實的時間內完成。 這也是很多人都提到過的，「量子時代來臨，當前的加密體系就會崩潰」，從算力的角度看，或許如此吧 。
既不能搶，也不能算，能不能猜呢？也就是通過 「推測 p 和 q 進行破解」 。
p 和 q 是通過 PRNG（偽隨機數生成器）生成的，於是，又一個關鍵因素，就是採用的 偽隨機數生成器演算法要足夠隨機 。
隨機數對於密碼學極為重要，後面會專門寫一篇筆記 。
前三種攻擊方式，都是基於 「硬碰硬」 的思路，而 「中間人攻擊」 則換了一種迂迴的思路，不去嘗試破解密碼演算法，而是欺騙通信雙方，從而獲取明文。具體來說，就是： 主動攻擊者 Mallory 混入發送者和接收者之間，面對發送者偽裝成接收者，面對接收者偽裝成發送者。
這個過程可以重復多次。需要注意的是，中間人攻擊方式不僅能夠針對 RSA，還可以針對任何公鑰密碼。能夠看到，整個過程中，公鑰密碼並沒有被破譯，密碼體系也在正常運轉，但機密性卻出現了問題，即 Alice 和 Bob 之間失去了機密性，卻在 Alice 和 Mallory 以及 Mallory 和 Bob 之間保持了機密性。即使公鑰密碼強度再強大 N 倍也無濟於事。也就是說，僅僅依靠密碼演算法本身，無法防禦中間人攻擊 。
而能夠抵禦中間人攻擊的，就需要用到密碼工具箱的另一種武器 -- 認證 。在下面一篇筆記中，就將涉及這個話題。
好了，以上就是公鑰密碼的基本知識了。
公鑰密碼體系能夠完美的解決對稱密碼體系中 「密鑰配送」 這個關鍵問題，但是拋開 「中間人攻擊」 問題不談，公鑰密碼自己也有個嚴重的問題：
公鑰密碼處理速度遠遠低於對稱密碼。不僅體現在密鑰對的生成上，也體現在加解密運算處理上。
因此，在實際應用場景下，往往會將對稱密碼和公鑰密碼的優勢相結合，構建一個 「混合密碼體系」 。簡單來說： 首先用相對高效的對稱密碼對消息進行加密，保證消息的機密性；然後用公鑰密碼加密對稱密碼的密鑰，保證密鑰的機密性。
下面是混合密碼體系的加解密流程圖。整個體系分為左右兩個部分：左半部分加密會話密鑰的過程，右半部分是加密原始消息的過程。原始消息一般較長，使用對稱密碼演算法會比較高效；會話密鑰一般比較短（十幾個到幾十個位元組），即使公鑰密碼演算法運算效率較低，對會話密鑰的加解密處理也不會非常耗時。
著名的密碼軟體 PGP、SSL/TLS、視頻監控公共聯網安全建設規范（GB35114） 等應用，都運用了混合密碼系統。
好了，以上就是公鑰密碼演算法的全部內容了，拖更了很久，以後還要更加勤奮一些。
為了避免被傻啦吧唧的審核機器人處理，後面就不再附漂亮姑娘的照片（也是為了你們的健康），改成我的攝影作品，希望不要對收視率產生影響，雖然很多小伙兒就是沖著姑娘來的。
就從喀納斯之旅開始吧。
⑺ 加密演算法套件怎麼根據需要選擇
SSL 支持各種各樣的加密套件，這些加密套件指定一組供連接使用的演算法。這些演算法的
強度從非常弱的可出口型（如40 位模式的RC4）到強度非常之高的（希望是這樣）如3DES。
此外，非對稱密鑰對可以使用一定范圍長度的密鑰。SSL 連接的安全自然而然就全部有賴於
它所使用的加密演算法的安全，因此應選擇與你的數據價值相當的加密套件。
為了做到這一點，就要根據你的應用程序所能支持的對加密套件**加以限制。由於客
戶端與伺服器必須就共同的加密套件達成一致才能進行通信，所以這樣將確保你能獲得相應
級別的安全。然而，一種可能的副作用就是伺服器與客戶端可能沒有共同的演算法**，因而
也就無法進行通信。因此，通常最好的策略是允許提供超過可接受的最低安全級別的所有加
密套件，而不只是專選支持最高強度的加密演算法。
⑻ 如何查看本機能夠支持的https加密演算法套件
HTTPS加密演算法，來自於簽發機構的SSL證書CSR文件，也就是說簽發完畢的證書加密演算法，就一定定向了，您可以打開這個網站，就說明就是支持，演算法：sha256 加密位數：2048，是證書常見的標准，你可以打開網路知道，就說明支持的。
⑼ 常見加密演算法原理及概念
在安全領域，利用密鑰加密演算法來對通信的過程進行加密是一種常見的安全手段。利用該手段能夠保障數據安全通信的三個目標：
而常見的密鑰加密演算法類型大體可以分為三類：對稱加密、非對稱加密、單向加密。下面我們來了解下相關的演算法原理及其常見的演算法。
對稱加密演算法採用單密鑰加密，在通信過程中，數據發送方將原始數據分割成固定大小的塊，經過密鑰和加密演算法逐個加密後，發送給接收方；接收方收到加密後的報文後，結合密鑰和解密演算法解密組合後得出原始數據。由於加解密演算法是公開的，因此在這過程中，密鑰的安全傳遞就成為了至關重要的事了。而密鑰通常來說是通過雙方協商，以物理的方式傳遞給對方，或者利用第三方平台傳遞給對方，一旦這過程出現了密鑰泄露，不懷好意的人就能結合相應的演算法攔截解密出其加密傳輸的內容。
對稱加密演算法擁有著演算法公開、計算量小、加密速度和效率高得特定，但是也有著密鑰單一、密鑰管理困難等缺點。
常見的對稱加密演算法有：
DES：分組式加密演算法，以64位為分組對數據加密，加解密使用同一個演算法。
3DES：三重數據加密演算法，對每個數據塊應用三次DES加密演算法。
AES：高級加密標准演算法，是美國聯邦政府採用的一種區塊加密標准，用於替代原先的DES，目前已被廣泛應用。
Blowfish：Blowfish演算法是一個64位分組及可變密鑰長度的對稱密鑰分組密碼演算法，可用來加密64比特長度的字元串。
非對稱加密演算法採用公鑰和私鑰兩種不同的密碼來進行加解密。公鑰和私鑰是成對存在，公鑰是從私鑰中提取產生公開給所有人的，如果使用公鑰對數據進行加密，那麼只有對應的私鑰才能解密，反之亦然。
下圖為簡單非對稱加密演算法的常見流程：
發送方Bob從接收方Alice獲取其對應的公鑰，並結合相應的非對稱演算法將明文加密後發送給Alice；Alice接收到加密的密文後，結合自己的私鑰和非對稱演算法解密得到明文。這種簡單的非對稱加密演算法的應用其安全性比對稱加密演算法來說要高，但是其不足之處在於無法確認公鑰的來源合法性以及數據的完整性。
非對稱加密演算法具有安全性高、演算法強度負復雜的優點，其缺點為加解密耗時長、速度慢，只適合對少量數據進行加密，其常見演算法包括：
RSA ：RSA演算法基於一個十分簡單的數論事實：將兩個大素數相乘十分容易，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰，可用於加密，也能用於簽名。
DSA ：數字簽名演算法，僅能用於簽名，不能用於加解密。
DSS ：數字簽名標准，技能用於簽名，也可以用於加解密。
ELGamal ：利用離散對數的原理對數據進行加解密或數據簽名，其速度是最慢的。
單向加密演算法常用於提取數據指紋，驗證數據的完整性。發送者將明文通過單向加密演算法加密生成定長的密文串，然後傳遞給接收方。接收方在收到加密的報文後進行解密，將解密獲取到的明文使用相同的單向加密演算法進行加密，得出加密後的密文串。隨後將之與發送者發送過來的密文串進行對比，若發送前和發送後的密文串相一致，則說明傳輸過程中數據沒有損壞；若不一致，說明傳輸過程中數據丟失了。單向加密演算法只能用於對數據的加密，無法被解密，其特點為定長輸出、雪崩效應。常見的演算法包括：MD5、sha1、sha224等等，其常見用途包括：數字摘要、數字簽名等等。
密鑰交換IKE（Internet Key Exchange）通常是指雙方通過交換密鑰來實現數據加密和解密，常見的密鑰交換方式有下面兩種：
1、公鑰加密，將公鑰加密後通過網路傳輸到對方進行解密，這種方式缺點在於具有很大的可能性被攔截破解，因此不常用；
2、Diffie-Hellman，DH演算法是一種密鑰交換演算法，其既不用於加密，也不產生數字簽名。DH演算法的巧妙在於需要安全通信的雙方可以用這個方法確定對稱密鑰。然後可以用這個密鑰進行加密和解密。但是注意，這個密鑰交換協議/演算法只能用於密鑰的交換，而不能進行消息的加密和解密。雙方確定要用的密鑰後，要使用其他對稱密鑰操作加密演算法實際加密和解密消息。DH演算法通過雙方共有的參數、私有參數和演算法信息來進行加密，然後雙方將計算後的結果進行交換，交換完成後再和屬於自己私有的參數進行特殊演算法，經過雙方計算後的結果是相同的，此結果即為密鑰。
如：
在整個過程中，第三方人員只能獲取p、g兩個值，AB雙方交換的是計算後的結果，因此這種方式是很安全的。
公鑰基礎設施是一個包括硬體、軟體、人員、策略和規程的集合，用於實現基於公鑰密碼機制的密鑰和證書的生成、管理、存儲、分發和撤銷的功能，其組成包括：簽證機構CA、注冊機構RA、證書吊銷列表CRL和證書存取庫CB。
PKI採用證書管理公鑰，通過第三方可信任CA中心，把用戶的公鑰和其他用戶信息組生成證書，用於驗證用戶的身份。
公鑰證書是以數字簽名的方式聲明，它將公鑰的值綁定到持有對應私鑰的個人、設備或服務身份。公鑰證書的生成遵循X.509協議的規定，其內容包括：證書名稱、證書版本、序列號、演算法標識、頒發者、有效期、有效起始日期、有效終止日期、公鑰 、證書簽名等等的內容。
CA證書認證的流程如下圖，Bob為了向Alice證明自己是Bob和某個公鑰是自己的，她便向一個Bob和Alice都信任的CA機構申請證書，Bob先自己生成了一對密鑰對（私鑰和公鑰），把自己的私鑰保存在自己電腦上，然後把公鑰給CA申請證書，CA接受申請於是給Bob頒發了一個數字證書，證書中包含了Bob的那個公鑰以及其它身份信息，當然，CA會計算這些信息的消息摘要並用自己的私鑰加密消息摘要（數字簽名）一並附在Bob的證書上，以此來證明這個證書就是CA自己頒發的。Alice得到Bob的證書後用CA的證書（自簽署的）中的公鑰來解密消息摘要，隨後將摘要和Bob的公鑰發送到CA伺服器上進行核對。CA在接收到Alice的核對請求後，會根據Alice提供的信息核對Bob的證書是否合法，如果確認合法則回復Alice證書合法。Alice收到CA的確認回復後，再去使用從證書中獲取的Bob的公鑰加密郵件然後發送給Bob，Bob接收後再以自己的私鑰進行解密。