資訊專欄INFORMATION COLUMN
摘要：實際上這一篇和上一篇均可以看作是關于加解密的懶漢入門篇安全加強篇一的后續，只不過側重點在于安全上。回到上篇結果提到的問題，就是對稱加密的安全性要人命，非對稱加密的性能非常要人命。元首作為高智商罪犯，這種低級錯誤是不可能犯的。
為什么標題總是要帶上“API安全”關鍵字呢？因為我想我樂意。
實際上這一篇和上一篇均可以看作是《關于PHP加解密的懶漢入門篇(API安全加強篇一)》》")的后續，只不過側重點在于安全上。
如果說，你沒有看上篇，你一定回去看，不然一定會斷篇兒！
為了避免文章陷入過于抽象復雜的理論講解，所以這次還得借助元首和東線的將領們以及“反派角色”朱可夫同志。
人民好演員列表：男一元首：
男二古德里安：
路人甲曼施坦因：
路人乙馮*博克
“反派”男一
上篇我們知道元首和古德里安翻臉了，然后兩個人通過非對稱加密技術diss彼此，朱可夫沒有私鑰只能在路邊兒打醬油。
根據事實，我們知道古德里安又重返了東線戰場。當初把人擼了下來，現在又得讓人去東線救火，反正這臉我是拉不下來，但元首拉的下來。
回到上篇結果提到的問題，就是：對稱加密的安全性要人命，非對稱加密的性能非常要人命。用我黨地話來說就是“不能多快好省”，不符合“可持續發展”，不滿足“社會主義主流價值觀”。
這篇主要就是說“多快好省”的綠色方案。
讓古德里安回東線肯定得是秘密下令的，加密是肯定。但是這個地方一定要值得注意：那就是元首一定得是用古德里安同志的給他公鑰進行加密，然后再發送出去，此時這個密文雖然在東線用飛機撒的滿地都是，但是只有古德里安同志自己能用藏在自己褲襠里的私鑰進行解密后才能得到明文，也就是說這事兒也只有古德里安和元首兩個人知道了。
除此之外，還有兩種情況，可能愛思考的青年已經考慮到了：
元首是不是可以利用自己的公鑰對密文進行加密。但這種做法的最終結果就是這個密文只能用元首的私鑰進行解密，但是元首的私鑰在元首的褲襠里，別人是無法知道的。元首作為高智商罪犯，這種低級錯誤是不可能犯的。
元首用自己的私鑰對密文進行加密。這個時候就意味著只有持有元首公鑰的東線將領們才可以解密這個密文，然而假如元首并不想讓其他人知道他天才一般的部署，這種方式就顯得有點兒2了。
綜上，這種情況下，最正確的方式就是元首利用古德里安的公鑰對密文進行加密，然而再撒的滿天飛，這會兒只有古德里安能用自己的私鑰進行解密。此時，無論是自己家的曼施坦因、馮*博克，還是“反派”的朱可夫，都只能默默當路人甲。
在上述案例中（注意，客戶端不要理解為狹義角度的手機客戶端！）
元首充當API服務器的角色。
古德里安充當客戶端的角色。
曼施坦因、馮*博克充當路人甲客戶端角色。
朱可夫充當中間劫持者的角色。
我們回歸到現實中，也就是真正搬磚擼代碼的現實中。這個時候，如果要對服務器和客戶端傳輸的數據進行非對稱加密，那么就得有如下條件：
客戶端有自己一對公鑰私鑰，客戶端持有服務器的公鑰
服務器有自己一對公鑰私鑰，服務器持有客戶端的公鑰
那么問題來了，服務器只有少數一臺，客戶端成千上萬。這會兒擺在搬磚俠們面前的只有兩個選擇：
客戶端的公鑰和私鑰共用一對，這樣服務器只要一個公鑰就算是擁有了所有客戶端的公鑰
客戶端的公鑰和私鑰都是特立獨行的，是顏色不一樣的煙火。這會兒服務器就苦逼了，必須維護一坨彼此不同的客戶端，同時還要建立和不同客戶端的對應關系
那么，好了，下面讓各位搬磚俠們吃口屎保持一下冷靜，我們看看支付寶是怎么做的。當你的系統接入支付寶的時候，支付寶會要求你生成一對你的公私鑰，然后私鑰你自己藏好了，公鑰上傳到支付寶（這個過程相當于支付寶有了你的公鑰），然后再你上傳完你的公鑰后，支付寶會返回給你支付寶的公鑰。其中當你使用RSA普通版本的時候，所有商戶得到的支付寶公鑰都是同一個，當你使用RSA2的時候，每個商戶收到的支付寶公鑰都是不盡相同的。
所以說，怎么做都行，一切都看你選擇。
說起支付寶，你們接入的時候都一定看到有個叫做簽名驗證的功能，我認為這個很重要，是必須值得一提的一件事情。回到元首這里來，我們說元首給古德里安發消息“滾到東線，去庫爾斯克棱角部”，正確的做法應該是用古德里安的公鑰進行加密，此時該消息只能被古德里安的私鑰解密，其他人都只能干瞪眼。如果元首抽風了，用自己的私鑰加密了密文，這會兒會是什么情況咧？那就是持有元首公鑰的人都可以看到“滾到東線，去庫爾斯克棱角部”這條機密消息了，很多人都會發朋友圈或者私聊類似于“聽說古德里安要回來了”。其實，用自己私鑰解密，然后利用自己公鑰解密是一個二逼的行為，但是，這個過程可以用來驗簽是沒有任何問題的。什么是驗簽？
假如有一天，希姆萊想提前篡位，冒充元首給古德里安發號施令了。此時，古德里安只需要用元首的公鑰驗證一下命令的簽名，一驗返回了false，那就說明這坨命令不是來自于元首，這種數據就應該直接扔掉即可！
所以，上面叨逼叨叨逼叨這么久，為的就是得出一個結論，你們理（bei）解（song）一下：
公鑰加密，私鑰解密
私鑰加密，公鑰驗簽
然后我們再往前追溯一下，我們的為什么要用非對稱加密？是為了防止對稱加密措施密鑰的泄漏，而非對稱加密不存在密鑰泄漏的情況。
但是，非對稱加解密的性能以及部署使用方式，非土豪所能及也！那么，有沒有辦法既能得到魚，又能得到熊掌咧？
最近開了一個微信公眾號:高性能API社區，所有文章都先發這里文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/31423.html
摘要：實際上這一篇和上一篇均可以看作是關于加解密的懶漢入門篇安全加強篇一的后續，只不過側重點在于安全上。回到上篇結果提到的問題，就是對稱加密的安全性要人命，非對稱加密的性能非常要人命。元首作為高智商罪犯，這種低級錯誤是不可能犯的。 為什么標題總是要帶上API安全關鍵字呢？因為我想我樂意。 實際上這一篇和上一篇均可以看作是《關于PHP加解密的懶漢入門篇(API安全加強篇一)》》)的后續，只不過...
摘要：很明顯，非對稱加密的極大的消耗成了一種瓶頸。其中，利用非對稱加密的方案大概就是我前面說的那樣，偽代碼已經展示過了。 其實，前面兩篇翻來覆去只為叨逼叨叨逼叨兩件事情： 對稱加解密，典型算法有AES、DES、3DES等等 非對稱加解密，典型的算法有RSA、DSA、ECDH等等 但是，我知道大家最討厭在看這種文章的時候冒出來的一坨橢圓曲線、素數、質數等等這樣的玩意，反正看也看不懂，理解也...
摘要：由于密鑰被暴露了，所以必須換新的密鑰，元首這會兒只能走途徑告訴古德里安新的密鑰，這會兒逗逼的事情來了，如何對密鑰進行加密。但是，有一點是值得說明，那就是無論是對稱加密還是非對稱加密，都頂不住用機器是強行暴力猜解私鑰。 懶漢 入門 這兩點就足以說明這篇文章不想要著有什么高端大氣的技術內容，我跟你講，全是水。不可能有什么質數素數、橢圓曲線加密、迪菲-赫爾曼什么的，不可能有的。 首先我不...
摘要：這種神奇的算法可以讓你服務器和客戶端在不傳輸該對稱密鑰的情況下就可以通過心有靈犀地方式各自計算出一個對稱密鑰，而且可以一樣，避免了該密鑰在網絡上流通，而且你可以隨意更換，過期時間定為分鐘，可謂是狠毒至極我們引入就是為了解決上面的問題。 首先是前段時間我在公眾號里被人批（dui）評（gang）了，大概意思就是：你別老整那ECDH又是橢圓又是素數啥的，你就說這玩意實際項目中怎么用就完了，我...
摘要：這種神奇的算法可以讓你服務器和客戶端在不傳輸該對稱密鑰的情況下就可以通過心有靈犀地方式各自計算出一個對稱密鑰，而且可以一樣，避免了該密鑰在網絡上流通，而且你可以隨意更換，過期時間定為分鐘，可謂是狠毒至極我們引入就是為了解決上面的問題。 首先是前段時間我在公眾號里被人批（dui）評（gang）了，大概意思就是：你別老整那ECDH又是橢圓又是素數啥的，你就說這玩意實際項目中怎么用就完了，我...
閱讀 1120·2023-04-26 02:46
閱讀 624·2023-04-25 19:38
閱讀 639·2021-10-14 09:42
閱讀 1234·2021-09-08 09:36
閱讀 1354·2019-08-30 15:44
閱讀 1319·2019-08-29 17:23
閱讀 2237·2019-08-29 15:27
閱讀 801·2019-08-29 14:15
