Herbert: I never said you had an issue with giving users a choice of algorithms to choose from, I am just stating that cryptoapi needs to become a permanent part of the Linus kernel before people will begin to accept it. As it is now, every time I rebuild my kernel, I need to build, install and merge the NVIDIA drivers, and the ltmodem drivers. I don't want to think that building a new kernel is going to turn into a massive issues, just so I can patch it to use crypto. Too much trouble. I do however, agree that a the idea of a cryptoapi in general (in the kernel) is a good one, if it is going to be part of all standard kernels from now forward. In other words if knowing what kernel version cryptoapi works with can be more complicated than any kernel after version x.y.z, then it will not be an easily deployable patch. Does your cryptoapi work flawlessly with a Linus kernel of 2.4.18, or 2.4.19pre1? Very Respectfully, Stuart Blake Tener, IT3 (E-4), USNR-R, N3GWG Beverly Hills, California VTU 1904G (Volunteer Training Unit) stuart@bh90210.net west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's free!) JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL. Thursday, February 28, 2002 12:40 PM -----Original Message----- From: linux-crypto-bounce@nl.linux.org [mailto:linux-crypto-bounce@nl.linux.org] On Behalf Of Herbert Valerio Riedel Sent: Thursday, February 28, 2002 10:39 AM To: linux-crypto@nl.linux.org Subject: RE: loop-AES supported ciphers On Thu, 2002-02-28 at 14:23, IT3 Stuart Blake Tener, USNR-R wrote: > present the same level of crypto support (or maybe even more crypto > choices than the i-patch) in terms of algorithms that the i-patch > supports, then this is good! just to make one thing clear: I have no problem at all w/ giving the user more choice, as to which software to use; that's why I like cryptoapi's variety of ciphers... [..] > Secondly, I must tell you I do not agree with this idea of > "known bugs", if someone (or a corporation, like SuSE) knows there is a > "known bug", or an imperfect implementation (i.e. with blowfish), they > have a responsibility to fix it, and offer a transition path to correct > it. btw, that cryptoapi thing is more a 'known issue' than a 'known bug' why? because a bug usually leads to loss of data or something different; but since the patch-int was the only encryption package to read and write such blowfish encrypted volumes there was no real need to change that... or was there any established volume-encryption format, to which compatibility would have been broken? ok, the bug about it is, that on big-endian machines the on-disk format is different... but as said in a mail before, this blowfish issue will be resolved... i.e. by fixing the current, and providing a compat-blowfish cipher... > Not that all of these problems are the fault of the authors of > the i-patch, clearly they all are not, but, since loop-aes fails to > enact these issues, I see it as a clear advantage for the moment. if you only need disk-encryption, then cryptoapi may be overkill... but the projects using cryptoapi as their cipher-repository is growing... [..] regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org 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/
