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
