just to let you know, what the crypto patch code status is in at the moment; On Tue, 10 Jul 2001, Dale Amon wrote: > There are two known definite bugs, a backward compatibility > issue and at least two general complainst on the table. > > * BUG: block size problem > Has a current work around, Herbert has stated > he will soon have it fixed in code. fixed, if you enable the 512-byte IV option (btw, I've seen the latest recent kernels added the blocksize set/get ioctl's... just as a sidenote...) > * BUG: SMP issue > None of us has had to deal with it, but Herbert > has stated he will have it fixed in code soon. fixed > * 2.2 not readable on 2.4 > Question: is this really unknown or are the systems > in question ones that were set up with the old > absolute block number problem? If not, perhaps > it is an issue for study using a small test case. > Is there anyone here who is actually a > mathematician/cryptographer? a user space tool will allow to convert to the new IV/blocksize scheme... > * performance loss due to non-reentrancy > Presumably if Herbert fixes the SMP issue, he > sorts this as well. I might note that I play > my Mozart CD on this laptop while editing on a > loopback AES partition and have no problems. fixed as well; can someone confirm this? (the scheduling issue, was actually just a one-liner; a change from atomic to non-atomic en/de-crypting loop...) > * kernel bloat. This is probably a non-issue. Linus > will at some point go for hooks into the kernel > for encryption support. The API for that will perhaps > be influenced by kerneli but that will not be the > final word. I do suspect it will have great influence > because everyone is using the new util-linux which > supports the new api for loopback encryption types. > In that sense we are already main stream. > (The util-linux support is mainstream debian now) btw, I don't see any major kernel bloat; the actual implementation does dynamic allocation of cipher modules, and uses strings for identification; instead of having to use some magic number IDs... (see also the mknod problem and devfs; which can be regarded as kernel bloat as well... actually the whole kernel is bloat... why do we use at all a virtual machine abstraction layer instead of coding directly without any underlying OS?!? ;-) > I'm pretty sure I remember a kernel discussion on some of > the issues and there is a desire to have one single crypto > API that is available for all purposes, loopback fs or other. > While loopAES is very nice for now, and perhaps some of the code > will find its' way into the kernel, I don't see that as the > likely way things will go for 2.6.x. I'm very sure that a > loopback module will not contain its' own crypto. It will share > it with other tools and applications. We are not going to see > 5 loadable modules providing different services each with its' > own implimentation of AES. ...and that's what the cryptoapi patch tries to accomplish... the loopback module has been separated from the crypto transfer function... the CIPE project wants to make use of the cryptoapi as well; another subsystem; virtual memory encryption, can make use of the cryptoapi as well... we really need to unify all those crypto related kernel space projects; otherwise linus surely won't let them go into the kernel (at least I expect this, judging from the past ;-) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@xxxxxxxxxx / Finger hvr@xxxxxxx for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
