> -----Original Message----- > From: Michael Rossberg <michael.rossb...@tu-ilmenau.de> > Sent: Wednesday, July 29, 2020 2:35 PM > To: Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> > Cc: ipsecme mailing list <ipsec@ietf.org> > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 > > > > > Actually, it does add value from a crypto point of view, at least from a > specific attack. In a multitarget attack, that is, an attack where we assume > that the attacker has encrypted packets from a large number of SAs, and his > goal is to recover the keys for any one of the encrypted packets, here is what > the attacker can do (assuming GCM or ChaCha20-Poly1305); if he has packet > encrypted with each SA with the same nonce, he can guess a key, and > generate the internal GCM/ChaCha20 keystream based on that key/nonce > combination. He can then scan through all the packets to see if the > encryption makes sense (or the ICV tag works out); this can be done far > faster than checking each packet individually. Assuming the packets are > encrypted with AES-128, and the attacker has packets from 2**L SAs, then > against this attack, we have only 128-L bits of security. > > > > By including 32 bits of unpredictable values, we make this attack 4 billion > times harder, and for AES-128, that would give us 160-L bits of security. This > doesn't actually add any security against attacks against a single SA, and the > salt doesn't actually need to be secret. > > Thanks for clarification. I guess I have been thinking too SA centric. > In fact we always discussed AES-256 only. > > Do you agree that starting the window/sender IDs with random offsets > would fix this weakness?
Yes, it would address this weakness. On the other hand, with AES-256, you don't really need this anyways... _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
