Bug #85781 for Digest-SHA: Concerns about constant-time HMAC comparison

Your suggestion might indeed be useful as part of a toolkit module for cryptographic application developers. I would encourage you to pursue that idea, or to collaborate with others who might already be working on such a module. But realize that timing attacks are just one small slice of the myriad threats that such developers need to be concerned about. Focusing solely on timing attacks is both insufficient and arbitrary. Timing attacks can be relevant to any process using secrets (keys), not just to HMAC algorithms. More importantly in this case, the timing attacks wouldn't actually be performed on the HMACs themselves: they are assumed to be public. Only the keys are hidden. Note that the HMAC algorithm uses the key exclusively during initialization of the digest context (ref. hmacopen), which is a very small part of the overall digest computation. It's difficult to see how an eavesdropper could obtain any reliable information about the key from timing data on the hmac functions.

Indeed, that's how one particular variant of a timing attack works. But discovering a MAC by such a process is useless because--as stated previously--the MAC is already public to begin with. The goal of the attacker is to discover the *key*, not the MAC. Without the key, it's impossible to forge a correct MAC for a given arbitrary message. When an eavesdropper sees a particular message with corresponding MAC pass over the network, he now knows the correct MAC for that message. This means that the eavesdropper could now spoof the receiver by sending that same message (and MAC) again. This is known as a replay attack. However such attacks are usually foiled by insisting that the message contain a random nonce or sequence number such that all messages to the receiver are guaranteed to be distinct. Because each message is distinct, each MAC will be distinct as well and therefore can't be forged without knowledge of the key. Threat scenarios are varied and complex. Oftentimes, special protocols need to be employed to combat them. But this is in the province of the cryptographic application developer, not the digest algorithm implementer. The sole purpose of Digest::SHA is to implement the FIPS 180-4 algorithms in a complete, compact, efficient, and easy-to-use set of routines accessible to the Perl programmer. Documenting the myriad threat scenarios relevant to cryptographic application developers is clearly outside the scope of the Digest::SHA module. Even mentioning particular instances of such threats is irresponsible since it would give the mis-impression that the module also serves as a tutorial to cryptographic application developers, which it clearly is not. Such tutorials are best left to experts in that area. Mark On Sat Jun 01 23:16:16 2013, DAGOLDEN wrote: Show quoted text

I see. Thanks for the clarification. We nonetheless concur on the main point that such attacks are beyond the scope of Digest::SHA to either handle or document. However, that fact doesn't cause your original concern to disappear. So the question becomes: where and how do you intend to address it? You might have the basis there for a new and very useful CPAN module. A daunting task, though. Mark On Sun Jun 02 14:48:29 2013, DAGOLDEN wrote: Show quoted text