Valery Smyslov writes: > > I thought so as well. In the meantime, the TLS working group is discussing > > the same thing for TLS 1.3, and they are proposing to get rid of the salt > > (or IV) for AES-GCM as well as ChaCha20. > > > > http://www.ietf.org/mail-archive/web/tls/current/msg15884.html > > AFAIK they are discussing the possibility to get rid of explicit IV at all > and to use record number for that purpose. I don't think it will work > in our case. More precisely it could work for ESP, where sequence numbers > are unique, but it won't work for IKEv2, since Message ID is not unique > and can repeat (in cases of cluster synchronization or IKE Fragmentation). > So either we need to define two different mechnisms (implicit IV for ESP > and explicit IV for IKE) or always use explicit IV.
What I proposed earlier was that we define that chacha20 uses explicit IV, but the IV is always generated as running counter incremented by one. In normal case the IV is sent inside the both IKEv2 and ESP packets. In ESP the sequence number is used normally for replay protection. Then we could create new "ESP Sequence number + IV compression" protocol, that would negotiate the support for this in the IKEv2 for ESP, and if enabled by both ends, then they would set the ESP sequence number and chacha20 IV to be linked, i.e. they would always be same, and then we could compress one of them away after the encryption, and decompress them back in place before decryption. I.e. the actual packets sent would only have one number, and IV and ESP sequence number would be derived from that before decryption. For IKEv2 we would still use just normal explict IV. This would require us to define chacha20 IV generation so it uses running counter starting from fixed value, but everything else can be done later. > >> 1. Section 1. > >> > >> I think the main problem with 3DES is not that it is significantly slower > >> than AES, but that it has blocksize of 64 bits, that is considered > >> loo small for high-speed networks, when the possibility of birthday > >> attack > >> leads to necessity to frequently rekey. > > > > It’s hard to make that case. The blocksize is 64 bits. So it’s prudent to > > not use more than, say, a billion blocks. > > A billion blocks is 64 Gb. There are very few real tunnels that run that > > kind of throughput in under a minute. > > OTOH it’s no problem at all to run a CreateChildSA every minute, or even > > every five seconds. > > So I think there are very few cases that *can’t* use 3DES. > > Well, I'm not a cryptographer, but I've heard several times that > the real problem of 3DES is its short block. That is also my understanding, and I would rather use real reason why 3DES cannot be used (short blocksize) than some other random reason (i.e. claiming it to be too slow). If we claim 3DES cannot be used because it is slower than AES, then vendors having separate hardware acceleration for 3DES, but very slow CPU otherwise, could say that they have no reason to implement chacha, as their 3DES acceleration is fast enough. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
