> -----Original Message----- > From: Horia Geanta <horia.geanta@xxxxxxx> > Sent: Friday, July 26, 2019 9:17 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx > Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; davem@xxxxxxxxxxxxx; mhl@xxxxxx > Subject: Re: gcm.c question regarding the rfc4106 cipher suite > > On 7/26/2019 6:55 PM, Pascal Van Leeuwen wrote: > > Hi, > > > > I recently watched some patches fly by fixing issues in other drivers regarding the checking > > of supposedly illegal AAD sizes - i.e. to match the generic implementation there. > > I followed that with some interest as I'm about to implement this for the inside-secure > > driver. > > > > And something puzzles me. These patches, as well as the generic driver, seem to expect > > AAD lengths of 16 and 20. But to the best of my knowledge, and according to the actual > > RFC, the AAD data for GCM for ESP is only 8 or 12 bytes, namely only SPI + sequence nr. > > > > The IV is NOT part of the AAD according to the RFC. It's inserted in the encapsulated > > output but it's neither encrypted nor authenticated. (It doesn't need to be as it's > > already authenticated implicitly as its used to generate the ciphertext. Note that GMAC > > (rfc4543) *does* have to authenticate the IV for this reason. But GCM doesn't ...) > > > > So is this a bug or just some weird alternative way of providing the IV to the cipher? > > (beyond the usual req->iv) > > > Try to track the aead assoclen and cryptlen values starting from IPsec ESP > (say net/ipv4/esp4.c) level. > At this point IV length is part of cryptlen. > > When crypto API is called, for e.g. seqiv(rfc4106(gcm(aes))), IV length > accounting changes from cryptlen to assoclen. > > In crypto/seqiv.c, seqiv_aead_encrypt(): > aead_request_set_crypt(subreq, req->dst, req->dst, > req->cryptlen - ivsize, info); > aead_request_set_ad(subreq, req->assoclen + ivsize); > thus the subrequest - rfc4106(gcm(aes)) - has to check for a 16 / 20-byte AAD. > > Hope this helps, > Yes and no. So it's what the ESP implementation expects but that stil doesn't tell me whether the IV is authenticated or not. Although if the ESP implementation actually interoperates with anything, I would have to assume that it doesn't. I tried reverse engineering gcm.c, but I find the code difficult to follow. It looks like it's actually *inserting* the IV there (from ctx->nonce and req->iv) but indeed not authenticating it? Not sure though. > Horia Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
