From: Solar Designer <solar@openwall.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH] cit_encrypt_iv/cit_decrypt_iv for ECB mode
Date: Tue, 22 Aug 2006 10:28:53 +0400 [thread overview]
Message-ID: <20060822062853.GA1673@openwall.com> (raw)
In-Reply-To: <20060820225830.GA31693@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
On Mon, Aug 21, 2006 at 08:58:30AM +1000, Herbert Xu wrote:
> On Sun, Aug 20, 2006 at 06:49:08PM +0400, Solar Designer wrote:
> >
> > Can we maybe define working but IV-ignoring functions for ECB (like I
> > did), but use memory-clearing nocrypt*() for CFB and CTR (as long as
> > these are not supported)? Of course, all of these will return -ENOSYS.
>
> In cryptodev-2.6, with block ciphers you can no longer select CFB/CTR
> until someone writes support for them so this is no longer an issue.
>
> For 2.4, I don't really mind either way what nocrypt does.
OK, I've merged Willy's suggestion for the memset()s into the patch that
I had submitted previously. The resulting patch is attached.
Alexander
[-- Attachment #2: linux-2.4.33-nocrypt.diff --]
[-- Type: text/plain, Size: 2508 bytes --]
diff -urp linux-2.4.33/crypto/cipher.c linux/crypto/cipher.c
--- linux-2.4.33/crypto/cipher.c Sun Aug 8 03:26:04 2004
+++ linux/crypto/cipher.c Tue Aug 22 09:53:35 2006
@@ -147,6 +147,15 @@ static int ecb_encrypt(struct crypto_tfm
ecb_process, 1, NULL);
}
+static int ecb_encrypt_iv(struct crypto_tfm *tfm,
+ struct scatterlist *dst,
+ struct scatterlist *src,
+ unsigned int nbytes, u8 *iv)
+{
+ ecb_encrypt(tfm, dst, src, nbytes);
+ return -ENOSYS;
+}
+
static int ecb_decrypt(struct crypto_tfm *tfm,
struct scatterlist *dst,
struct scatterlist *src,
@@ -157,6 +166,15 @@ static int ecb_decrypt(struct crypto_tfm
ecb_process, 1, NULL);
}
+static int ecb_decrypt_iv(struct crypto_tfm *tfm,
+ struct scatterlist *dst,
+ struct scatterlist *src,
+ unsigned int nbytes, u8 *iv)
+{
+ ecb_decrypt(tfm, dst, src, nbytes);
+ return -ENOSYS;
+}
+
static int cbc_encrypt(struct crypto_tfm *tfm,
struct scatterlist *dst,
struct scatterlist *src,
@@ -197,11 +215,20 @@ static int cbc_decrypt_iv(struct crypto_
cbc_process, 0, iv);
}
+/*
+ * nocrypt*() zeroize the destination buffer to make sure we don't leak
+ * uninitialized memory contents if the caller ignores the return value.
+ * This is bad since the data in the source buffer is unused and may be
+ * lost, but an infoleak would be even worse. The performance cost of
+ * memset() is irrelevant since a well-behaved caller would not bump into
+ * the error repeatedly.
+ */
static int nocrypt(struct crypto_tfm *tfm,
struct scatterlist *dst,
struct scatterlist *src,
unsigned int nbytes)
{
+ memset(dst, 0, nbytes);
return -ENOSYS;
}
@@ -210,6 +237,7 @@ static int nocrypt_iv(struct crypto_tfm
struct scatterlist *src,
unsigned int nbytes, u8 *iv)
{
+ memset(dst, 0, nbytes);
return -ENOSYS;
}
@@ -235,6 +263,11 @@ int crypto_init_cipher_ops(struct crypto
case CRYPTO_TFM_MODE_ECB:
ops->cit_encrypt = ecb_encrypt;
ops->cit_decrypt = ecb_decrypt;
+/* These should have been nocrypt_iv, but patch-cryptoloop-jari-2.4.22.0
+ * (and its other revisions) directly calls the *_iv() functions even in
+ * ECB mode and ignores their return value. */
+ ops->cit_encrypt_iv = ecb_encrypt_iv;
+ ops->cit_decrypt_iv = ecb_decrypt_iv;
break;
case CRYPTO_TFM_MODE_CBC:
prev parent reply other threads:[~2006-08-22 6:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-20 0:23 [PATCH] cit_encrypt_iv/cit_decrypt_iv for ECB mode Solar Designer
2006-08-20 8:04 ` Willy Tarreau
2006-08-20 11:20 ` Herbert Xu
2006-08-20 14:49 ` Solar Designer
2006-08-20 16:13 ` Willy Tarreau
2006-08-20 16:58 ` Solar Designer
2006-08-20 22:58 ` Herbert Xu
2006-08-22 6:28 ` Solar Designer [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=20060822062853.GA1673@openwall.com \
--to=solar@openwall.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=w@1wt.eu \
/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.