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,
Horia
