關於PHP加解密的青年擡高篇(API安全增強篇二)

爲何標題老是要帶上「API安全」關鍵字呢?由於我想我樂意。segmentfault

實際上這一篇和上一篇都可以看做是《關於PHP加解密的懶漢入門篇(API安全增強篇一)》》")的後續,只不過側重點在於安全上。安全

若是說,你沒有看上篇,你必定回去看,否則必定會斷篇兒!服務器

爲了不文章陷入過於抽象複雜的理論講解,因此此次還得藉助元首和東線的將領們以及「反派角色」朱可夫同志。微信

人民好演員列表:

  • 男一元首:

  • 男二古德里安:

  • 路人甲曼施坦因:

  • 路人乙馮*博克

  • 「反派」男一

上篇咱們知道元首和古德里安翻臉了,而後兩我的經過非對稱加密技術diss彼此,朱可夫沒有私鑰只能在路邊兒打醬油。性能

根據事實,咱們知道古德里安又重返了東線戰場。當初把人擼了下來,如今又得讓人去東線救火,反正這臉我是拉不下來,但元首拉的下來。加密

回到上篇結果提到的問題,就是:對稱加密的安全性要人命,非對稱加密的性能很是要人命。用我黨地話來講就是「不能多快好省」,不符合「可持續發展」,不知足「社會主義主流價值觀」。spa

這篇主要就是說「多快好省」的綠色方案。blog

讓古德里安回東線確定得是祕密下令的,加密是確定。可是這個地方必定要值得注意:那就是元首必定得是用古德里安同志的給他公鑰進行加密,而後再發送出去,此時這個密文雖然在東線用飛機撒的滿地都是,可是隻有古德里安同志本身能用藏在本身褲襠裏的私鑰進行解密後才能獲得明文,也就是說這事兒也只有古德里安和元首兩我的知道了。圖片

除此以外,還有兩種狀況,可能愛思考的青年已經考慮到了:支付寶

  • 元首是否是能夠利用本身的公鑰對密文進行加密。但這種作法的最終結果就是這個密文只能用元首的私鑰進行解密,可是元首的私鑰在元首的褲襠裏,別人是沒法知道的。元首做爲高智商罪犯,這種低級錯誤是不可能犯的。
  • 元首用本身的私鑰對密文進行加密。這個時候就意味着只有持有元首公鑰的東線將領們才能夠解密這個密文,然而假如元首並不想讓其餘人知道他天才通常的部署,這種方式就顯得有點兒2了。

綜上,這種狀況下,最正確的方式就是元首利用古德里安的公鑰對密文進行加密,然而再撒的滿天飛,這會兒只有古德里安能用本身的私鑰進行解密。此時,不管是本身家的曼施坦因、馮*博克,仍是「反派」的朱可夫,都只能默默當路人甲。

在上述案例中(注意,客戶端不要理解爲狹義角度的手機客戶端!

  • 元首充當API服務器的角色。
  • 古德里安充當客戶端的角色。
  • 曼施坦因、馮*博克充當路人甲客戶端角色。
  • 朱可夫充當中間劫持者的角色。

咱們迴歸到現實中,也就是真正搬磚擼代碼的現實中。這個時候,若是要對服務器和客戶端傳輸的數據進行非對稱加密,那麼就得有以下條件:

  • 客戶端有本身一對公鑰私鑰,客戶端持有服務器的公鑰
  • 服務器有本身一對公鑰私鑰,服務器持有客戶端的公鑰

那麼問題來了,服務器只有少數一臺,客戶端成千上萬。這會兒擺在搬磚俠們面前的只有兩個選擇:

  • 客戶端的公鑰和私鑰共用一對,這樣服務器只要一個公鑰就算是擁有了全部客戶端的公鑰
  • 客戶端的公鑰和私鑰都是特立獨行的,是顏色不同的煙火。這會兒服務器就苦逼了,必須維護一坨彼此不一樣的客戶端,同時還要創建和不一樣客戶端的對應關係

那麼,好了,下面讓各位搬磚俠們吃口屎保持一下冷靜,咱們看看支付寶是怎麼作的。當你的系統接入支付寶的時候,支付寶會要求你生成一對你的公私鑰,而後私鑰你本身藏好了,公鑰上傳到支付寶(這個過程至關於支付寶有了你的公鑰),而後再你上傳完你的公鑰後,支付寶會返回給你支付寶的公鑰。其中當你使用RSA普通版本的時候,全部商戶獲得的支付寶公鑰都是同一個,當你使用RSA2的時候,每一個商戶收到的支付寶公鑰都是不盡相同的。

因此說,怎麼作都行,一切都看你選擇。

提及支付寶,大家接入的時候都必定看到有個叫作簽名驗證的功能,我認爲這個很重要,是必須值得一提的一件事情。回到元首這裏來,咱們說元首給古德里安發消息「滾到東線,去庫爾斯克棱角部」,正確的作法應該是用古德里安的公鑰進行加密,此時該消息只能被古德里安的私鑰解密,其餘人都只能乾瞪眼。若是元首抽風了,用本身的私鑰加密了密文,這會兒會是什麼狀況咧?那就是持有元首公鑰的人均可以看到「滾到東線,去庫爾斯克棱角部」這條機密消息了,不少人都會發朋友圈或者私聊相似於「據說古德里安要回來了」。其實,用本身私鑰解密,而後利用本身公鑰解密是一個二逼的行爲,可是,這個過程能夠用來驗籤是沒有任何問題的。什麼是驗籤?

假若有一天,希姆萊想提早篡位,冒充元首給古德里安發號施令了。此時,古德里安只須要用元首的公鑰驗證一下命令的簽名,一驗返回了false,那就說明這坨命令不是來自於元首,這種數據就應該直接扔掉便可!

因此,上面叨逼叨叨逼叨這麼久,爲的就是得出一個結論,大家理(bei)解(song)一下:

  • 公鑰加密,私鑰解密
  • 私鑰加密,公鑰驗籤

而後咱們再往前追溯一下,咱們的爲何要用非對稱加密?是爲了防止對稱加密措施密鑰的泄漏,而非對稱加密不存在密鑰泄漏的狀況。

可是,非對稱加解密的性能以及部署使用方式,非土豪所能及也!那麼,有沒有辦法既能獲得魚,又能獲得熊掌咧?

最近開了一個微信公衆號:高性能API社區,全部文章都先發這裏

圖片描述

相關文章
相關標籤/搜索