> > 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?
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
