数字签名与通过 DH 使用密钥的 HMAC
我正在编写一个大量使用密码学的应用程序。与大多数网络应用程序一样，我的应用程序将数据分解为不同类型的消息（即时消息、文件块、视频帧等），并且必须检查每一条消息的真实性，以防止篡改和来源正确。到目前为止，我能够使用 ECDH 来协商我已经用于 AES 的共享密钥。当然，稍后可以使用相同的共享秘密。
我的问题是：在这种情况下，使用 ECDSA 来签署每条消息，而不是简单地使用 ECDH 与 HMAC 建立的共享密钥，是否有任何额外的好处？
下面，当我说 M 时，我的意思是加密消息或明文；应该没关系。请更正下面的任何错误。
据我了解，在 ECDSA（或 DSA）中，通常使用安全散列算法（我当前正在使用 SHA-2 之一）对消息 (M) 进行散列，以生成 H(M)< /code>，然后使用签名者的私钥加密 H(M)。这会产生 R 和 S 整数（签名）。然后，M、R和S被发送给接收者，接收者已经拥有发送者的公钥。计算H'(M)，并使用R和S验证签名。 BouncyCastle 提供了实现此功能的ECDSASigner。
在 HMAC 中，需要一个共享密钥，而我已经拥有了。然后：HMAC(K, M) := H( f2(K) || H(f1(K) || M) ) （感谢 Paŭlo Ebermann 的更正。有关详细信息，请参阅他的回答。）
那么，考虑到 DH/ECDH 安全地协商共享密钥，我是否有理由不使用 HMAC？
相关：为什么 NSA 为 DSA 指定标准算法而不是 MAC？仅仅因为它可以是 SHA-2 + AES？
速度在这里很重要，因为我希望我正在制作的这个协议不仅支持现在的文本消息，而且在不久的将来也支持大文件和视频帧。因此，我更喜欢使用 HMAC，但希望确保我能够实现上述目标。
感谢您的帮助！
I am writing an application that heavily uses cryptology. Like most networked applications, mine breaks up data into different types of messages (instant message, file chunk, video frame, etc.) -- and each one must be checked for authenticity both for anti-tampering and correct origin. So far, I am able to use ECDH to negotiate a shared secret which I use already for AES. Of course, that same shared secret can be used later.
My question is: In this case, is there any added benefit to using ECDSA in order to sign each message, rather than simply using the shared secret established by ECDH with a HMAC?
Below, when I say M, I mean either an encrypted message or plaintext; it shouldn't matter. Please correct any errors below.
I understand that in ECDSA (or DSA) typically hashes a message (M) with a secure hashing algorithm (I am currently using one of the SHA-2s) to make H(M), then encrypts the H(M) using the signer's private key. This produces R and S integers (the signature). Then, M, R and S are sent to the recipient, who is already in possession of the sender's public key. H'(M) is calculated, and the signature is verified using R and S. BouncyCastle provides ECDSASigner which implements this.
In HMAC, a shared secret is required, which I have. Then:HMAC(K, M) := H( f2(K) || H(f1(K) || M) )
(Thanks for the correction, Paŭlo Ebermann. See his answer for details.)
So, considering that DH/ECDH negotiate a shared secret securely, is there a reason I shouldn't use HMAC?
Related: why does the NSA specify a standard algorithm for DSA and not MAC? Just because it can be SHA-2 + AES?
Speed is important here because I want this one protocol that I'm making to support not only text messages now, but also large files and video frames in the near future. Therefore I prefer using an HMAC but want to make sure I can meet the goals above.
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DSA 的一个缺点是您需要相当多的随机字节来进行签名。甚至在这种情况下，使用错误的随机源可以根据签名重建您的私钥。对于 MAC，您必须签署大量消息，因此需要大量随机数。如果你没有硬件产生这些，你就会耗尽熵。
HMAC 不需要任何随机数（它是确定性的）。
另外，我认为 HMAC 比此处使用 DSA 更有效，但您可以（并且应该）对此进行测量。
关于“纠正错误”：您对 HMAC 的描述不太正确 - 没有“解密”。它更像是这样：
您有消息
M、哈希函数H和共享秘密K。添加两个公共函数f1和f2（这些是一些简单的 XOR+padding）。然后||是简单的串联。发送者和接收者进行相同的计算，发送者将他的结果与消息一起发送，然后接收者将他的结果与发送的结果进行比较。 （确保您以不允许计时攻击的方式进行比较，即比较所有内容，即使您已经发现它不匹配。）HMAC 的确切定义位于 RFC 2104，其中还包含一些澄清的数字。
关于这个问题：
我不太确定，但这里有一个想法：
那里的链接列表提到了“Galois TLS (RFC 5288) 和 SSH (RFC 5647)，据说这是保护机密性和完整性。因此不再需要单独的 MAC。 （这是我第一次读到这篇文章，所以我现在无法判断。）
One disadvantage of DSA is that you need quite some good random bytes for your signature. It is even the case that using a bad random source your private key can be reconstructed from the signature. For a MAC, you have to sign lots of messages, so you need lots of random numbers. If you have no hardware producing these, you will run out of entropy.
HMAC does not need any random numbers (it is deterministic).
Additionally I think HMAC will be more efficient than using DSA here, but you could (and should) measure this.
About "correct errors": Your description of HMAC is not quite right - there is no "decryption". It is more like this:
You have the message
M, a hash functionH, and a shared secretK. Add two public functionsf1andf2(these are some simple XOR+padding). Thenwith
||being simple concatenation. The sender and receiver do the same calculation, the sender sends his one with the message, and the receiver then compares his result with the sent one. (Make sure you do your comparison in a way which does not allow timing attacks, i.e. compare everything, even if you already found it does not match.)The exact definition of HMAC is in RFC 2104, which also contains some clarifying figures.
About this question:
I'm not really sure, but here is one idea:
The list of links there mentions the "Galois Counter Mode" for TLS (RFC 5288) and SSH (RFC 5647), and this is said to protect both confidentiality and integrity in one. Thus a separate MAC is not necessary anymore. (It's the first time I read this, so I can't judge this right now.)