All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.