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;
MIME-Version: 1.0
References: <20221007152105.3057788-1-ardb@kernel.org> <3e395ad2-48f6-87f6-9042-a3ca21c0baba@amd.com>
 <CAMj1kXGNXYvS9_-RwzzO-VeZN8+ZErhxGiCbfbBA5thJ84RxYA@mail.gmail.com> <ecc2207e-4845-f467-1926-e675f78c6b2e@amd.com>
In-Reply-To: <ecc2207e-4845-f467-1926-e675f78c6b2e@amd.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 10 Oct 2022 10:44:28 +0200
Message-ID: <CAMj1kXF5+i9SJ3zuua8TCQVRutVt80v85dgjde3sb3+J+=pKHg@mail.gmail.com>
Subject: Re: [PATCH] crypto: gcm - Provide minimal library implementation
To:     "Nikunj A. Dadhania" <nikunj@amd.com>
Cc:     linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au,
        ebiggers@kernel.org, keescook@chromium.org, jason@zx2c4.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, 10 Oct 2022 at 10:25, Nikunj A. Dadhania <nikunj@amd.com> wrote:
>
>
>
> On 10/10/22 13:45, Ard Biesheuvel wrote:
> > On Mon, 10 Oct 2022 at 09:27, Nikunj A. Dadhania <nikunj@amd.com> 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@amd.com>
> >>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >>> ---
...
> >> 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@amd.com>

OK, good to know - thanks.