linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 1/7] crypto: arc4 - refactor arc4 core code into separate library
Date: Mon, 10 Jun 2019 09:32:17 -0700	[thread overview]
Message-ID: <20190610163216.GC63833@gmail.com> (raw)
In-Reply-To: <CAKv+Gu-az2BBVLpKqw=m_5ttXYRT95CE8toxt8-+W13A_jmuAg@mail.gmail.com>

On Mon, Jun 10, 2019 at 06:10:41PM +0200, Ard Biesheuvel wrote:
> On Mon, 10 Jun 2019 at 18:06, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > Just some bike shedding:
> >
> > On Sun, Jun 09, 2019 at 01:55:03PM +0200, Ard Biesheuvel wrote:
> > > diff --git a/include/crypto/arc4.h b/include/crypto/arc4.h
> > > index 5b2c24ab0139..62ac95ec6860 100644
> > > --- a/include/crypto/arc4.h
> > > +++ b/include/crypto/arc4.h
> > > @@ -6,8 +6,21 @@
> > >  #ifndef _CRYPTO_ARC4_H
> > >  #define _CRYPTO_ARC4_H
> > >
> > > +#include <linux/types.h>
> > > +
> > >  #define ARC4_MIN_KEY_SIZE    1
> > >  #define ARC4_MAX_KEY_SIZE    256
> > >  #define ARC4_BLOCK_SIZE              1
> > >
> > > +struct crypto_arc4_ctx {
> > > +     u32 S[256];
> > > +     u32 x, y;
> > > +};
> > > +
> > > +int crypto_arc4_set_key(struct crypto_arc4_ctx *ctx, const u8 *in_key,
> > > +                     unsigned int key_len);
> > > +
> > > +void crypto_arc4_crypt(struct crypto_arc4_ctx *ctx, u8 *out, const u8 *in,
> > > +                    unsigned int len);
> >
> > How about naming these just arc4_* instead of crypto_arc4_*?  The crypto_*
> > prefix is already used mostly for crypto API helper functions, i.e. functions
> > that take take one of the abstract crypto API types like crypto_skcipher,
> > shash_desc, etc.  For lib functions, the bare name seems more appropriate.  See
> > e.g. sha256_update() vs. crypto_sha256_update().
> >
> 
> That is also fine, although I am slightly concerned that we may run
> into trouble with other algorithms in the future. But I do agree it
> makes sense to make a clear distinction with the full blown API.
> 
> > > +++ b/lib/crypto/Makefile
> > > @@ -0,0 +1,3 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +obj-$(CONFIG_CRYPTO_LIB_ARC4) += libarc4.o
> > > diff --git a/lib/crypto/libarc4.c b/lib/crypto/libarc4.c
> > > new file mode 100644
> > > index 000000000000..b828af2cc03b
> > > --- /dev/null
> > > +++ b/lib/crypto/libarc4.c
> > > @@ -0,0 +1,74 @@
> >
> > How about arc4.c instead of libarc4.c?  The second "lib" is redundant, given
> > that the file is already in the lib/ directory.
> >
> 
> The problem here is that we'll end up with two modules named arc4.ko,
> one in crypto/ and one in lib/crypto/. Perhaps we should rename the
> other one? (especially once it implements ecb(arc4) only.)

Another option is to do:

obj-$(CONFIG_CRYPTO_LIB_ARC4) += libarc4.o
libarc4-y := arc4.o

Also, CONFIG_CRYPTO_LIB_ARC4 needs to actually be a tristate.
It seems you accidentally made it a bool:

> +config CRYPTO_LIB_ARC4
> +	bool
> +

- Eric

  reply	other threads:[~2019-06-10 16:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 11:55 [PATCH v2 0/7] crypto: rc4 cleanup Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 1/7] crypto: arc4 - refactor arc4 core code into separate library Ard Biesheuvel
2019-06-10 16:06   ` Eric Biggers
2019-06-10 16:10     ` Ard Biesheuvel
2019-06-10 16:32       ` Eric Biggers [this message]
2019-06-09 11:55 ` [PATCH v2 2/7] net/mac80211: move WEP handling to ARC4 library interface Ard Biesheuvel
2019-06-09 20:08   ` Johannes Berg
2019-06-10 10:58     ` Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 3/7] net/lib80211: move WEP handling to ARC4 library code Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 4/7] net/lib80211: move TKIP " Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 5/7] crypto: arc4 - remove cipher implementation Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 6/7] ppp: mppe: switch to RC4 library interface Ard Biesheuvel
2019-06-09 11:55 ` [PATCH v2 7/7] fs: cifs: " Ard Biesheuvel
2019-06-09 22:03   ` Steve French
2019-06-10 16:17     ` Eric Biggers
2019-06-10 17:54       ` Steve French
2019-06-10 18:02         ` Ard Biesheuvel
2019-06-10 18:59           ` Steve French
2019-06-09 12:03 ` [PATCH v2 0/7] crypto: rc4 cleanup Ard Biesheuvel

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=20190610163216.GC63833@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@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).