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. >>> >>> [0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2Flegacy%2Fsp%2Fnistspecialpublication800-38d.pdf&data=05%7C01%7Cnikunj.dadhania%40amd.com%7C912c5b73be0146ca63db08daaa97ade4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638009869061457627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sNHrpE3d7w%2BpT8dzAPiFbmvYLLIu9zsCnJ%2BFFxjzp%2Bk%3D&reserved=0 >>> >>> Cc: "Nikunj A. Dadhania" <nikunj@xxxxxxx> >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fc6fb9b25-a4b6-2e4a-2dd1-63adda055a49%40amd.com%2F&data=05%7C01%7Cnikunj.dadhania%40amd.com%7C912c5b73be0146ca63db08daaa97ade4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638009869061457627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oyUKkikTm6wsPy8vFHiS98TZpL4Hu%2BFz9aYX%2Fs37wk0%3D&reserved=0 >>> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> >>> --- >>> +/** >>> + * gcm_decrypt - Perform GCM decryption on a block of data >>> + * @ctx: The GCM key schedule >>> + * @dst: Pointer to the plaintext output buffer >>> + * @src: Pointer the ciphertext (may equal @dst for decryption in place) >>> + * @crypt_len: The size in bytes of the plaintext and ciphertext. >>> + * @assoc: Pointer to the associated data, >>> + * @assoc_len: The size in bytes of the associated data >>> + * @iv: The initialization vector (IV) to use for this block of data >>> + * (must be 12 bytes in size as per the GCM spec recommendation) >>> + * @authtag: The address of the buffer in memory where the authentication >>> + * tag is stored. >>> + * >>> + * Returns 0 on success, or -EBADMSG if the ciphertext failed authentication. >>> + * On failure, no plaintext will be returned. >>> + */ >>> +int __must_check gcm_decrypt(const struct gcm_ctx *ctx, u8 *dst, const u8 *src, >>> + int crypt_len, const u8 *assoc, int assoc_len, >>> + const u8 iv[GCM_AES_IV_SIZE], const u8 *authtag) >>> +{ >>> + u8 tagbuf[AES_BLOCK_SIZE]; >>> + __be32 ctr[4]; >>> + >>> + memcpy(ctr, iv, GCM_AES_IV_SIZE); >>> + >>> + gcm_mac(ctx, src, crypt_len, assoc, assoc_len, ctr, tagbuf); >>> + if (crypto_memneq(authtag, tagbuf, ctx->authsize)) { >>> + memzero_explicit(tagbuf, sizeof(tagbuf)); >>> + return -EBADMSG; >>> + } >> >> 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>
