1. 程式人生 > >對 【對稱加密和非對稱加密以及CA】的理解(二)

對 【對稱加密和非對稱加密以及CA】的理解(二)

非對稱加密更加安全但是費時費力,對稱加密雖然省時,快速但是不安全,於是就可以將它倆結合起來使用。

結合思路是這樣的:檔案傳輸用對稱加密,對稱加密的加密和解密用的都是同一個金鑰,用非對稱加密的公鑰對此對稱加密的金鑰進行加密,然後傳送出去,接收方用非對稱加密的私鑰對剛才用公鑰加密過的對稱加密的金鑰進行解密,得到對稱加密的金鑰,然後用此金鑰對加密後的檔案進行解密。這樣既用到了對稱加密的簡單高效,也用到了非對稱加密的安全。

非對稱加密的一種應用:數字簽名 

可以保證資訊傳輸的完整性、傳送者的身份驗證、防止交易中的抵賴發生。那麼是怎麼實現的呢?

1、保證資訊傳輸的完整性

假設現在A要給B發文件。A有自己的公鑰和私鑰, A將要傳送的檔案進行 單向雜湊函式進行處理,得到了一個固定的128位長度的摘要。A此時用自己的私鑰將這個 摘要給加密, 此時摘要編變成了 加密摘要,也可稱之為是A的數字簽名。此時A將自己的 公鑰、A的數字簽名(即加密後的摘要)、A要傳送的檔案 這3個東西傳送給了B。【A是不能對簽名之後的內容進行修改的,否則則A的私鑰失效,因為用A的公鑰已經解不開這個加密的摘要了】注意檔案並沒有被加密,此處是驗證一致性,即檔案是否被更改(通俗點說就是    上級給你的任務 中途有沒有被人給做了手腳,將任務改變)。B收到了A的公鑰,B收到了A的數字簽名後,B用A發來的A的公鑰對此數字簽名進行解密,得到了A生成的未加密的128位摘要。 B也收到了這個檔案,B也用單向雜湊函式對這個檔案進行處理也得到了固定的128位長度的摘要,B用此時這個摘要同剛才對A數字簽名解密後的摘要進行對比,若2次的摘要相同,則證明,傳輸前後,檔案的內容沒有被改變。因為是單向雜湊函式函式,所以檔案稍有變動,生成的摘要就會不同。  若2次的摘要不同,則證明檔案已經發生了變化。  

在我們之前下載大型遊戲,或者在Apache官網下載東西或者別處等等、往往會有驗證演算法,比如MD5和SHA,來對我們的下載的東西做完整性檢驗,通過相同的演算法,如果我們生成的 碼和伺服器端的存放的碼不同,則證明我們下載的檔案已經和原版有不同了。它們的原理和上面都是一樣的。

2、傳送者的身份驗證

假如此刻A不承認這3個東西是他發的呢(但事實上就是A發的)?B要怎麼論證呢?

所以就有了:電子商務認證授權機構(CA, Certificate Authority),也稱為電子商務認證中心,是負責發放和管理數字證書的權威機構,並作為電子商務交易中受信任的第三方,承擔公鑰體系中公鑰的合法性檢驗的責任。

A想發文件給B,但是B收到了,B要怎麼確認是A發的而不是別人發的呢?

A就需要一個擔保機構 CA。 A在傳送前先把自己的相關資訊,比如公鑰和私鑰等傳送給 CA 機構, CA也有自己的公鑰和私鑰,CA對A的公鑰和私鑰進行簽名,(即用CA的私鑰對此加密)。將簽名後的 A的公鑰和私鑰傳回給A。A要給B發文件,A此時將檔案、以及A的私鑰加密後的摘要(即數字簽名)、有CA簽名的A的公鑰傳送給B。 B收到後,必須得信任這個 CA機構後,得到CA的公鑰,用CA的公鑰檢查 , 有CA簽名的A的公鑰。若一致後,得到了A的公鑰,再用A的公鑰解A的數字簽名。就可以驗證檔案是否完整,,A也不得不承認就是他發的,因為B拿到的是CA簽名的A的公鑰。

總結一下CA作用:1 、為企業和個人進行證書頒發,確認企業和個人的身份。2 。公佈“證書吊銷列表”,來讓別的企業進行核對。(假如在上述場景,A企業的證書丟失了,為了防止別人冒充,A就會向CA掛失,CA就可以先將A的證書置入“證書吊銷列表”。假如B想和A交易, B一看CA機構的列表,上面有些A的證書已經不是他本人了。A和B就可以進一步的協商,防止被騙。)