From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH v3 5/7] crypto: arc4 - remove cipher implementation
Date: Tue, 11 Jun 2019 10:39:39 -0700 [thread overview]
Message-ID: <20190611173938.GA66728@gmail.com> (raw)
In-Reply-To: <20190611134750.2974-6-ard.biesheuvel@linaro.org>
On Tue, Jun 11, 2019 at 03:47:48PM +0200, Ard Biesheuvel wrote:
> There are no remaining users of the cipher implementation, and there
> are no meaningful ways in which the arc4 cipher can be combined with
> templates other than ECB (and the way we do provide that combination
> is highly dubious to begin with).
>
> So let's drop the arc4 cipher altogether, and only keep the ecb(arc4)
> skcipher, which is used in various places in the kernel.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> crypto/arc4.c | 46 ++------------------
> 1 file changed, 4 insertions(+), 42 deletions(-)
>
> diff --git a/crypto/arc4.c b/crypto/arc4.c
> index 6974dba1b7b9..79a51e9f90ae 100644
> --- a/crypto/arc4.c
> +++ b/crypto/arc4.c
> @@ -13,23 +13,12 @@
> #include <linux/init.h>
> #include <linux/module.h>
>
> -static int arc4_set_key(struct crypto_tfm *tfm, const u8 *in_key,
> - unsigned int key_len)
> -{
> - struct arc4_ctx *ctx = crypto_tfm_ctx(tfm);
> -
> - return arc4_setkey(ctx, in_key, key_len);
> -}
> -
> static int arc4_set_key_skcipher(struct crypto_skcipher *tfm, const u8 *in_key,
> unsigned int key_len)
> {
> - return arc4_set_key(&tfm->base, in_key, key_len);
> -}
> + struct arc4_ctx *ctx = crypto_tfm_ctx(&tfm->base);
>
> -static void arc4_crypt_one(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> -{
> - arc4_crypt(crypto_tfm_ctx(tfm), out, in, 1);
> + return arc4_setkey(ctx, in_key, key_len);
> }
>
> static int ecb_arc4_crypt(struct skcipher_request *req)
Can you clean up the naming here?
arc4_set_key_skcipher() => crypto_arc4_setkey()
ecb_arc4_crypt() => crypto_arc4_crypt()
The current names were intended to distinguish the "skcipher" functions from the
"cipher" functions, but that will no longer be needed.
Also, crypto_arc4_setkey() should use crypto_skcipher_ctx() rather than
crypto_tfm_ctx(), now that it only handles "skcipher".
> @@ -50,23 +39,6 @@ static int ecb_arc4_crypt(struct skcipher_request *req)
> return err;
> }
>
> -static struct crypto_alg arc4_cipher = {
> - .cra_name = "arc4",
> - .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
> - .cra_blocksize = ARC4_BLOCK_SIZE,
> - .cra_ctxsize = sizeof(struct arc4_ctx),
> - .cra_module = THIS_MODULE,
> - .cra_u = {
> - .cipher = {
> - .cia_min_keysize = ARC4_MIN_KEY_SIZE,
> - .cia_max_keysize = ARC4_MAX_KEY_SIZE,
> - .cia_setkey = arc4_set_key,
> - .cia_encrypt = arc4_crypt_one,
> - .cia_decrypt = arc4_crypt_one,
> - },
> - },
> -};
> -
> static struct skcipher_alg arc4_skcipher = {
Similarly this could be renamed from arc4_skcipher to arc4_alg, now that the
skcipher algorithm doesn't need to be distinguished from the cipher algorithm.
> .base.cra_name = "ecb(arc4)",
Given the confusion this name causes, can you leave a comment? Like:
/*
* For legacy reasons, this is named "ecb(arc4)", not "arc4".
* Nevertheless it's actually a stream cipher, not a block cipher.
*/
.base.cra_name = "ecb(arc4)",
Also, due to removing the cipher algorithm, we need the following testmgr change
so that the comparison self-tests consider the generic implementation of this
algorithm to be itself rather than "ecb(arc4-generic)":
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 658a7eeebab28..5d3eb8577605f 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -4125,6 +4125,7 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}, {
.alg = "ecb(arc4)",
+ .generic_driver = "ecb(arc4)-generic",
.test = alg_test_skcipher,
.suite = {
.cipher = __VECS(arc4_tv_template)
- Eric
next prev parent reply other threads:[~2019-06-11 17:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 13:47 [PATCH v3 0/7] crypto: rc4 cleanup Ard Biesheuvel
2019-06-11 13:47 ` [PATCH v3 1/7] crypto: arc4 - refactor arc4 core code into separate library Ard Biesheuvel
2019-06-11 13:47 ` [PATCH v3 2/7] net/mac80211: move WEP handling to ARC4 library interface Ard Biesheuvel
2019-06-11 13:51 ` Johannes Berg
2019-06-11 13:53 ` Ard Biesheuvel
2019-06-11 13:55 ` Johannes Berg
2019-06-11 13:56 ` Ard Biesheuvel
2019-06-11 13:58 ` Johannes Berg
2019-06-11 17:54 ` Eric Biggers
2019-06-11 13:47 ` [PATCH v3 3/7] net/lib80211: move WEP handling to ARC4 library code Ard Biesheuvel
2019-06-11 17:59 ` Eric Biggers
2019-06-11 13:47 ` [PATCH v3 4/7] net/lib80211: move TKIP " Ard Biesheuvel
2019-06-11 13:47 ` [PATCH v3 5/7] crypto: arc4 - remove cipher implementation Ard Biesheuvel
2019-06-11 17:39 ` Eric Biggers [this message]
2019-06-12 15:33 ` Eric Biggers
2019-06-12 15:39 ` Ard Biesheuvel
2019-06-11 13:47 ` [PATCH v3 6/7] ppp: mppe: switch to RC4 library interface Ard Biesheuvel
2019-06-11 13:47 ` Ard Biesheuvel
2019-06-11 18:08 ` Eric Biggers
2019-06-11 18:08 ` Eric Biggers
2019-06-11 13:47 ` [PATCH v3 7/7] fs: cifs: " Ard Biesheuvel
2019-06-11 18:17 ` Eric Biggers
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=20190611173938.GA66728@gmail.com \
--to=ebiggers@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=johannes@sipsolutions.net \
--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 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.