導航:首頁 > 文檔加密 > 圖示對稱加密

圖示對稱加密

發布時間:2024-06-26 11:42:57

A. 用圖示說明對稱加密技術和非對稱加密技術相結合(即數字信封技術)的工作過程。

數字信封技術用於保證資料在傳輸過程中的安全。對稱密鑰加密和公鑰加密技術各有其優缺點,對稱密鑰加密演算法效率高,但密鑰的憤發和管理都很困難;而公鑰加密演算法密鑰易於管理和傳遞,但運行效率太低,不適於加密大量的消息,而且它要求被加密的信息塊長度要小於密鑰的長度。數字信封技術結合了密鑰加密技術和公鑰加密技術各自的優點,克服了密鑰加密技術中密鑰分發和管理困難和公鑰加密技術中加解密效率低的缺點,充分利用了密鑰系統的高效性和公鑰系統的靈活性,保證信息在傳輸過程中的靈活性。
數字信封技術首先使用密鑰加密技術對要發送的消息進行加密;再利用公鑰加密技術對密鑰系統中使用的密鑰進行加密。然後把加密的消息和加密的密鑰一起傳送給接收方。其具體的實現方法和步驟如下:

說明:以上圖中的步驟可以解釋為:
①在需要發送信息時,發送方Alice先生成一個對稱密鑰K;
②Alice利用生成的對稱密鑰K和相應的對稱密鑰演算法E( • )對要發送的明文消息P進行加密,生成密文C=Ek(P);
③然後Alice再用接收方Bob提供的公鑰KpB 對剛才用到的加密明文P的密鑰K進行加密,得到加密後的密鑰Ck;
④Alice把加密後的消息C和加密後的對稱密鑰Ck作為密文一起傳送給Bob。
⑤Bob接收到密文後,先用自己的私鑰解密Ck還原出對稱密鑰K,然後再用得到的K,根據實現商定好的對稱密鑰演算法解密得到明文P。

數字信封技術實際上是使用雙層加密體制。在內層,利用對稱密鑰加密技術,每次傳送消息都可以重新生成新的對稱密鑰,實現了一次一密,保證了信息的安全性。在外層,使用公鑰加密技術對對稱密鑰進行加密,保證對稱密鑰傳輸的安全性。數字信封技術的應用,使資料信息在公共為了中的傳輸有了安全保障。

B. AES加解密使用總結

AES, 高級加密標准, 是採用區塊加密的一種標准, 又稱Rijndael加密法. 嚴格上來講, AES和Rijndael又不是完全一樣, AES的區塊長度固定為128比特, 秘鑰長度可以是128, 192或者256. Rijndael加密法可以支持更大范圍的區塊和密鑰長度, Rijndael使用的密鑰和區塊長度均可以是128,192或256比特. AES是對稱加密最流行的演算法之一.

我們不去討論具體的AES的實現, 因為其中要運用到大量的高等數學知識, 單純的了解AES流程其實也沒什麼意義(沒有數學基礎難以理解), 所以我們今天著重來總結一些使用過程中的小點.

當然了分組密碼的加密模式不僅僅是ECB和CBC這兩種, 其他的我們暫不涉及.

上面說的AES是一種區塊加密的標准, 那加密模式其實可以理解為處理不同區塊的方式和聯系.

ECB可以看做最簡單的模式, 需要加密的數據按照區塊的大小分為N個塊, 並對每個塊獨立的進行加密

此種方法的缺點在於同樣的明文塊會被加密成相同的密文塊, 因此, 在某些場合, 這種方法不能提供嚴格的數據保密性. 通過下面圖示例子大家就很容易明白了

我們的項目中使用的就是這種模式, 在CBC模式中, 每個明文塊與前一個塊的加密結果進行異或後, 在進行加密, 所以每個塊的加密都依賴前面塊的加密結果的, 同時為了保證第一個塊的加密, 在第一個塊中需要引入初始化向量iv.

CBC是最常用的模式. 他的缺點是加密過程只能是串列的, 無法並行, 因為每個塊的加密要依賴到前一個塊的加密結果, 同時在加密的時候明文中的細微改變, 會導致後面所有的密文塊都發生變化. 但此種模式也是有優點的, 在解密的過程中, 每個塊的解密依賴上一個塊的加密結果, 所以我們要解密一個塊的時候, 只需要把他前面一個塊也一起讀取, 就可以完成本塊的解密, 所以這個過程是可以並行操作的.

AES加密每個塊blockSize是128比特, 那如果我們要加密的數據不是128比特的倍數, 就會存在最後一個分塊不足128比特, 那這個塊怎麼處理, 就用到了填充模式. 下面是常用的填充模式.

PKCS7可用於填充的塊大小為1-255比特, 填充方式也很容易理解, 使用需填充長度的數值paddingSize 所表示的ASCII碼 paddingChar = chr(paddingSize)對數據進行冗餘填充. (後面有解釋)

PKCS5隻能用來填充8位元組的塊

我們以AES(128)為例, 數據塊長度為128比特, 16位元組, 使用PKCS7填充時, 填充長度為1-16. 注意, 當加密長度是16整數倍時, 反而填充長度是最大的, 要填充16位元組. 原因是 "PKCS7" 拆包時會按協議取最後一個位元組所表徵的數值長度作為數據填充長度, 如果因真實數據長度恰好為16的整數倍而不進行填充, 則拆包時會導致真實數據丟失.

舉一個blockSize為8位元組的例子

第二個塊中不足8位元組, 差4個位元組, 所以用4個4來填充

嚴格來講 PKCS5不能用於AES, 因為AES最小是128比特(16位元組), 只有在使用DES此類blockSize為64比特演算法時, 考慮使用PKCS5

我們的項目最開始加解密庫使用了CryptoSwift, 後來發現有性能問題, 就改為使用IDZSwiftCommonCrypto.

這里咱們結合項目中邊下邊播邊解密來提一個點, 具體的可以參考之前寫的 邊下邊播的總結 . 因為播放器支持拖動, 所以我們在拖拽到一個點, 去網路拉取對應數據時, 應做好range的修正, 一般我們都會以range的start和end為基準, 向前後找到包含這個range的所有塊范圍. 打比方說我們需要的range時10-20, 這是我們應該修正range為0-31, 因為起點10在0-15中, 20 在16-31中. 這是常規的range修正.(第一步 找16倍數點).

但是在實際中, 我們請求一段數據時, 還涉及到解密器的初始化問題, 如果我們是請求的0-31的數據, 因為是從0開始, 所以我們的解密器只需要用key和初始的iv來進行初始化, 那如果經過了第一步的基本range修正後, 我們請求的數據不是從0開始, 那我們則還需要繼續往前讀取16個位元組的數據, 舉個例子, 經過第一步修正後的range為16-31, 那我們應該再往前讀取16位元組, 應該是要0-31 這32個位元組數據, 拿到數據後,使用前16個位元組(上一個塊的密文)當做iv來初始化解密器.

還有一個要注意的點是, 數據解密的過程中, 還有可能會吞掉後面16個位元組的數據, 我暫時沒看源碼, 不知道具體因為什麼, 所以保險起見, 我們的range最好是再向後讀取6個位元組.

感謝閱讀

參考資料

https://zh.wikipedia.org/zh-cn/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86
https://segmentfault.com/a/1190000019793040
https://ithelp.ithome.com.tw/articles/10250386

C. 區塊鏈技術中的哈希演算法是什麼

1.1. 簡介

計算機行業從業者對哈希這個詞應該非常熟悉,哈希能夠實現數據從一個維度向另一個維度的映射,通常使用哈希函數實現這種映射。通常業界使用y = hash(x)的方式進行表示,該哈希函數實現對x進行運算計算出一個哈希值y。
區塊鏈中哈希函數特性:

D. 【深度知識】區塊鏈之加密原理圖示(加密,簽名)

先放一張以太坊的架構圖:

在學習的過程中主要是採用單個模塊了學習了解的,包括P2P,密碼學,網路,協議等。直接開始總結:

秘鑰分配問題也就是秘鑰的傳輸問題,如果對稱秘鑰,那麼只能在線下進行秘鑰的交換。如果在線上傳輸秘鑰,那就有可能被攔截。所以採用非對稱加密,兩把鑰匙,一把私鑰自留,一把公鑰公開。公鑰可以在網上傳輸。不用線下交易。保證數據的安全性。

如上圖,A節點發送數據到B節點,此時採用公鑰加密。A節點從自己的公鑰中獲取到B節點的公鑰對明文數據加密,得到密文發送給B節點。而B節點採用自己的私鑰解密。

2、無法解決消息篡改。

如上圖,A節點採用B的公鑰進行加密,然後將密文傳輸給B節點。B節點拿A節點的公鑰將密文解密。

1、由於A的公鑰是公開的,一旦網上黑客攔截消息,密文形同虛設。說白了,這種加密方式,只要攔截消息,就都能解開。

2、同樣存在無法確定消息來源的問題,和消息篡改的問題。

如上圖,A節點在發送數據前,先用B的公鑰加密,得到密文1,再用A的私鑰對密文1加密得到密文2。而B節點得到密文後,先用A的公鑰解密,得到密文1,之後用B的私鑰解密得到明文。

1、當網路上攔截到數據密文2時, 由於A的公鑰是公開的,故可以用A的公鑰對密文2解密,就得到了密文1。所以這樣看起來是雙重加密,其實最後一層的私鑰簽名是無效的。一般來講,我們都希望簽名是簽在最原始的數據上。如果簽名放在後面,由於公鑰是公開的,簽名就缺乏安全性。

2、存在性能問題,非對稱加密本身效率就很低下,還進行了兩次加密過程。

如上圖,A節點先用A的私鑰加密,之後用B的公鑰加密。B節點收到消息後,先採用B的私鑰解密,然後再利用A的公鑰解密。

1、當密文數據2被黑客攔截後,由於密文2隻能採用B的私鑰解密,而B的私鑰只有B節點有,其他人無法機密。故安全性最高。
2、當B節點解密得到密文1後, 只能採用A的公鑰來解密。而只有經過A的私鑰加密的數據才能用A的公鑰解密成功,A的私鑰只有A節點有,所以可以確定數據是由A節點傳輸過來的。

經兩次非對稱加密,性能問題比較嚴重。

基於以上篡改數據的問題,我們引入了消息認證。經過消息認證後的加密流程如下:

當A節點發送消息前,先對明文數據做一次散列計算。得到一個摘要, 之後將照耀與原始數據同時發送給B節點。當B節點接收到消息後,對消息解密。解析出其中的散列摘要和原始數據,然後再對原始數據進行一次同樣的散列計算得到摘要1, 比較摘要與摘要1。如果相同則未被篡改,如果不同則表示已經被篡改。

在傳輸過程中,密文2隻要被篡改,最後導致的hash與hash1就會產生不同。

無法解決簽名問題,也就是雙方相互攻擊。A對於自己發送的消息始終不承認。比如A對B發送了一條錯誤消息,導致B有損失。但A抵賴不是自己發送的。

在(三)的過程中,沒有辦法解決交互雙方相互攻擊。什麼意思呢? 有可能是因為A發送的消息,對A節點不利,後來A就抵賴這消息不是它發送的。

為了解決這個問題,故引入了簽名。這里我們將(二)-4中的加密方式,與消息簽名合並設計在一起。

在上圖中,我們利用A節點的私鑰對其發送的摘要信息進行簽名,然後將簽名+原文,再利用B的公鑰進行加密。而B得到密文後,先用B的私鑰解密,然後 對摘要再用A的公鑰解密,只有比較兩次摘要的內容是否相同。這既避免了防篡改問題,有規避了雙方攻擊問題。因為A對信息進行了簽名,故是無法抵賴的。

為了解決非對稱加密數據時的性能問題,故往往採用混合加密。這里就需要引入對稱加密,如下圖:

在對數據加密時,我們採用了雙方共享的對稱秘鑰來加密。而對稱秘鑰盡量不要在網路上傳輸,以免丟失。這里的共享對稱秘鑰是根據自己的私鑰和對方的公鑰計算出的,然後適用對稱秘鑰對數據加密。而對方接收到數據時,也計算出對稱秘鑰然後對密文解密。

以上這種對稱秘鑰是不安全的,因為A的私鑰和B的公鑰一般短期內固定,所以共享對稱秘鑰也是固定不變的。為了增強安全性,最好的方式是每次交互都生成一個臨時的共享對稱秘鑰。那麼如何才能在每次交互過程中生成一個隨機的對稱秘鑰,且不需要傳輸呢?

那麼如何生成隨機的共享秘鑰進行加密呢?

對於發送方A節點,在每次發送時,都生成一個臨時非對稱秘鑰對,然後根據B節點的公鑰 和 臨時的非對稱私鑰 可以計算出一個對稱秘鑰(KA演算法-Key Agreement)。然後利用該對稱秘鑰對數據進行加密,針對共享秘鑰這里的流程如下:

對於B節點,當接收到傳輸過來的數據時,解析出其中A節點的隨機公鑰,之後利用A節點的隨機公鑰 與 B節點自身的私鑰 計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。

對於以上加密方式,其實仍然存在很多問題,比如如何避免重放攻擊(在消息中加入 Nonce ),再比如彩虹表(參考 KDF機制解決 )之類的問題。由於時間及能力有限,故暫時忽略。

那麼究竟應該採用何種加密呢?

主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以,但是很重要的數據就需要採用安全等級比較高的加密方案了。

密碼套件 是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。

在整個網路的傳輸過程中,根據密碼套件主要分如下幾大類演算法:

秘鑰交換演算法:比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。

消息認證演算法:比如SHA1、SHA2、SHA3。主要用於消息摘要。

批量加密演算法:比如AES, 主要用於加密信息流。

偽隨機數演算法:例如TLS 1.2的偽隨機函數使用MAC演算法的散列函數來創建一個 主密鑰 ——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰(例如創建MAC)時作為一個熵來源。

在網路中,一次消息的傳輸一般需要在如下4個階段分別進行加密,才能保證消息安全、可靠的傳輸。

握手/網路協商階段:

在雙方進行握手階段,需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等

身份認證階段:

身份認證階段,需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密,DSA簽名)等。

消息加密階段:

消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。

消息身份認證階段/防篡改階段:

主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。

ECC :Elliptic Curves Cryptography,橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成 公鑰、私鑰的演算法。用於生成公私秘鑰。

ECDSA :用於數字簽名,是一種數字簽名演算法。一種有效的數字簽名使接收者有理由相信消息是由已知的發送者創建的,從而發送者不能否認已經發送了消息(身份驗證和不可否認),並且消息在運輸過程中沒有改變。ECDSA簽名演算法是ECC與DSA的結合,整個簽名過程與DSA類似,所不一樣的是簽名中採取的演算法為ECC,最後簽名出來的值也是分為r,s。 主要用於身份認證階段

ECDH :也是基於ECC演算法的霍夫曼樹秘鑰,通過ECDH,雙方可以在不共享任何秘密的前提下協商出一個共享秘密,並且是這種共享秘鑰是為當前的通信暫時性的隨機生成的,通信一旦中斷秘鑰就消失。 主要用於握手磋商階段。

ECIES: 是一種集成加密方案,也可稱為一種混合加密方案,它提供了對所選擇的明文和選擇的密碼文本攻擊的語義安全性。ECIES可以使用不同類型的函數:秘鑰協商函數(KA),秘鑰推導函數(KDF),對稱加密方案(ENC),哈希函數(HASH), H-MAC函數(MAC)。

ECC 是橢圓加密演算法,主要講述了按照公私鑰怎麼在橢圓上產生,並且不可逆。 ECDSA 則主要是採用ECC演算法怎麼來做簽名, ECDH 則是採用ECC演算法怎麼生成對稱秘鑰。以上三者都是對ECC加密演算法的應用。而現實場景中,我們往往會採用混合加密(對稱加密,非對稱加密結合使用,簽名技術等一起使用)。 ECIES 就是底層利用ECC演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密,對稱加密和簽名的功能。

<meta charset="utf-8">

這個先訂條件是為了保證曲線不包含奇點。

所以,隨著曲線參數a和b的不斷變化,曲線也呈現出了不同的形狀。比如:

所有的非對稱加密的基本原理基本都是基於一個公式 K = k G。其中K代表公鑰,k代表私鑰,G代表某一個選取的基點。非對稱加密的演算法 就是要保證 該公式 不可進行逆運算( 也就是說G/K是無法計算的 )。 *

ECC是如何計算出公私鑰呢?這里我按照我自己的理解來描述。

我理解,ECC的核心思想就是:選擇曲線上的一個基點G,之後隨機在ECC曲線上取一個點k(作為私鑰),然後根據k G計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*

那麼k G怎麼計算呢?如何計算k G才能保證最後的結果不可逆呢?這就是ECC演算法要解決的。

首先,我們先隨便選擇一條ECC曲線,a = -3, b = 7 得到如下曲線:

在這個曲線上,我隨機選取兩個點,這兩個點的乘法怎麼算呢?我們可以簡化下問題,乘法是都可以用加法表示的,比如2 2 = 2+2,3 5 = 5+5+5。 那麼我們只要能在曲線上計算出加法,理論上就能算乘法。所以,只要能在這個曲線上進行加法計算,理論上就可以來計算乘法,理論上也就可以計算k*G這種表達式的值。

曲線上兩點的加法又怎麼算呢?這里ECC為了保證不可逆性,在曲線上自定義了加法體系。

現實中,1+1=2,2+2=4,但在ECC演算法里,我們理解的這種加法體系是不可能。故需要自定義一套適用於該曲線的加法體系。

ECC定義,在圖形中隨機找一條直線,與ECC曲線相交於三個點(也有可能是兩個點),這三點分別是P、Q、R。

那麼P+Q+R = 0。其中0 不是坐標軸上的0點,而是ECC中的無窮遠點。也就是說定義了無窮遠點為0點。

同樣,我們就能得出 P+Q = -R。 由於R 與-R是關於X軸對稱的,所以我們就能在曲線上找到其坐標。

P+R+Q = 0, 故P+R = -Q , 如上圖。

以上就描述了ECC曲線的世界裡是如何進行加法運算的。

從上圖可看出,直線與曲線只有兩個交點,也就是說 直線是曲線的切線。此時P,R 重合了。

也就是P = R, 根據上述ECC的加法體系,P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0

於是乎得到 2 P = -Q (是不是與我們非對稱演算法的公式 K = k G 越來越近了)。

於是我們得出一個結論,可以算乘法,不過只有在切點的時候才能算乘法,而且只能算2的乘法。

假若 2 可以變成任意個數進行想乘,那麼就能代表在ECC曲線里可以進行乘法運算,那麼ECC演算法就能滿足非對稱加密演算法的要求了。

那麼我們是不是可以隨機任何一個數的乘法都可以算呢? 答案是肯定的。 也就是點倍積 計算方式。

選一個隨機數 k, 那麼k * P等於多少呢?

我們知道在計算機的世界裡,所有的都是二進制的,ECC既然能算2的乘法,那麼我們可以將隨機數k描 述成二進制然後計算。假若k = 151 = 10010111

由於2 P = -Q 所以 這樣就計算出了k P。 這就是點倍積演算法 。所以在ECC的曲線體系下是可以來計算乘法,那麼以為這非對稱加密的方式是可行的。

至於為什麼這樣計算 是不可逆的。這需要大量的推演,我也不了解。但是我覺得可以這樣理解:

我們的手錶上,一般都有時間刻度。現在如果把1990年01月01日0點0分0秒作為起始點,如果告訴你至起始點為止時間流逝了 整1年,那麼我們是可以計算出現在的時間的,也就是能在手錶上將時分秒指針應該指向00:00:00。但是反過來,我說現在手錶上的時分秒指針指向了00:00:00,你能告訴我至起始點算過了有幾年了么?

ECDSA簽名演算法和其他DSA、RSA基本相似,都是採用私鑰簽名,公鑰驗證。只不過演算法體系採用的是ECC的演算法。交互的雙方要採用同一套參數體系。簽名原理如下:

在曲線上選取一個無窮遠點為基點 G = (x,y)。隨機在曲線上取一點k 作為私鑰, K = k*G 計算出公鑰。

簽名過程:

生成隨機數R, 計算出RG.

根據隨機數R,消息M的HASH值H,以及私鑰k, 計算出簽名S = (H+kx)/R.

將消息M,RG,S發送給接收方。

簽名驗證過程:

接收到消息M, RG,S

根據消息計算出HASH值H

根據發送方的公鑰K,計算 HG/S + xK/S, 將計算的結果與 RG比較。如果相等則驗證成功。

公式推論:

HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG

在介紹原理前,說明一下ECC是滿足結合律和交換律的,也就是說A+B+C = A+C+B = (A+C)+B。

這里舉一個WIKI上的例子說明如何生成共享秘鑰,也可以參考 Alice And Bob 的例子。

Alice 與Bob 要進行通信,雙方前提都是基於 同一參數體系的ECC生成的 公鑰和私鑰。所以有ECC有共同的基點G。

生成秘鑰階段:

Alice 採用公鑰演算法 KA = ka * G ,生成了公鑰KA和私鑰ka, 並公開公鑰KA。

Bob 採用公鑰演算法 KB = kb * G ,生成了公鑰KB和私鑰 kb, 並公開公鑰KB。

計算ECDH階段:

Alice 利用計算公式 Q = ka * KB 計算出一個秘鑰Q。

Bob 利用計算公式 Q' = kb * KA 計算出一個秘鑰Q'。

共享秘鑰驗證:

Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'

故 雙方分別計算出的共享秘鑰不需要進行公開就可採用Q進行加密。我們將Q稱為共享秘鑰。

在以太坊中,採用的ECIEC的加密套件中的其他內容:

1、其中HASH演算法採用的是最安全的SHA3演算法 Keccak 。

2、簽名演算法採用的是 ECDSA

3、認證方式採用的是 H-MAC

4、ECC的參數體系採用了secp256k1, 其他參數體系 參考這里

H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下:

以太坊 的 UDP通信時(RPC通信加密方式不同),則採用了以上的實現方式,並擴展化了。

首先,以太坊的UDP通信的結構如下:

其中,sig是 經過 私鑰加密的簽名信息。mac是可以理解為整個消息的摘要, ptype是消息的事件類型,data則是經過RLP編碼後的傳輸數據。

其UDP的整個的加密,認證,簽名模型如下:

E. 網路密鑰是什麼和WiFi密碼是一回事嗎

是的 是一樣的。
網路安全密鑰,正確的讀法為「網路安全密匙」,即你的WiFi密碼。

裝無線wifi提示輸入『網路安全密匙』只需要輸入一串8到18位數的數字與字母即可公用密鑰加密技術使用不對稱的密鑰來加密和解密,每對密鑰包含一個公鑰和一個私鑰,公鑰是公開,而且廣泛分布的,而私鑰從來不公開,只有自己知道。
互聯網路是一個開放式的系統,任何人都可以通過它共享自己的資源,獲取需要的信息。當人們在網路上進行信息交流的時候,比如聊天、收發郵件,或者登錄需要提供個人信息的站點,這些包含著重要個人資料的信息包很可能在到達最終目的地前被第三方截獲並破解。所以保護個人隱私是互聯網路的頭等大事,而使用加密密鑰是最簡單、有效的方法。信息在發送前需要按照規則進行數據的重新排列組合,打亂了原有的數據順序,這樣即便數據包被第三方截獲。

F. 常見的加密演算法、原理、優缺點、用途

在安全領域,利用密鑰加密演算法來對通信的過程進行加密是一種常見的安全手段。利用該手段能夠保障數據安全通信的三個目標:

而常見的密鑰加密演算法類型大體可以分為三類:對稱加密、非對稱加密、單向加密。下面我們來了解下相關的演算法原理及其常見的演算法。

在加密傳輸中最初是採用對稱密鑰方式,也就是加密和解密都用相同的密鑰。

1.對稱加密演算法採用單密鑰加密,在通信過程中,數據發送方將原始數據分割成固定大小的塊,經過密鑰和加密演算法逐個加密後,發送給接收方

2.接收方收到加密後的報文後,結合解密演算法使用相同密鑰解密組合後得出原始數據。

圖示:

非對稱加密演算法採用公鑰和私鑰兩種不同的密碼來進行加解密。公鑰和私鑰是成對存在,公鑰是從私鑰中提取產生公開給所有人的,如果使用公鑰對數據進行加密,那麼只有對應的私鑰(不能公開)才能解密,反之亦然。N 個用戶通信,需要2N個密鑰。

非對稱密鑰加密適合對密鑰或身份信息等敏感信息加密,從而在安全性上滿足用戶的需求。

1.甲使用乙的公鑰並結合相應的非對稱演算法將明文加密後發送給乙,並將密文發送給乙。
2.乙收到密文後,結合自己的私鑰和非對稱演算法解密得到明文,得到最初的明文。

圖示:

單向加密演算法只能用於對數據的加密,無法被解密,其特點為定長輸出、雪崩效應(少量消息位的變化會引起信息摘要的許多位變化)。

單向加密演算法常用於提取數據指紋,驗證數據的完整性、數字摘要、數字簽名等等。

1.發送者將明文通過單向加密演算法加密生成定長的密文串,然後傳遞給接收方。

2.接收方將用於比對驗證的明文使用相同的單向加密演算法進行加密,得出加密後的密文串。

3.將之與發送者發送過來的密文串進行對比,若發送前和發送後的密文串相一致,則說明傳輸過程中數據沒有損壞;若不一致,說明傳輸過程中數據丟失了。

圖示:

MD5、sha1、sha224等等

密鑰交換IKE(Internet Key Exchange)通常是指雙方通過交換密鑰來實現數據加密和解密

常見的密鑰交換方式有下面兩種:

將公鑰加密後通過網路傳輸到對方進行解密,這種方式缺點在於具有很大的可能性被攔截破解,因此不常用

DH演算法是一種密鑰交換演算法,其既不用於加密,也不產生數字簽名。

DH演算法通過雙方共有的參數、私有參數和演算法信息來進行加密,然後雙方將計算後的結果進行交換,交換完成後再和屬於自己私有的參數進行特殊演算法,經過雙方計算後的結果是相同的,此結果即為密鑰。

如:

安全性

在整個過程中,第三方人員只能獲取p、g兩個值,AB雙方交換的是計算後的結果,因此這種方式是很安全的。

答案:使用公鑰證書

公鑰基礎設施是一個包括硬體、軟體、人員、策略和規程的集合

用於實現基於公鑰密碼機制的密鑰和證書的生成、管理、存儲、分發和撤銷的功能

簽證機構CA、注冊機構RA、證書吊銷列表CRL和證書存取庫CB。

公鑰證書是以數字簽名的方式聲明,它將公鑰的值綁定到持有對應私鑰的個人、設備或服務身份。公鑰證書的生成遵循X.509協議的規定,其內容包括:證書名稱、證書版本、序列號、演算法標識、頒發者、有效期、有效起始日期、有效終止日期、公鑰 、證書簽名等等的內容。

1.客戶A准備好要傳送的數字信息(明文)。(准備明文)

2.客戶A對數字信息進行哈希(hash)運算,得到一個信息摘要。(准備摘要)

3.客戶A用CA的私鑰(SK)對信息摘要進行加密得到客戶A的數字簽名,並將其附在數字信息上。(用私鑰對數字信息進行數字簽名)

4.客戶A隨機產生一個加密密鑰(DES密鑰),並用此密鑰對要發送的信息進行加密,形成密文。 (生成密文)

5.客戶A用雙方共有的公鑰(PK)對剛才隨機產生的加密密鑰進行加密,將加密後的DES密鑰連同密文一起傳送給乙。(非對稱加密,用公鑰對DES密鑰進行加密)

6.銀行B收到客戶A傳送過來的密文和加過密的DES密鑰,先用自己的私鑰(SK)對加密的DES密鑰進行解密,得到DES密鑰。(用私鑰對DES密鑰解密)

7.銀行B然後用DES密鑰對收到的密文進行解密,得到明文的數字信息,然後將DES密鑰拋棄(即DES密鑰作廢)。(解密文)

8.銀行B用雙方共有的公鑰(PK)對客戶A的數字簽名進行解密,得到信息摘要。銀行B用相同的hash演算法對收到的明文再進行一次hash運算,得到一個新的信息摘要。(用公鑰解密數字簽名)

9.銀行B將收到的信息摘要和新產生的信息摘要進行比較,如果一致,說明收到的信息沒有被修改過。(對比信息摘要和信息)

答案是沒法保證CA的公鑰沒有被篡改。通常操作系統和瀏覽器會預制一些CA證書在本地。所以發送方應該去那些通過認證的CA處申請數字證書。這樣是有保障的。

但是如果系統中被插入了惡意的CA證書,依然可以通過假冒的數字證書發送假冒的發送方公鑰來驗證假冒的正文信息。所以安全的前提是系統中不能被人插入非法的CA證書。

END

閱讀全文

與圖示對稱加密相關的資料

熱點內容
新求精德語中級pdf 瀏覽:984
pfx項目編譯 瀏覽:123
pdf改圖 瀏覽:625
mimejava 瀏覽:603
小K同學App如何鏈接藍牙 瀏覽:70
如何創造我的世界國際版伺服器 瀏覽:116
java實例化類型 瀏覽:341
給你一個團隊pdf 瀏覽:154
伺服器忘記了角色怎麼辦 瀏覽:92
程序員會做財務季度表格嗎 瀏覽:316
javatxt編碼 瀏覽:434
姜恩惠的電影有哪些 瀏覽:690
geplc編譯有用嗎 瀏覽:143
我的世界電腦181伺服器地址大全 瀏覽:917
蘋果怎麼轉區轉安卓 瀏覽:599
推理與證明演算法初步的思維導圖 瀏覽:484
天氣預報類app如何增加客戶粘度 瀏覽:249
韓國經典愛情電影 瀏覽:500
安卓手機在國外有什麼不便 瀏覽:269
在線觀看網址入口 瀏覽:98