[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    Re: loop-AES supported ciphers
From:       Jari Ruusu <jari.ruusu () pp ! inet ! fi>
Date:       2002-02-28 18:11:01
[Download RAW message or body]

Herbert Valerio Riedel wrote:
> On Wed, 2002-02-27 at 22:00, Jari Ruusu wrote:
> > So many people have asked about more ciphers for loop-AES that next release
> > may have additional extra-ciphers package with at least serpent, blowfish
> > and twofish ciphers.
> ...you may consider changing loop-AES name to something more generic
> then ;-)

It is going to be add-on package (a separate tarball). Loop-AES core will
remain AES only. One of the reasons is that loop-AES supports old 2.0
kernels, but externally loaded ciphers only work with 2.2 and later kernels
only.

> anyway, I can't help thinking that you're in the process of recreating
> the international kernel patch....

Cryptoapi does not support _my_ kernel of choice. If you care to examine
headers of this message, you will notice that this message is sent using
ultra stable 2.2.20aa1. This box goes down only when UPS batteries are about
to run out of juice (and for maintenance... ZIP drive died yesterday, grrr).

All 2.4 kernel versions prior to 2.4.17 died under my simple non-evil stress
tests. And that was without any crypto. 2.4.17 was first 2.4 kernel that
showed some signs of stability.

Herbert, if you are not going to support all maintained stable kernels
(especially ultra stable ones and distro vendor versions), then I will
support them... and do that without cryptoapi bloat.

> ps: ...are you aware of any data corruption problems with loop-AES in
> combination with XFS on SMP boxes under high IO load? if I get the time,
> I can try to recreate the issue with 2.4.18; it was present w/ 2.4.16
> the last time I checked, and it affected both, loop-AES and patch-int...

I am not aware of any problems with loop-AES. Like I said above, kernels
prior to 2.4.17 were unstable in my tests.

> > I copied and audited serpent and blowfish from cryptoapi, and took twofish
> > from SuSE kernel sources. Just for the record, blowfish implementation in
> > cryptoapi on little endian boxes is not straight blowfish, but some
> > mutated-byteorder-variation. Cryptoapi blowfish on big endian boxes
> > implements blowfish correctly.
> btw, that's a known problem (see this mailing lists archives for more
> details); when it was detected it was too late, thus left so, since it
> would have broken existing encrypted volumes...

I corrected the bug, but added a "bug-compatible" option so that existing
cryptoapi-mutated disk images can be mounted (also had to add RIPE-MD160
password hash for 100% compatibility).

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>
-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/

[prev in list] [next in list] [prev in thread] [next in thread]