<abbr id="nhvpa"><tbody id="nhvpa"></tbody></abbr>
    <noscript id="nhvpa"></noscript>

    <ruby id="nhvpa"></ruby>
  1. 當(dāng)前位置:首頁 > 知識 >

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

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

    我們先看一個例子,小明和小紅要進行通信,但是不想被其他人知道通信的內(nèi)容,所以雙方?jīng)Q定采用對稱加密的方式。他們做了下麵的事情:

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

    2、雙方確定密鑰

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

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

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

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

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

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

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

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

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

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

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

    回到剛才的例子,小明和下紅經(jīng)過研究發(fā)現(xiàn)非對稱加密能解決他們通信的安全問題,於是做了下麵的事情:

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

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

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

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

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

    以上過程是一次完整的request和response。通過這個例子我們梳理出一次信息傳輸?shù)姆菍ΨQ加、解密過程:

    1、消息接收方準(zhǔn)備好公鑰和私鑰

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

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

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

    公鑰隻能用做數(shù)據(jù)加密。公鑰加密的數(shù)據(jù),隻能用對應(yīng)的私鑰才能解密。這是非對稱加密的核心概念。

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

    我有下圖這樣一個信箱。

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

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

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

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

    密文=明文^E mod N

    明文=密文^D mod N

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

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

    1、求 N

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

    N=a*b

    2、求 L

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

    3、求 E(公鑰)

    E 有兩個限製:

    1<E<

    E和L的最大公約數(shù)為1

    第一個條件限製了 E 的取值範(fàn)圍,第二個條件是為了保證有與 E 對應(yīng)的解密時用到的 D。

    4、求 D(私鑰)

    D 也有兩個限製條件:

    1<D<L

    E*D mod L = 1

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

    由於原理涉及很多數(shù)學(xué)知識,這裏就不展開細(xì)講,我們隻需要了解這個過程中用到這幾個數(shù)字及公式。這是理解RSA 安全性的基礎(chǔ)。

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

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

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

    E*D mod L = 1

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

    等等,N 是公開的,而 N = a*b。那麼是否可以對 N 進行質(zhì)因數(shù)分解求得 a 和 b 呢?好在人類還未發(fā)現(xiàn)高效進行質(zhì)因數(shù)分解的方法,因此可以認(rèn)為做質(zhì)因數(shù)分解非常困難。

    但是一旦某一天發(fā)現(xiàn)了快速做質(zhì)因數(shù)分解的算法,那麼 RSA 就不再安全

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

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

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

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

    要防範(fàn)中間人,我們需要使用公鑰證書。這部分內(nèi)容在下一篇文章裏會做介紹。

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

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

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

    3、1024 bit 的 RSA不應(yīng)該在被新的應(yīng)用使用。至少要 2048 bit 的 RSA。

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

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

    猜你喜歡

    微信二維碼

    微信二維碼
    欧美国产精品久久高清| 亚洲精品国产美女久久久| 婷婷久久久亚洲欧洲日产国码AV| 国产免费久久精品丫丫| 人妻少妇久久中文字幕| 无码人妻久久一区二区三区免费| 成人综合久久精品色婷婷| 久久这里都是精品| 久久午夜无码鲁丝片秋霞| 久久精品国产日本波多野结衣| 7777精品伊人久久久大香线蕉| 麻豆久久| 色8久久人人97超碰香蕉987| 色偷偷偷久久伊人大杳蕉| 国产精品久久久久久吹潮| 91精品婷婷国产综合久久| 国产精品欧美久久久久天天影视| 99久久精品国产综合一区 | 久久久亚洲欧洲日产国码aⅴ | 国产精品免费看久久久香蕉| 国产精品久久久久一区二区三区| 久久人人超碰精品CAOPOREN| 午夜精品久久久久| 久久人人爽人人爽人人片AV不| 办公室久久精品| 国产亚洲美女精品久久久2020| 91精品国产高清91久久久久久| 国产成人AV综合久久| 狠狠色综合网站久久久久久久高清 | 无码精品久久久久久人妻中字| 国产精品久久午夜夜伦鲁鲁| 精品无码久久久久久久久久 | 久久99精品久久久久久秒播| 久久国内免费视频| 狠狠干狠狠久久| 久久精品国产免费观看三人同眠| 久久91精品国产91久久小草| 亚洲欧洲精品成人久久曰影片 | 久久婷婷五月综合97色一本一本| 国产精品女同一区二区久久| 久久久SS麻豆欧美国产日韩|