On Mon, 10 Oct 2022 at 10:25, Nikunj A. Dadhania <nikunj@xxxxxxx> wrote: > > > > On 10/10/22 13:45, Ard Biesheuvel wrote: > > On Mon, 10 Oct 2022 at 09:27, Nikunj A. Dadhania <nikunj@xxxxxxx> wrote: > >> > >> Hi Ard, > >> > >> On 07/10/22 20:51, Ard Biesheuvel wrote: > >>> Implement a minimal library version of GCM based on the existing library > >>> implementations of AES and multiplication in GF(2^128). Using these > >>> primitives, GCM can be implemented in a straight-forward manner. > >>> > >>> GCM has a couple of sharp edges, i.e., the amount of input data > >>> processed with the same initialization vector (IV) should be capped to > >>> protect the counter from 32-bit rollover (or carry), and the size of the > >>> authentication tag should be fixed for a given key. [0] > >>> > >>> The former concern is addressed trivially, given that the function call > >>> API uses 32-bit signed types for the input lengths. It is still up to > >>> the caller to avoid IV reuse in general, but this is not something we > >>> can police at the implementation level. > >>> > >>> As for the latter concern, let's make the authentication tag size part > >>> of the key schedule, and only permit it to be configured as part of the > >>> key expansion routine. > >>> > >>> Note that table based AES implementations are susceptible to known > >>> plaintext timing attacks on the encryption key. The AES library already > >>> attempts to mitigate this to some extent, but given that the counter > >>> mode encryption used by GCM operates exclusively on known plaintext by > >>> construction (the IV and therefore the initial counter value are known > >>> to an attacker), let's take some extra care to mitigate this, by calling > >>> the AES library with interrupts disabled. > >>> > >>> > >>> Cc: "Nikunj A. Dadhania" <nikunj@xxxxxxx> > >>> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > >>> --- ... > >> The gcm_mac computation seems to be broken in this version. When I receive the encrypted > >> packet back from the security processor the authtag does not match. Will debug further > >> and report back. > >> > > > > Sorry to hear that. If you find out what's wrong, can you please > > provide a test vector that reproduces it so we can add it to the list? > > My bad, it was wrong crypt_len that I was sending. Working fine now. > > Tested-by: Nikunj A Dadhania <nikunj@xxxxxxx> OK, good to know - thanks.
