> -----Original Message-----
> From: Benjamin Kaduk <ka...@mit.edu>
> Sent: Tuesday, August 6, 2024 1:17 PM
> To: Michael Richardson <mcr+i...@sandelman.ca>
> Cc: Daniel Shiu <daniel.s...@arqit.uk>; ipsec@ietf.org
> Subject: [IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated
>
> On Tue, Aug 06, 2024 at 12:31:21PM -0400, Michael Richardson wrote:
> >
> > Daniel Shiu <daniel.s...@arqit.uk> wrote:
> > > While working on cryptographic inventory tools, I noticed that the IKE
> > > authentication methos AUTH_HMAC_SHA1_96 (SHA1-based HMAC
> truncated to
> > > 96-bits) is permitted in IKEv2 per RFC 8247 (status MUST-
> > according t
> >
> > Note, it's *HMAC* SHA1.
> >
> > > Have I missed the deprecation elsewhere, or is further action merited.
> >
> > HMAC consists of two passes of SHA1, and includes padding in such a
> > way that means that pre-image attacks where the attack text is longer
> > than the original does not work.
> >
> > So, I am not falling overmyself to deprecate HMAC-SHA1.
> > I'm happy to leave things as they are until a revision to 8247 is done.
> > Note that MUST- means that it is already on it's "way down"
>
> The truncation to 96 bits is probably worth a bit of worry in this era (though
> not an extreme amount of worry). Note that Kerberos for a long time only
> had AES-CBC-HMAC-SHA1-96 as its strongest enctype but published RFC 8009
> back in 2016 to rectify that (with both a longer authentication tag and the
> more modern hash for HMAC), and as I understand it the new enctype has
> gotten pretty good uptake.
> At the time, the truncated tag was far more of a concern than the SHA-1
> usage (in HMAC).
I don’t see how a truncated tag would be much of a concern (either back then or
now).
To exploit it, what an attacker would have to do is generate his ciphertext and
then apply a guess of what the tag would be. Then, he would submit his
ciphertext/guessed tag to the decryptor, and hope that the decryptor generated
the same tag. Now, with a 96 bit tag, his guess would be correct with
probability 2^{-96} (with HMAC not giving him any way to increase this
probability). That is, to get a single forgery through with probability
2^{-20}, he'd need to present to the valid decryptor 2^{76), that is,
75,557,863,725,914,323,419,136 packets with different guesses at the tag. I
believe that this is approximately the number of packets flowing over the
entire global internet in an hour - all directed towards our device under
attack. Needless to say, there is no device that would process this much data
in any reasonable amount of time.
So, what's the difference between this, and a ciphertext encrypted with a 96
bit key? Well, in the 96 bit key case, the attacker can test various keys on
his own devices, and can easily (given a large budget) build a huge computing
base that can test an enormous number of keys at once. In the 96 bit tag case,
the attacker cannot test an enormous number of tags at once - instead, he needs
to submit each guess at a tag to the valid decrypter, who will accept queries
only as fast as he cares to, and a well-funded adversary cannot speed it up.
[Sorry for the rant - I think this point is missed far too often, and it bugs
me]
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
