ACM_Someone like you

總體邏輯：

客戶端：對稱加密數據，上傳。。。回執對稱解密

同理服務端：獲取上傳數據 對稱解密 。。。下發：對稱加密

當且僅當登錄接口和 拉新（更新nonce 和 key的接口）是對稱加密上傳 非對稱解密

1.加密庫選擇 ： Libsodium

2.加密對象：     

（1）整體：這個我們最后放棄了，因為如果整體加密，服務端大多數情況會回執本地無法解開的數據，客戶端不能按需處理邏輯了，僵死的邏輯處境

（2）局部：只加密data部分，這樣隨時根據回執信息按需處理

　　　　　　{code:0

                 data: {XXX}

　　　　  　message:success　　　　　　

　　　　　　}

3.加密方式：

重中之重，先 生成密鑰對：

執行方法crypto_box_keypair，生成密鑰對（pk,sk）

3.1 未登錄前http請求需要：(eg 發送驗證碼、請求國際碼集合等)

對稱加密：

客戶端參數：

  (1)前提:請求頭必有參數

  VERSION:客戶端版本號 md5處理

（2）密碼學必要參數 nonce:  (1) 中截取md5[0,24)

          key:  (1)中截取[0,32)

  (3) 加密對象：最終轉為data形式

 (4)執行加密傳輸：

                                                       方法：crypto_secretbox_easy

同理：服務端解密需要用 成對方法解密：crypto_secretbox_open_easy

（5）服務端回執：客戶端對稱解密（服務端發送是對稱加密）

3.2 登錄操作：

（1） “3.1”  對稱加密形式發起登錄請求

（2） 上傳加密的內容包括 本地生成的pk. ??登錄操作上傳公鑰對

（3）服務端回執：新的nonce 和 key  更新并存儲 （此時回執解密使用非對稱解密）

         服務端非對稱加密方法： crypto_secretbox_easy

         客戶端非對稱解密方法： crypto_secretbox_open_easy

3.3 登錄后的所有http請求（客戶端繼續操作）

    （1）發起請求，上傳 對稱加密

    （2）回執： 對稱解密

    （3）當驗簽失敗 即接口401時，seed(即  nonce 和 key 過期)，使用更新 seed接口，再次更新nonce和key 再繼續請求。（這個交互邏輯類似于釘釘，異端登錄會踢掉該賬號，要重新登錄才能繼續使用的業務邏輯）

         更新nonce 和 key 操作 因為 舊的已失效

    （4）??該拉新接口：對稱加密（實際好像沒參數。。。看需求 有就對稱加密上傳）上傳，非對稱解密更新nonce和key

待有時間，細化該文章。。。