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
On Sun, Aug 20, 2006 at 06:49:08PM +0400, Solar Designer wrote:
> 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.
I thought we would not have to protect users from shooting themselves in
the foot (right now they get an oops). But I agree that the cost of
protecting them is close to zero so we probably should do it. If Herbert
is OK, do you care to provide a new patch ?
> Alexander
Thanks,
willy
On Sun, Aug 20, 2006 at 06:13:46PM +0200, Willy Tarreau 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.
>
> I thought we would not have to protect users from shooting themselves in
> the foot (right now they get an oops). But I agree that the cost of
> protecting them is close to zero so we probably should do it. If Herbert
> is OK, do you care to provide a new patch ?
Yes, if the above proposal is OK with Herbert, I will provide a new
patch for 2.4.
Thanks,
Alexander
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.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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