Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3e395ad2-48f6-87f6-9042-a3ca21c0baba@amd.com>
Date:   Mon, 10 Oct 2022 12:57:30 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] crypto: gcm - Provide minimal library implementation
Content-Language: en-US
To:     Ard Biesheuvel <ardb@kernel.org>, linux-crypto@vger.kernel.org
Cc:     herbert@gondor.apana.org.au, ebiggers@kernel.org,
        keescook@chromium.org, jason@zx2c4.com
References: <20221007152105.3057788-1-ardb@kernel.org>
From:   "Nikunj A. Dadhania" <nikunj@amd.com>
In-Reply-To: <20221007152105.3057788-1-ardb@kernel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SnRENnppeGhFb0NaY3gyanVaU3dDa09oYmV4OEFJdzVBK1IxMTc2OTkzUHRY?=
 =?utf-8?B?cS9RTjJ1R2IwbjJndW1iMkRhd1ZLSGJmNmM5VlMzTU84bFJrYU9qc09lNzAy?=
 =?utf-8?B?V21Kb093K01tR2JDUmVvWUpJUm9VZmlqS1k2QkhWOUtPRi96NEJEaVN0aU94?=
 =?utf-8?B?NjBzaW1IR0drUUk2dzZPLzRkK2laMEZwOW9wTHVFbkt4RVJ2WUdTQzk4R3Ja?=
 =?utf-8?B?S2lqb3llWk9nZlBiQzFndDVscnBsM3FXYUEzRFAwS0tKa3BzOUVJMHZ1QjRt?=
 =?utf-8?B?YWpDYVNBYnRkK2xGekdSL0FpeFVwTS9nNWluMnlMbDBMMlNETnJxSkZxZzE3?=
 =?utf-8?B?TUs5cmJ6TklWVEkvRnZ5ZDN6bUtXZVhiak9VbEFEcGZ2STc3SnJpcWVzVkhG?=
 =?utf-8?B?ZmFtRVJQeHFodno5WjkrZkZpdjFhaFptSjVrR0t0dEdSWCtkMlRZZnhWdXNy?=
 =?utf-8?B?SUZ3SGtNN3dLVHZ2czhPekN3bXJtaSt4RlJkaUpocWxkcjVCUDRWTFlHWWkv?=
 =?utf-8?B?eFBmcHF5dnlpeTRFU2hnclgxYkl0ajJSU0wvUlNZQ29vNFRucmJIN05jbk1n?=
 =?utf-8?B?WnBrdGt1VFJ2WU51Z0xIREhMdzZSNVJwSVFhbHFnSndGNFI0V3gzSkEzUVpC?=
 =?utf-8?B?UFNOSzc5RWdDdHFheFNqRVdqVll4YzRvSjNVb3dmSmJETE5VWStmZ3E4T1Iz?=
 =?utf-8?B?N1dKNGJITkVaM1NVSVlDai94QitaU1Nndy96TTdmc1RmeTFKY1lwU001WlJl?=
 =?utf-8?B?V1Y3aHptTTc4cXAwNTlzQWs3all0aGZHN0xYcnRmbUo1dXZrRVAwcmdnaEhX?=
 =?utf-8?B?YkJHQUF2QWRTejF6aWwyWWFUQmVMbFNUMW8zbVFMamorajF3Z0JISE80dTRP?=
 =?utf-8?B?QWJsQTBieC91S3JCQXZRbjVJdStOUCt5T21ieWJaeXE2enMwVmlWaldrM0oz?=
 =?utf-8?B?eFM1NGptb0lIOTBlaFdPbm45WTA0TGw4T0c2NTdpRUJNWDM3YmxDZWg4Rk9j?=
 =?utf-8?B?c08wUjlIZE5JeXJ0czBpRWRmQUJZRjlQckdNNTQ2YWNEWTJUQXJWZXczOXVR?=
 =?utf-8?B?VnUxeXVGQlBOUW1UaGlNVndyUHdYZi81THlweG1OblZxKzY2bzRsTXVDTHhp?=
 =?utf-8?B?b3FJOXdiSlpzNXdhalVDSUxjRnFDVVUvUFZ3RjRvTjRaUktEZ01FM3FKTUFM?=
 =?utf-8?B?cVpzZk1jdnZqN1JTVU1iOHROdDhOVVlTRmpkTVhtZm5xTlloS2tsYStqSjdj?=
 =?utf-8?B?ak9JcnRYOUErei9TeXY1d0NEM0R3bzBRR1lGaVhGcjdIMWxPY05LTG8rRVRB?=
 =?utf-8?B?QVkvT1JXeklxZjJjRmpEKzJWUi9CQ0FuUm5hUVNCNVlOUEhhandYT1IwbDZz?=
 =?utf-8?B?NmhSZVp0VGEza1BoVStpajFSVytTUnlneWw2Mkh1akZEUmxkQVdpUVFFK09w?=
 =?utf-8?B?MEE2N0txeEtnekw4ZG90b1RXVy9FMmFLSE12OThSWVlhVHFNL2ttMGJ5Ujh4?=
 =?utf-8?B?VzA2UE5vcFRVMXdjelErblRQbjFneTdKOE5HdEdFM2NlT0NNWDA2SWRpMkhU?=
 =?utf-8?B?YWdEaUdoVTZMcW1RYzhFb2NtR3A4TXZJZXNGcVJpTVdGZGg3NmZ3K1c0RjAy?=
 =?utf-8?B?UmVqNWtGWDBDVU8zVVF0bUZiOHpVZ1BIWkt1YTlXTTZOU3Z1YWFhK2ZaNW1Z?=
 =?utf-8?B?MDBQOTNPc2xDK3JFSkduZFZXMnhYOEZIQVA5bGYwWXQ3YTR5a2xHT2hBQkxJ?=
 =?utf-8?B?NVM4cUNtMzZVUGpxYlZDdWZGd2FNeWlmRzA1WlVNSm1BTmpkMURIL1ZwaHBa?=
 =?utf-8?B?V21RVkRCYWNxSC9ZWERET2hmMy9mZkpscjF0NDFSVGdiTXMwMGFaK2I1SDJ5?=
 =?utf-8?B?azI4c2NDMS9kRnVMaDVkRE1sOWxqc3JqRVAxOGhyalhzMGJSWGdSOEttTFd3?=
 =?utf-8?B?SyszMkhpdXpIaElUWHROUXUxdEhjU2t3ZzQzdkpaUG92OTZ1ZGNFQTd1R2RN?=
 =?utf-8?B?V20zRGJnLzhsZmlxMkVnaDhkTGdKaE15eTdpWjFOZ2ZxOG5pYXNxWDZVQzFV?=
 =?utf-8?B?dDVmTmh3aXZhc0NyT3JuZXVKaXdwRGtwaWhVaEo3VDM5QkF1OGNJNnUxZTZI?=
 =?utf-8?Q?uSNk9VcMquT7dyOUA3OrVVCU6?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a18372dd-2a12-4c36-5e51-08daaa90eeff
X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB6309.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2022 07:27:48.9478
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: OAI+TD9s56aIKRMFr8LqPzL+t1+PPeeZg3kVmQrqJS4OxRTHyKtXv9KSnNxhy0ihOPIR0klfFaajAc2P3KN/BQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB5008
X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

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://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
> 
> Cc: "Nikunj A. Dadhania" <nikunj@amd.com>
> Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> +/**
> + * 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.

> +	gcm_crypt(ctx, dst, src, crypt_len, ctr);
> +	return 0;
> +}
> +EXPORT_SYMBOL(gcm_decrypt);
> +
> +MODULE_DESCRIPTION("Generic GCM library");
> +MODULE_AUTHOR("Ard Biesheuvel <ardb@kernel.org>");
> +MODULE_LICENSE("GPL");

Regards
Nikunj