On Sat, May 16, 2020 at 02:24:45PM +0200, Christian Weisgerber wrote: > Tobias Heider: > > > currently iked(8) supports AES-GCM only for ESP. > > The diff below adds the ENCR_AES_GCM_16 and ENCR_AES_GCM_12 variants for > > IKE. > > (for more information see [1] and [2]). > > Both variants support the 128, 196, and 256 bit key lengths. > > > > The new new ciphers can be configured with: > > - aes-128-gcm, aes-196-gcm and aes-256-gcm for ENCR_AES_GCM_16 > > - aes-128-gcm-12, aes-196-gcm-12 and aes-256-gcm-12 for ENCR_AES_GCM_12 > > Is there a compelling reason to implement the GCM_12 variants?
Only that it's actually used in the wild. I added them because I am forced to have them for compatibility. Dropping them would force me to maintain a local diff, which I would of course like to avoid. > I remember that truncating integrity tags is problematic for GCM. > That probably doesn't matter for small IKE exchanges, but then again > four extra bytes per packet don't matter either. According to > RFC5282, full length tags MUST be supported anyway, truncated ones > are optional. I know NIST recommends a limit in message size and operations per key for the 32 and 64 bit truncated versions in [1]. The AES_GCM_12 tag seems to be long enough to make attacks considerably harder (although I agree that the non truncated version should always be preferred). > > RFC5282 also says that AES-192 is NOT RECOMMENDED. > Fair enough, I think we can live without those. - Tobias [1] https://csrc.nist.gov/publications/detail/sp/800-38d/final
