Herbert Valerio Riedel wrote: > On Tue, 2002-03-05 at 16:43, Jari Ruusu wrote: > > Because cryptoapi works with very limited set of kernels, and with none of > > the ultra stable kernels. Loop-AES works with all maintained stable kernels, > > including distro vendor kernels. Meaning that if you use cryptoapi, HVR > > chooses your kernel for you. If you use loop-AES, crypto adapts to _your_ > > choice of kernel. That is a big difference. > ...and with loop-aes, you choose the set of ciphers your users use... > ;-) Yes, and people bitched and moaned about it. Now they have portable (as in works with all stable linux kernels in use today) loop encryption with more than one cipher available. > > Another disadvantage that cryptoapi loop has, is the cryptoapi bloat that > > makes it slower than loop-AES. Loop-AES does not use cryptoapi, and that is > > a feature. > btw, I wondering, whether we have any objective measurements of the > overhead involved wrt using the additional abstraction layer w/ > cryptoapi... Tested on 2.4.18 kernel, Pentium-2 300 MHz, ST34342A IDE disk Implementation Cipher Total CPU cycles spent in system mode -------------- ------ ------------------------------------- cryptoapi AES-128 54 % loop-AES AES-128 36 % cryptoapi serpent-128 81 % loop-AES serpent-128 78 % All above implementations used the disk at maximum data transfer rate supported by the disk, so megabytes/sec rate was same for all ciphers on unloaded test box. Serpent implementations used same cipher source code. Cryptoapi overhead on loop encryption seems to be few percent of CPU cycles. 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/
