散列和保护传输中的数据答案

【问题标题】：Hash and protecting data in transit散列和保护传输中的数据
【发布时间】：2020-10-16 07:40:26
【问题描述】：

我在 AWS 文档中看到以下关于保护传输中的请求数据的建议：

保护传输中的数据 为防止请求在传输过程中被篡改，一些请求元素用于计算请求的哈希（摘要），并将生成的哈希值作为请求的一部分包含在内。当 AWS 服务收到请求时，它会使用相同的信息来计算哈希并将其与您请求中的哈希值进行匹配。如果值不匹配，AWS 将拒绝该请求。

只是想知道篡改者不可能从更改的值中重新计算散列并用原始散列替换新散列，这样服务器就看不到请求有任何问题吗？

哈希是使用密钥创建的吗？并且篡改者将无法正确创建新的哈希？

我确定我在这里遗漏了一些东西。有人可以帮忙吗。

【问题讨论】：

我在同一个链接中得到了以下答案：签署请求要签署请求，您首先要计算请求的哈希（摘要）。然后，您使用哈希值、请求中的一些其他信息以及您的秘密访问密钥来计算另一个称为签名的哈希。然后通过以下方式之一将签名添加到请求中： 1. 授权标头。 2.查询参数所以基本上我们使用秘密访问密钥重新哈希哈希并将其添加到请求中。
请注意，AWS 文档包含 abysmal 实施建议，包括其中一些操作的冗长复杂的手动实施。图书馆几乎可以完成所有这些工作；尽可能避免使用 v1 AWS Java SDK，我更喜欢 jets3t 进行 S3 操作。
顺便说一下，这种 AWS 方法与 JSON Web Tokens 基本相同，不同之处在于 JWT 有点冗长但总体上是明智的，而 AWS 签名可能是对 AWS 进行编程时最麻烦的一个问题.

【解决方案1】：

这些签名由加密哈希和秘密加密密钥组成。例如https://en.wikipedia.org/wiki/HMAC。这就是为什么你不能修改数据并重新散列。

【讨论】：

【解决方案2】：

是否正在使用密钥创建哈希？

是的，这里提到的“哈希”实际上是一个HMAC，创建它需要您的 AWS 秘密访问密钥。

【讨论】：