如何从 CyberSource REST API 文档复制 sha256 哈希示例?
How to replicate sha256 hash example from CyberSource REST API documentation?
我正在研究 CyberSource REST API 并想测试 JSON Web 令牌身份验证方法,如下所述:https://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html
我无法复制 JWT Payload/Claim 设置部分中描述的 JSON 负载的 sha256 哈希。
{
"clientReferenceInformation" : {
"code" : "TC50171_3"
},
"orderInformation" : {
"amountDetails" : {
"totalAmount" : "102.21",
"currency" : "USD"
}
}
}
我试图在包含有效负载示例的文件中以二进制和文本格式使用 sha256sum 命令。我还尝试 运行 此命令对此有效负载的不同排列,例如没有空格或换行符。
我希望得到
的示例哈希
2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c
而是得到
f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3
和其他不同的哈希。
我做错了什么?
可能你没有做错什么。哈希函数具有 avalanche effect,其中输入中的任何不同位都会对输出哈希产生很大影响。如果站点的原始示例使用了不同的编码,或者 JSON 元素的顺序不同,或者甚至有更多或更少的制表符、空格、换行符或任何其他“垃圾”字符,您将拥有很难找到与网站中显示的哈希值相符的消息。
通常,加密解决方案使用规范化来避免此类问题(语义相同的消息具有不同的哈希值)。但是,JWT specification 没有为 JSON 指定任何类型的规范化。
总之,我觉得你不用担心这个。只要您使用有效(正确实施)的哈希函数,您的 JWT 实施就是正确的。
此外,我注意到 JWT specification 没有为 JWT 负载指定“摘要”字段。因此,您甚至可能不需要使用此字段。除非 CyberSource REST API 强制要求。
由于所谓的 "example" 散列包含 33 个十六进制字符,因此可以看出它不是 SHA256 的可能有效输出。所以你无法使你的例子与他们的相匹配。
该讨论中还有一个 base64 示例,但它也不是有效的 base64。通过向 base64 添加一个额外的填充字符“=”,它可以变得有效,并且解码它会发现它主要匹配所谓的 SHA256 哈希。
我的猜测是该页面上的值只是人眼所见值的示例,而不是您应该完全匹配的测试向量。
我正在研究 CyberSource REST API 并想测试 JSON Web 令牌身份验证方法,如下所述:https://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html
我无法复制 JWT Payload/Claim 设置部分中描述的 JSON 负载的 sha256 哈希。
{
"clientReferenceInformation" : {
"code" : "TC50171_3"
},
"orderInformation" : {
"amountDetails" : {
"totalAmount" : "102.21",
"currency" : "USD"
}
}
}
我试图在包含有效负载示例的文件中以二进制和文本格式使用 sha256sum 命令。我还尝试 运行 此命令对此有效负载的不同排列,例如没有空格或换行符。
我希望得到
的示例哈希2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c
而是得到
f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3
和其他不同的哈希。
我做错了什么?
可能你没有做错什么。哈希函数具有 avalanche effect,其中输入中的任何不同位都会对输出哈希产生很大影响。如果站点的原始示例使用了不同的编码,或者 JSON 元素的顺序不同,或者甚至有更多或更少的制表符、空格、换行符或任何其他“垃圾”字符,您将拥有很难找到与网站中显示的哈希值相符的消息。
通常,加密解决方案使用规范化来避免此类问题(语义相同的消息具有不同的哈希值)。但是,JWT specification 没有为 JSON 指定任何类型的规范化。
总之,我觉得你不用担心这个。只要您使用有效(正确实施)的哈希函数,您的 JWT 实施就是正确的。
此外,我注意到 JWT specification 没有为 JWT 负载指定“摘要”字段。因此,您甚至可能不需要使用此字段。除非 CyberSource REST API 强制要求。
由于所谓的 "example" 散列包含 33 个十六进制字符,因此可以看出它不是 SHA256 的可能有效输出。所以你无法使你的例子与他们的相匹配。
该讨论中还有一个 base64 示例,但它也不是有效的 base64。通过向 base64 添加一个额外的填充字符“=”,它可以变得有效,并且解码它会发现它主要匹配所谓的 SHA256 哈希。
我的猜测是该页面上的值只是人眼所见值的示例,而不是您应该完全匹配的测试向量。