总体逻辑：
客户端：对称加密数据，上传。。。回执对称解密
同理服务端：获取上传数据 对称解密 。。。下发：对称加密
当且仅当登录接口和 拉新（更新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
待有时间，细化该文章。。。