我發誓這真的是最后一篇關于ECDH的文兒！（API安全加強篇四）

IntMain 發布于2019-07-01 12:47 / 2373人閱讀

摘要：這種神奇的算法可以讓你服務器和客戶端在不傳輸該對稱密鑰的情況下就可以通過心有靈犀地方式各自計算出一個對稱密鑰，而且可以一樣，避免了該密鑰在網絡上流通，而且你可以隨意更換，過期時間定為分鐘，可謂是狠毒至極我們引入就是為了解決上面的問題。

首先是前段時間我在公眾號里被人批（dui）評（gang）了，大概意思就是：你別老整那ECDH又是橢圓又是素數啥的，你就說這玩意實際項目中怎么用就完了，我們不想聽那些，那些我們都懂都精通，而且你還太監了，你自己看看是不是太監了，ECDH寫到上一篇明顯還沒完，結果到現在了還沒下文，你自己說是不是太監了，你自己說。

其次是實際上本篇內容實際上和ECDH沒有半毛錢關系，通篇都是DH（少了EC兩個字母），不過在項目中實際應用的業務邏輯寫法、道理都是一樣曬兒的。你現在可以暫時認為DH就是ECDH的“ 少了兩個字母版本 ”。用DH的最主要原因是啥呢，因為時間有限，我優先寫了DH的常用語言庫文件，目前可用，ECDH的一根毛都沒有寫，所以只能用DH演示。

最后是再次強調一遍，作為一篇正經的文章，我需要再次科普一下DH是啥意思。

很多都以為DH是Daemon Hunter（惡魔獵手）的簡稱，然而并不是。Daemon Hunter是真實名稱叫做伊利丹，是個瞎子同時又是法瑪麗奧（就是老鹿）的兄dei。他暗戀白虎（就是那種真的白虎）泰蘭德，然而泰蘭德卻嫁給了老鹿，事情大概就是這么一回事。

在我們這里DH則是Diffie-Hellman的簡稱，二位大爺的照片我以前貼過，現在不得不再貼一遍：

上圖告訴我們頭發長短與職業無關，douyin上那些自以為get到程序員梗的短視頻真的是LOWB到一塌糊涂。

在正式開始前之前，我還是要說明一下用DH的初衷是什么或者說這個東西是來解決什么問題的。接著上篇的故事（點擊這里）說：

你老板說項目非常牛逼，數據要加密，用牛逼的加密算法

你就用RSA非對稱加密開發測試操作猛如虎

然后，一上線：CPU炸了，成績1-5

然后你找老板審批升級服務器費用，老板給了你300塊并讓你放心花大膽花

你首先把RSA下線了，然后偷偷換成了AES對稱加密，CPU不炸了

然后三百塊偷偷放到了自己腰包里

但是AES的對稱密鑰你寫死到客戶端，被逆向就完了；如果通過服務器下發，聽起來更加扯淡

想了想，你拿著三百塊錢組了個局兒，你帶著錢，我帶著陳旭，老趙帶著柱子，再加上大彪，正好六人局

局上我向你透露出一種方案：將AES對稱密鑰通過非對稱方式協商出來。DH這種神奇的算法可以讓你服務器和客戶端在不傳輸該對稱密鑰的情況下就可以通過心有靈犀地方式各自計算出一個對稱密鑰，而且可以一樣，避免了該密鑰在網絡上流通，而且你可以隨意更換，過期時間定為1分鐘，可謂是狠毒至極！

我們引入DH就是為了解決上面的問題。然而，DH或ECDH并不能解決中間人攻擊問題，這個要搞明白了。

所以，在正式開始之前，我必須先安利我和東北大嫖客還有巨蛀以及阿尼特寫的DH庫，github鏈接是這個，下面我將利用這些DH庫們進行demo演示。

https://github.com/ti-dh
（明眼人已經看出來我是來騙star的）

目前這個庫提供了純PHP、C實現的PHP擴展、Java版，列個表格吧：

先說下服務端和客戶端進行協商地整體流程，非常非常簡單：

整個協商流程中，只有第二步和第三步會發生數據交互。第二步是API下發p、g、server-num給客戶端；第三步是客戶端向API提交client-num數據；最后一步，對稱加解密用的key就已經計算出來用于生產環境了。

下面我用世界上最好的語言演示一下如何使用這個鬼東西，客戶端我們用什么演示呢？客戶端也依然使用世界上最好的語言來演示。首先，你們把上面github里的庫文件集成到你們API里，我這里集成完畢后代碼如下：

API demo code：

dh = new Dh();
  }

  // 這就是上圖中的第二步：客戶端訪問這個API獲取g p 和 server-num
  public function getdhbasedataAction() {
    $ret = $this->dh->getdhbasedata();
    echo json_encode( $ret );
  }

  // 這就是上圖中的第三步：客戶端通過這個api提交client-num參數
  public function postdhclientdataAction() {
    if ( $this->getRequest()->isPost() ) {
      if ( empty( $_POST["client_number"] ) || !is_numeric( $_POST["client_number"] ) ) {
        exit( json_encode( array(
          "code"    => -1,
          "message" => "wrong parameters",
        ) ) );
      }
      $ret = $this->dh->postdhclientdata( $_POST );
      echo json_encode( array(
        "key" => $ret,
      ) );
    }
  }

}

Client demo code：

get( "https://xxxx.ooo/dh/getdhbasedata" );
$ret = json_decode( $ret, true );
$p = $ret["p"];
$g = $ret["g"];
$server_number = $ret["server_number"];
// 2、第二步，根據服務器獲取到的數據計算出client-number
$process_client_number = gmp_powm( $g, $client_number, $p );
// 3、第三步，將計算過后的client-number發送給服務器
// 那個demo里已經有完美的演示了，多看代碼
$ret = $curl->post( "https://xxxx.ooo/dh/postdhclientdata", array(
  "client_number" => gmp_strval( $process_client_number ),
) );
$ret = json_decode( $ret, true );
// 4、第四步，根據server-number，client-number和p 計算出公共密鑰K
$key = gmp_powm( $server_number, $client_number, $p );
echo PHP_EOL."DH非對稱密鑰產生交換：".PHP_EOL;
echo "client計算出的public key : ".$key.PHP_EOL;
echo "server計算出的public key : ".$ret["key"].PHP_EOL.PHP_EOL;

客戶端文件保存client.php，然后php client.php執行一下，結果你們感受一下：

一樣有沒有？！計算出來的都一樣，有沒有？！！

上圖中那么一坨長的不能整的讓人看了就覺得惡心嘔吐的數字就是API和客戶端分別計算出來的對稱加解密的密鑰了，請注意實際使用過程中，服務器千萬不要把這個數據返回給客戶端，demo里這么做就是為了演示而已，用的時候自己也需要動動腦子的。

然而，事情往往不會說就是這么簡單就可以了，如果在生產環境使用，還是需要繼續完善一些細節的。

第一個問題就是有些想的比較多的寶貝兒們會不同的兩個客戶端計算出來的key會不會一樣？可能性非常非常非常小

第二個問題就是一般客戶端登陸的用戶都有自己的token或uid之類的，API這里在與一個客戶端協商出一個key后可以以 “ token:key ” 格式把key存儲到redis中，然后給一個有效時間比如30分鐘；客戶端也將key保存到手機內存中設置一個30分鐘有效期。每次使用key進行加解密前都驗證一下是否過期，如果過期了就重新走一遍前面的協商流程

我發誓，這是關于DH或ECDH的最后一篇文章了，以后我再也不會寫任何與這兩個英文縮寫相關的東西了，我說都是真的，我保證說到做到。

歡迎來公眾號懟我、杠我：

云服務器 GPU云服務器我發誓一篇關于關于加強加強dhcp服務器的安全

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/31486.html

我發誓這真的是最后一篇關于ECDH的文兒！（API安全加強篇四）

摘要：這種神奇的算法可以讓你服務器和客戶端在不傳輸該對稱密鑰的情況下就可以通過心有靈犀地方式各自計算出一個對稱密鑰，而且可以一樣，避免了該密鑰在網絡上流通，而且你可以隨意更換，過期時間定為分鐘，可謂是狠毒至極我們引入就是為了解決上面的問題。首先是前段時間我在公眾號里被人批（dui）評（gang）了，大概意思就是：你別老整那ECDH又是橢圓又是素數啥的，你就說這玩意實際項目中怎么用就完了，我...

Barrior 2019-06-21 16:55 評論0 收藏0
關于PHP加解密之終扯到ECDH了（API安全加強篇三）

摘要：很明顯，非對稱加密的極大的消耗成了一種瓶頸。其中，利用非對稱加密的方案大概就是我前面說的那樣，偽代碼已經展示過了。其實，前面兩篇翻來覆去只為叨逼叨叨逼叨兩件事情：對稱加解密，典型算法有AES、DES、3DES等等非對稱加解密，典型的算法有RSA、DSA、ECDH等等但是，我知道大家最討厭在看這種文章的時候冒出來的一坨橢圓曲線、素數、質數等等這樣的玩意，反正看也看不懂，理解也...

lcodecorex 2019-07-01 12:45 評論0 收藏0
關于PHP加解密的懶漢入門篇(API安全加強篇一)

摘要：由于密鑰被暴露了，所以必須換新的密鑰，元首這會兒只能走途徑告訴古德里安新的密鑰，這會兒逗逼的事情來了，如何對密鑰進行加密。但是，有一點是值得說明，那就是無論是對稱加密還是非對稱加密，都頂不住用機器是強行暴力猜解私鑰。懶漢入門這兩點就足以說明這篇文章不想要著有什么高端大氣的技術內容，我跟你講，全是水。不可能有什么質數素數、橢圓曲線加密、迪菲-赫爾曼什么的，不可能有的。首先我不...

waterc 2019-07-01 12:43 評論0 收藏0
關于PHP加解密的青年抬高篇(API安全加強篇二)

摘要：實際上這一篇和上一篇均可以看作是關于加解密的懶漢入門篇安全加強篇一的后續，只不過側重點在于安全上。回到上篇結果提到的問題，就是對稱加密的安全性要人命，非對稱加密的性能非常要人命。元首作為高智商罪犯，這種低級錯誤是不可能犯的。為什么標題總是要帶上API安全關鍵字呢？因為我想我樂意。實際上這一篇和上一篇均可以看作是《關于PHP加解密的懶漢入門篇(API安全加強篇一)》》)的后續，只不過...

wujl596 2019-07-01 12:45 評論0 收藏0
關于PHP加解密的青年抬高篇(API安全加強篇二)

摘要：實際上這一篇和上一篇均可以看作是關于加解密的懶漢入門篇安全加強篇一的后續，只不過側重點在于安全上。回到上篇結果提到的問題，就是對稱加密的安全性要人命，非對稱加密的性能非常要人命。元首作為高智商罪犯，這種低級錯誤是不可能犯的。為什么標題總是要帶上API安全關鍵字呢？因為我想我樂意。實際上這一篇和上一篇均可以看作是《關于PHP加解密的懶漢入門篇(API安全加強篇一)》》)的后續，只不過...

付倫 2019-06-21 16:55 評論0 收藏0