签名算法中的 密钥来自哪里？

[hhhhhh123]

我想知道 客户端生成 sign 的时候 这个 appsecret 密钥哪里来的
如果采用 rsa 算法的话， 这个是参数填公钥吗？
如果是公钥那不是谁都能拿到吗？ 私钥不能泄露，
所以这个参数到底是怎么设计的？
就是这个地方没有看懂。

签名算法  
签名生成的通用步骤如下：  

设所有发送或者接收到的数据为集合 M ，将集合 M 内非空参数值的参数按照参数名 ASCII 码从小到大排序（字典序），使用 URL 键值对的格式（即 key1=value1&key2=value2…）拼接成字符串 stringA 。
在 stringA 最后拼接上 &appsecret=密钥 得到 stringSignTemp 字符串，并对 stringSignTemp 进行 MD5 运算，再将得到的字符串所有字符转换为大写，得到 sign 值
特别注意以下重要规则：  

参数名 ASCII 码从小到大排序（字典序）；  
如果参数的值为空不参与签名；  
参数名区分大小写；  
验证调用返回或平台主动通知签名时，传送的 sign 参数不参与签名，将生成的签名与该 sign 值作校验。  
接口可能增加字段，验证签名时必须支持增加的扩展字段  
举例  
例如传递的参数如下：  

appid: 12345  
pay_money: 1  
order_sn: 123123123123  
第一步：对参数按照 key=value 的格式，并按照参数名 ASCII 字典序排序如下  

appid=12345&order_sn=123123123123&pay_money=1  
第二步：对上一步中的字符串拼接 &appsecret=密钥  

appid=12345&order_sn=123123123123&pay_money=1&appsecret=xxxxxxxxx  
第三步：对上一步中字符串取 MD5 值  

$sign = md5('appid=12345&order_sn=123123123123&pay_money=1&appsecret=xxxxxxxxx');  
第四步：对上面 md5 值转化为大写  

$sign = strtoupper($sign);

[ysc3839]

不会使用 RSA 算法

[geelaw]

首先，这个不是数字签名，而是消息验证码（ MAC ），特别地，这是 hash MAC 。

其次，这里说的 app 不是运行在客户端的程序，而是运行在服务器上的（因此受到开发者的控制），客户不应该能直接访问这个 secret （因此不受任意用户的控制）。

就用这里的收付款的例子，假设客户可以通过客户端（如网页）填写信用卡信息来购物，然后要调用 VMADU 公司的支付 API 来请款，那么调用这个请款 API 的程序运行在服务器上，而不是客户的机器上，服务器程序需要验证购物信息有效才会调用这个 API ，而消息验证码是确保这个 API 确实是服务器调用的。

假设你发现信用卡 1234 的客户总是退货，于是你决定不再和这个客户做生意，那么你的服务器程序遇到 1234 的时候就不调用 API ，此时 1234 客户不能强行用这个 API 使得你收款（从而带来不必要的麻烦，例如要求你发货之类的）。

[ZE3kr]

用公钥加密密钥解密

其次，公钥是公钥，并不代表就一定要公开，你把公钥当密码看待，别人也不会知道

[geelaw]

最后，这个 secret 是你和 VMADU 公司才知道的，通常来说是 VMADU 公司审核你的资质之后为你生成的（同时也允许你请求 VMADU 重新生成并告诉你新的 secret ）。

[GeruzoniAnsasu]

如果我没猜错，断章取义了。

这里的流程大概是微信小程序之类的平台用到的 auth 算法，参考微信支付的流程图：

https://pay.weixin.qq.com/wiki/doc/apiv3/assets/img/pay/wechatpay/3_9.png





你截的这段不是个通用签名流程

[cweijan]

哥们, 这个签名算法的流程已经说了, 是用 md5 算法... 服务端用相同的 md5 计算, 然后对比 hash 值是否一致.

[hhhhhh123]

@geelaw 明白了。 这是自己的服务端和第三方服务端进行交互 ， 用户是看不到的。

[hhhhhh123]

@GeruzoniAnsasu usdt 支付的

[hhhhhh123]

@geelaw 那像正常的 app 客户端和服务端进行交互 。 那么 sign 组成是没有这个密钥参数吗？ 其他的照搬？

[LeegoYih]

加签和加密的使用场景是不一样的

MD5：例子中是为了防止报文被篡改，服务端拿到的报文会再生成一遍签名，和客户端传入的签名进行匹配，不匹配说明报文被中间人篡改了（或者是 bug ），就可以拒绝该请求。

RSA：私钥加签，公钥验签；公钥加密，私钥解密。
通常用于双方都有开发能力的场景，比如你想调用支付宝的 OpenAPI ，在注册商家时，会和你交换公钥，这样就可以安全的交互了。

[geelaw]

@hhhhhh123 #9 客户端和服务端的通信要防止传输路径上的窃听与篡改，不能防止用户发送无意义数据。你的问题（……进行交互……照搬？的完整解答需要好几本书，但你可以通过仔细思考什么行为是安全隐患、什么问题可以（或者不能）通过在哪里施加哪些技术手段防范来管中窥豹。

[datoujiejie221]

如果用在签名的话 那肯定是用私钥了