當前位置:首頁 » 密碼管理 » 小明看台灣加密三

小明看台灣加密三

發布時間: 2024-01-02 15:37:56

A. 加密、簽名、證書的作用及運用場景

本文主要是簡單介紹了常見的加密類型、各自的運用場景、為什麼需要數字簽名和數字證書、HTTPS涉及到的加密流程等。這里主要從使用者的角度出發,對演算法本身不做過多介紹。

對稱/非對稱加密均屬於 可逆加密,可以通過密鑰將密文還原為明文

有時候,我們希望明文一旦加密後,任何人(包括自己)都無法通過密文逆推回明文,不可逆加密就是為了滿足這種需求。
不可逆加密主要通過 hash演算法實現:即對目標數據生成一段特定長度hash值 ;無論你的數據是1KB、1MB、1GB,都是生成特定長度的一個Hash值(比如128bit)。這里大家應該能感受到一點 不可逆 的味道,加密後128bit的hash值顯然無法還原出1個G甚至更大的不規則數據的, hash可以看做是原來內容的一個摘要

常見演算法:

小明給小紅寫信:

經過九轉十八彎後,信的內容有可能:1. 被窺視 2. 被篡改(冒充小明發送假消息)

小紅先 生成對稱加密的密鑰key1 ,然後通過一個安全的渠道交予小明。
傳輸數據時,小明 使用key1加密 ,而小紅收到後再 使用key1解密
這時候 中間者既看不到原來的內容,也沒辦法篡改 (因為沒有密鑰):

【對稱加密】實現簡單,性能優秀 ,演算法本身安全級別高。然而對 密鑰的管理 卻是個很頭疼的問題:一旦密鑰交到對方手裡,對方對密鑰的保管能力 我方是沒辦法控制 的,一旦對方泄露的話,加密就形同虛設了。
相對而言,【非對稱加密】的公鑰就沒有這個憂慮,因為 公鑰 的設計就是為了 可以公開的 ,盡管對方泄露,我方也不會有任何損失。

小紅生成一對公私鑰,自己持有私鑰(pri_key1),將公鑰(pub_key1)交予小明。
傳輸數據時,小明使用 公鑰加密 ,小紅使用 私鑰解密
因為 中間者沒有私鑰,公鑰加密的內容是無法獲取的 。此時達到了 防窺視 的效果:

然而因為 公鑰是可以公開的 ,如果 中間者知曉公鑰 的話,盡管沒有辦法看到原來的內容,卻 可以冒充小明發送假消息

這時小紅在想,如果小明發送消息時,能帶上 只有他自己才能生成 的數據(字元串),我就能 驗證是不是小明發的真實消息 了。
通常這個 能證實身份的數據(字元串) 被稱之為 數字簽名(Signature)

小明再生成一對公私鑰 ,自己持有私鑰(pri_key2),將公鑰交予小紅(pub_key2)。

當小明傳輸數據時(可能很大),除了公鑰加密明文之外,還要帶上簽名:(1) 對明文做一個hash摘要 (2)對摘要進行私鑰加密,加密結果即簽名(傳輸內容=內容密文+簽名)

小紅收到後:(1) 解密簽名獲取hash (2)解密內容密文,對解密後的明文進行hash;如果兩個hash一致,說明驗簽通過。

盡管中間者修改了傳輸內容,但因為簽名無法冒認(沒有私鑰),小紅驗簽失敗,自然不會認可這份數據:

通常 非對稱加密要做到防窺視和防篡改,需要有兩對公私鑰 :對方的公鑰用於內容加密,自己的私鑰用於簽名(讓對方驗證身份)。

因為HTTP協議明文通信的安全問題,引入了HTTPS:通過建立一個安全通道(連接),來保證數據傳輸的安全。

伺服器是 沒辦法直接將密鑰傳輸到瀏覽器的 ,因為在 安全連接建立之前,所有通信內容都是明文的 ,中間者可窺視到密鑰信息。
或許這時你想到了非對稱加密,因為公鑰是不怕公開的:

然而在第2步, 中間者可以截取伺服器公鑰,並替換成了自己的公鑰 ,此時加密就沒意義了:

為了 防止公鑰被假冒,數字證書(digital certificate )便誕生了

當伺服器需要告訴瀏覽器公鑰時,並不是簡單地返回公鑰,而是響應 包含公鑰信息在內的數字證書

證書主要包含以下內容:

瀏覽器通過 【頒發機構的公鑰】進行解密驗簽 ,驗簽通過即說明證書的真實性,可以放心取 證書擁有者的公鑰 了。( 常用CA機構的公鑰都已經植入到瀏覽器裡面

數字證書只做一件事: 保證 伺服器響應的 公鑰是真實的

以上保證了 [瀏覽器⇒伺服器] 是加密的,然而 [伺服器⇒瀏覽器] 卻沒有(上圖第4步);另外一個是 性能問題 ,如果所有數據都使用非對稱加密的話,會消耗較多的伺服器資源,通信速度也會受到較大影響。
HTTPS巧妙地結合了非對稱加密和對稱加密,在保證雙方通信安全的前提下,盡量提升性能。

HTTPS(SSL/TLS)期望 建立安全連接後,通信均使用【對稱加密】
建立安全連接的任務就是讓 瀏覽器-伺服器協商出本次連接使用的【對稱加密的演算法和密鑰】 ;協商過程中會使用到【非對稱加密】和數字證書。

特別注意的是:協商的密鑰必須是不容易猜到(足夠隨機的):

其中比較核心的是隨機數r3(pre-master secret),因為之前的r1、r2都是明文傳輸的, 只有r3是加密傳輸 的。至於為什麼需要三個隨機數,可以參考:

以上是一個比較簡單的HTTPS流程,詳細的可以參考文末的引用。

參考資料:
[1] 數字證書應用綜合揭秘
[2] SSL/TLS協議運行機制的概述
[3] 圖解SSL/TLS協議
[4] 《圖解HTTP》

B. 圖文徹底搞懂非對稱加密(公鑰密鑰)

前文詳細講解了對稱加密及演算法原理。那麼是不是對稱加密就萬無一失了呢?對稱加密有一個天然的缺點,就是加密方和解密方都要持有同樣的密鑰。你可以能會提出疑問:既然要加、解密,當然雙方都要持有密鑰,這有什麼問題呢?別急,我們繼續往下看。

我們先看一個例子,小明和小紅要進行通信,但是不想被其他人知道通信的內容,所以雙方決定採用對稱加密的方式。他們做了下面的事情:

1、雙方商定了加密和解密的演算法

2、雙方確定密鑰

3、通信過程中採用這個密鑰進行加密和解密

這是不是一個看似完美的方案?但其中有一個步驟存在漏洞!

問題出在步驟2:雙方確定密鑰!

你肯定會問,雙方不確定密鑰,後面的加、解密怎麼做?

問題在於確定下來的密鑰如何讓雙方都知道。密鑰在傳遞過程中也是可能被盜取的!這里引出了一個經典問題:密鑰配送問題。

小明和小紅在商定密鑰的過程中肯定會多次溝通密鑰是什麼。即使單方一次確定下來,也要發給對方。加密是為了保證信息傳輸的安全,但密鑰本身也是信息,密鑰的傳輸安全又該如何保證呢?難不成還要為密鑰的傳輸再做一次加密?這樣不就陷入了死循環?

你是不是在想,密鑰即使被盜取,不還有加密演算法保證信息安全嗎?如果你真的有這個想法,那麼趕緊復習一下上一篇文章講的杜絕隱蔽式安全性。任何演算法最終都會被破譯,所以不能依賴演算法的復雜度來保證安全。

小明和小紅現在左右為難,想加密就要給對方發密鑰,但發密鑰又不能保證密鑰的安全。他們應該怎麼辦呢?

有如下幾種解決密鑰配送問題的方案:

非對稱加密也稱為公鑰密碼。我更願意用非對稱加密這種叫法。因為可以體現出加密和解密使用不同的密鑰。

對稱加密中,我們只需要一個密鑰,通信雙方同時持有。而非對稱加密需要4個密鑰。通信雙方各自准備一對公鑰和私鑰。其中公鑰是公開的,由信息接受方提供給信息發送方。公鑰用來對信息加密。私鑰由信息接受方保留,用來解密。既然公鑰是公開的,就不存在保密問題。也就是說非對稱加密完全不存在密鑰配送問題!你看,是不是完美解決了密鑰配送問題?

回到剛才的例子,小明和下紅經過研究發現非對稱加密能解決他們通信的安全問題,於是做了下面的事情:

1、小明確定了自己的私鑰 mPrivateKey,公鑰 mPublicKey。自己保留私鑰,將公鑰mPublicKey發給了小紅

2、小紅確定了自己的私鑰 hPrivateKey,公鑰 hPublicKey。自己保留私鑰,將公鑰 hPublicKey 發給了小明

3、小明發送信息 「周六早10點soho T1樓下見」,並且用小紅的公鑰 hPublicKey 進行加密。

4、小紅收到信息後用自己的私鑰 hPrivateKey 進行解密。然後回復 「收到,不要遲到」 並用小明的公鑰mPublicKey加密。

5、小明收到信息後用自己的私鑰 mPrivateKey 進行解密。讀取信息後心裡暗想:還提醒我不遲到?每次遲到的都是你吧?

以上過程是一次完整的request和response。通過這個例子我們梳理出一次信息傳輸的非對稱加、解密過程:

1、消息接收方准備好公鑰和私鑰

2、私鑰接收方自己留存、公鑰發布給消息發送方

3、消息發送方使用接收方公鑰對消息進行加密

4、消息接收方用自己的私鑰對消息解密

公鑰只能用做數據加密。公鑰加密的數據,只能用對應的私鑰才能解密。這是非對稱加密的核心概念。

下面我用一個更為形象的例子來幫助大家理解。

我有下圖這樣一個信箱。

由於我只想接收我期望與之通信的朋友信件。於是我在投遞口加了一把鎖,這把鎖的鑰匙(公鑰)我可以復制n份,發給我想接受其信件的人。只有這些人可以用這把鑰匙打開寄信口,把信件投入。

相信通過這個例子,可以幫助大家徹底理解公鑰和私鑰的概念。

RSA 是現在使用最為廣泛的非對稱加密演算法,本節我們來簡單介紹 RSA 加解密的過程。

RSA 加解密演算法其實很簡單:

密文=明文^E mod N

明文=密文^D mod N

RSA 演算法並不會像對稱加密一樣,用玩魔方的方式來打亂原始信息。RSA 加、解密中使用了是同樣的數 N。公鑰是公開的,意味著 N 也是公開的。所以私鑰也可以認為只是 D。

我們接下來看一看 N、E、D 是如何計算的。

1、求 N

首先需要准備兩個很大質數 a 和 b。太小容易破解,太大計算成本太高。我們可以用 512 bit 的數字,安全性要求高的可以使用 1024,2048 bit。

N=a*b

2、求 L

L 只是生成密鑰對過程中產生的數,並不參與加解密。L 是 (a-1) 和 (b-1) 的最小公倍數

3、求 E(公鑰)

E 有兩個限制:

1<E<

E和L的最大公約數為1

第一個條件限制了 E 的取值范圍,第二個條件是為了保證有與 E 對應的解密時用到的 D。

4、求 D(私鑰)

D 也有兩個限制條件:

1<D<L

E*D mod L = 1

第二個條件確保密文解密時能夠成功得到原來的明文。

由於原理涉及很多數學知識,這里就不展開細講,我們只需要了解這個過程中用到這幾個數字及公式。這是理解RSA 安全性的基礎。

由於 N 在公鑰中是公開的,那麼只需要破解 D,就可以解密得到明文。

在實際使用場景中,質數 a,b 一般至少1024 bit,那麼 N 的長度在 2048 bit 以上。D 的長度和 N 接近。以現在計算機的算力,暴力破解 D 是非常困難的。

公鑰是公開的,也就是說 E 和 N 是公開的,那麼是否可以通過 E 和 N 推斷出 D 呢?

E*D mod L = 1

想要推算出 D 就需要先推算出 L。L 是 (a-1) 和 (b-1) 的最小公倍數。想知道 L 就需要知道質數 a 和 b。破解者並不知道這兩個質數,想要破解也只能通過暴力破解。這和直接破解 D 的難度是一樣的。

等等,N 是公開的,而 N = a*b。那麼是否可以對 N 進行質因數分解求得 a 和 b 呢?好在人類還未發現高效進行質因數分解的方法,因此可以認為做質因數分解非常困難。

但是一旦某一天發現了快速做質因數分解的演算法,那麼 RSA 就不再安全

我們可以看出大質數 a 和 b 在 RSA 演算法中的重要性。保證 a 和 b 的安全也就確保了 RSA 演算法的安全性。a 和 b 是通過偽隨機生成器生成的。一旦偽隨機數生成器的演算法有問題,導致隨機性很差或者可以被推斷出來。那麼 RSA 的安全性將被徹底破壞。

中間人攻擊指的是在通信雙方的通道上,混入攻擊者。他對接收方偽裝成發送者,對放送放偽裝成接收者。

他監聽到雙方發送公鑰時,偷偷將消息篡改,發送自己的公鑰給雙方。然後自己則保存下來雙方的公鑰。

如此操作後,雙方加密使用的都是攻擊者的公鑰,那麼後面所有的通信,攻擊者都可以在攔截後進行解密,並且篡改信息內容再用接收方公鑰加密。而接收方拿到的將會是篡改後的信息。實際上,發送和接收方都是在和中間人通信。

要防範中間人,我們需要使用公鑰證書。這部分內容在下一篇文章里會做介紹。

和對稱加密相比較,非對稱加密有如下特點:

1、非對稱加密解決了密碼配送問題

2、非對稱加密的處理速度只有對稱加密的幾百分之一。不適合對很長的消息做加密。

3、1024 bit 的 RSA不應該在被新的應用使用。至少要 2048 bit 的 RSA。

RSA 解決了密碼配送問題,但是效率更低。所以有些時候,根據需求可能會配合使用對稱和非對稱加密,形成混合密碼系統,各取所長。

最後提醒大家,RSA 還可以用於簽名,但要注意是私鑰簽名,公鑰驗簽。發信方用自己的私鑰簽名,收信方用對方公鑰驗簽。關於簽名,後面的文章會再詳細講解。

熱點內容
scratch編程自學 發布:2024-11-28 16:09:15 瀏覽:825
蘇州cnc編程學徒招聘 發布:2024-11-28 16:07:44 瀏覽:610
linux中怎麼搭建http伺服器配置 發布:2024-11-28 16:04:17 瀏覽:291
緩存expires 發布:2024-11-28 16:02:27 瀏覽:383
圖像的jpeg壓縮matlab 發布:2024-11-28 16:02:05 瀏覽:940
androidcompilewith 發布:2024-11-28 16:00:19 瀏覽:435
訪問跳轉 發布:2024-11-28 15:54:44 瀏覽:698
演算法對算 發布:2024-11-28 15:41:38 瀏覽:4
稱重系統界面如何找配置項 發布:2024-11-28 15:28:29 瀏覽:570
vue能被反編譯嘛 發布:2024-11-28 15:23:59 瀏覽:80