linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Iuliana Prodan <iuliana.prodan@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v2 2/2] crypto: aes - helper function to validate key length for AES algorithms
Date: Wed, 31 Jul 2019 11:50:11 +0300	[thread overview]
Message-ID: <CAKv+Gu8KcL_Q_C+euZ9DOT7VEX68CJZJLrT8hxeCiiiEkxQ=jQ@mail.gmail.com> (raw)
In-Reply-To: <VI1PR04MB4445AABC9062673BD4FA3CEF8CDF0@VI1PR04MB4445.eurprd04.prod.outlook.com>

On Wed, 31 Jul 2019 at 11:35, Iuliana Prodan <iuliana.prodan@nxp.com> wrote:
>
> On 7/31/2019 8:33 AM, Ard Biesheuvel wrote:
> > On Tue, 30 Jul 2019 at 13:33, Iuliana Prodan <iuliana.prodan@nxp.com> wrote:
> >>
> >> Add inline helper function to check key length for AES algorithms.
> >> The key can be 128, 192 or 256 bits size.
> >> This function is used in the generic aes implementation.
> >>
> >> Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
> >> ---
> >>   include/crypto/aes.h | 17 +++++++++++++++++
> >>   lib/crypto/aes.c     |  8 ++++----
> >>   2 files changed, 21 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/crypto/aes.h b/include/crypto/aes.h
> >> index 8e0f4cf..8ee07a8 100644
> >> --- a/include/crypto/aes.h
> >> +++ b/include/crypto/aes.h
> >> @@ -31,6 +31,23 @@ struct crypto_aes_ctx {
> >>   extern const u32 crypto_ft_tab[4][256] ____cacheline_aligned;
> >>   extern const u32 crypto_it_tab[4][256] ____cacheline_aligned;
> >>
> >> +/*
> >> + * validate key length for AES algorithms
> >> + */
> >> +static inline int crypto_aes_check_keylen(unsigned int keylen)
> >
> > Please rename this to aes_check_keylen()
> >
> I just renamed it to crypto_, the first version was check_aes_keylen
> - see https://patchwork.kernel.org/patch/11058869/.
> I think is better to keep the helper functions with crypto_, as most of
> these type of functions, in crypto, have this prefix.
>

The AES library consists of

aes_encrypt
aes_decrypt
aes_expandkey

and has no dependencies on the crypto API, which is why I omitted the
crypto_ prefix from the identifiers. Please do the same for this
function.
.


> >> +{
> >> +       switch (keylen) {
> >> +       case AES_KEYSIZE_128:
> >> +       case AES_KEYSIZE_192:
> >> +       case AES_KEYSIZE_256:
> >> +               break;
> >> +       default:
> >> +               return -EINVAL;
> >> +       }
> >> +
> >> +       return 0;
> >> +}
> >> +
> >>   int crypto_aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
> >>                  unsigned int key_len);
> >>
> >> diff --git a/lib/crypto/aes.c b/lib/crypto/aes.c
> >> index 4e100af..3407b01 100644
> >> --- a/lib/crypto/aes.c
> >> +++ b/lib/crypto/aes.c
> >> @@ -187,11 +187,11 @@ int aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
> >>   {
> >>          u32 kwords = key_len / sizeof(u32);
> >>          u32 rc, i, j;
> >> +       int err;
> >>
> >> -       if (key_len != AES_KEYSIZE_128 &&
> >> -           key_len != AES_KEYSIZE_192 &&
> >> -           key_len != AES_KEYSIZE_256)
> >> -               return -EINVAL;
> >> +       err = crypto_aes_check_keylen(key_len);
> >> +       if (err)
> >> +               return err;
> >>
> >>          ctx->key_length = key_len;
> >>
> >> --
> >> 2.1.0
> >>
> >
>

      reply	other threads:[~2019-07-31  8:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 10:33 [PATCH v2 0/2] crypto: validate inputs for gcm and aes Iuliana Prodan
2019-07-30 10:33 ` [PATCH v2 1/2] crypto: gcm - helper functions for assoclen/authsize check Iuliana Prodan
2019-07-30 11:28   ` Horia Geanta
2019-07-30 18:55   ` Horia Geanta
2019-07-30 10:33 ` [PATCH v2 2/2] crypto: aes - helper function to validate key length for AES algorithms Iuliana Prodan
2019-07-30 11:29   ` Horia Geanta
2019-07-31  5:32   ` Ard Biesheuvel
2019-07-31  8:35     ` Iuliana Prodan
2019-07-31  8:50       ` Ard Biesheuvel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu8KcL_Q_C+euZ9DOT7VEX68CJZJLrT8hxeCiiiEkxQ=jQ@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=iuliana.prodan@nxp.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).