I agree with the comments in this thread regarding the security of a 96-bit
MAC assuming the MAC function is also a PRF (which we assume HMAC to be).
This is what Scott is pointing out. An old paper of Prennel and van Orschot
also makes the case for truncation as adding security (Uri mentions that).
The reason people are allergic to shortened tags is because of the risk of
collisions in the context of collision-resistant hash functions. MAC
functions do not have to be collision-resistant (this is why HMAC-SHA1
still seems to survive in spite of collision attacks on SHA1).
*However, *people have abused MAC values as commitment values, e.g., for
channel binding, where collision resistance is required, which led to
actual attacks. This was the wrong use of MAC values but overall, if
shortening is not considered to have strong reasons, may it is better not
to (I refer to this as robustness against future mistakes or changes in
functionality). A different but related example is the use of outputs from
KDF also for channel binding (e.g., producing exporter_master_secret in TLS
1.3) where collision resistance is needed (as pointed out is rfc8446). So
while 128-bit keys may be appropriate in some settings, binders of that
size are not.
Bottom line: Truncated values to 96 bits lead to secure MAC but may not be
sufficient when these values are (ab)used for other purposes.
Hugo
On Tue, Aug 6, 2024 at 3:01 PM Scott Fluhrer (sfluhrer) <sfluhrer=
40cisco....@dmarc.ietf.org> wrote:
>
>
> > -----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
>
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
