Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <de5768f5-8c56-bec0-0c73-04aa4805c749@ti.com> <CAKv+Gu-XNFE+=griwBJCNooyoV7BR81hkqQ9jV3PDb-P6ghYxg@mail.gmail.com>
 <82a75666-3cb7-e33d-d873-1aad5581a13c@ti.com>
In-Reply-To: <82a75666-3cb7-e33d-d873-1aad5581a13c@ti.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue, 10 Dec 2019 11:07:51 +0100
Message-ID: <CAKv+Gu9H9wFbAZwA5Gt6TaqBVEQheryP+kG+y5FsmNmf8FE5_Q@mail.gmail.com>
Subject: Re: aes_expandkey giving wrong expanded keys over crypto_aes_expand_key(older
 deprecated implementation under aes_generic)
To:     Keerthy <j-keerthy@ti.com>
Cc:     "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>, "Kristo, Tero" <t-kristo@ti.com>,
        Herbert Xu <herbert@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Tue, 10 Dec 2019 at 11:06, Keerthy <j-keerthy@ti.com> wrote:
>
>
>
> On 10/12/19 3:31 pm, Ard Biesheuvel wrote:
> > Hello Keerthy,
> >
> > On Tue, 10 Dec 2019 at 10:35, Keerthy <j-keerthy@ti.com> wrote:
> >>
> >> Hi Ard,
> >>
> >> I am not sure if am the first one to report this. It seems like
> >> aes_expandkey is giving me different expansion over what i get with the
> >> older crypto_aes_expand_key which was removed with the below commit:
> >>
> >> commit 5bb12d7825adf0e80b849a273834f3131a6cc4e1
> >> Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Date:   Tue Jul 2 21:41:33 2019 +0200
> >>
> >>     crypto: aes-generic - drop key expansion routine in favor of library
> >> version
> >>
> >> The key that is being expanded is from the crypto aes(cbc) testsuite:
> >>
> >>   }, { /* From NIST SP800-38A */
> >>                 .key    = "\x8e\x73\xb0\xf7\xda\x0e\x64\x52"
> >>                           "\xc8\x10\xf3\x2b\x80\x90\x79\xe5"
> >>                           "\x62\xf8\xea\xd2\x52\x2c\x6b\x7b",
> >>                 .klen   = 24,
> >>
> >>
> >> The older version crypto_aes_expand_key output that passes the cbc(aes)
> >> decryption test:
...
> >>
> >> The difference is between 52nd index through 59.
> >>
> >> Any ideas if this is expected?
> >>
> >
> > Yes, this is expected. This particular test vector uses a 192 bit key,
> > so those values are DC/ignored.
>
> Thanks for the quick response. However with the new implementation
> decryption test case fails for me with wrong result.

Can you share more details please? Platform, endianness, etc ...