From: Solar Designer <solar@openwall.com>
To: Willy Tarreau <w@1wt.eu>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH] cit_encrypt_iv/cit_decrypt_iv for ECB mode
Date: Sun, 20 Aug 2006 18:49:08 +0400 [thread overview]
Message-ID: <20060820144908.GA19602@openwall.com> (raw)
In-Reply-To: <20060820080403.GA602@1wt.eu>
On Sun, Aug 20, 2006 at 10:04:03AM +0200, Willy Tarreau wrote:
> On Sun, Aug 20, 2006 at 04:23:46AM +0400, Solar Designer wrote:
> > The attached patch actually defines ecb_encrypt_iv() and
> > ecb_decrypt_iv() functions that perform ECB encryption/decryption
> > ignoring the IV, yet return -ENOSYS (just like nocrypt_iv would).
> > The result is no more Oopses and no infoleaks either.
>
> Can the cryptoloop patch use CRYPTO_TFM_MODE_CFB or CRYPTO_TFM_MODE_CTR
> and so be redirected to nocrypt() which will leave uninitialized memory
> too ?
At least patch-cryptoloop-jari-2.4.22.0 in particular will only do CBC
(default, preferred) or ECB (if requested); it won't attempt to use CFB
or CTR.
Regarding nocrypt*():
> I wonder whether we shouldn't consider that those functions must at
> least clear the memory area that was submitted to them, such as
> proposed below. It would also fix the problem for potential other
> users.
This makes sense to me, although it is not perfect as Herbert has
correctly pointed out:
> If the user is ignoring the error value here then you're in serious
> trouble anyway since they've just lost all their data.
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.
Alexander
next prev parent reply other threads:[~2006-08-20 14:53 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 [this message]
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
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=20060820144908.GA19602@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.