On Wed, Aug 27, 2003 at 03:26:48AM +0200, Alessandro Avagliano wrote: > I am a little confused about > cryptoapi implementation on kernel 2.4.21 and 2.4.22. > I can see a new submenu named 'Cryptographic options' > wich contains various digest algorithms, aes and other. > > Does anyone can explain me what is happening? that is a backport to 2.4 of the 2.6 scatterlist based cryptoapi; > The patch-int from ftp://ftp.kernel.org/pub/linux/kernel/people/hvr/testing > will no longer be required? starting with (mainstream) 2.4.22 the patch won't apply anymore; but 2.4.22 only contains the cryptoapi, nothing more! if you want ipsec or cryptoloop support, you'll have to apply additional patches anyway; > Does the current kernel version contain a stable (and usable) implementation > of cipher algorithm like aes, twofish, blowfish and serpent ? many cipher implementations in the current kernel version use the same implementations that were part of the patch-int's of previous kernel versions; > New kernel versions will ship with a full implemention of cryptoapi and will > not need patch? yes; except that 2.4 (as opposed to 2.6) will need patches to add cryptoloop and/or ipsec capatibilites; > Actually I'm running a 2.4.20 with patch-int-2.4.20-1, > and I have about 120gb of encrypted data with aes-twofish since a year ago. > I had some problems applying the patch-int-2.4.21.0 to the kernel 2.4.21. > but now with 2.4.22 and patch-cryptoloop-hvr-2.4.22.0 I can see that the > cryptoloop support is now located under block devices and all seems ok. > Does anyone can tell me if I can upgrade to kernel 2.4.22 with the last > cryptoloop-hvr patch without losing my data and if the new cryptographic api > is backward compatible with my 2.4.19? the API itself is not backward compatible, the old api was based on unfragmented contiguous memory buffers for operations, while the new api is based on scatterlist buffers; I assume what you really care for, is whether the algorithms are compatible -- well yes, they should, since the specs and the test vectors are the same (*) quick tests have shown it to be compatible -- (*)except for a few ciphers which got endian reversed (such as serpent), but that's something you'll notice the moment you try to mount a volumen...; but only long-term testing will show whether the new framework is robust; should you experience lockups with patch-cryptoloop-hvr, I'd recommend you try patch-cryptoloop-jari, which implements aggressive buffering; ps: I can't give you any guarantee about not losing your data, since the code is rather new and hasn't had much time to prove it's reliability yet; I'd recommend you try to mount read-only your partitions and see whether your data is still non-corrupt, that would at least test the read/deciphering code paths and show that decoding is compatible; then you could create a new dummy volume and stresstest write/read on it, while comparing data integrity, that would show that reading and writing with the new code does work; that together with the read-only test of your 'old' data should prove that the new framework is usable, and you might want to risk mounting your old data volumes read/write... but still, if your data is important, you should backup it nevertheless; 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/
