Herbert: If in fact Jari is recreating the i-patch via Loop-aes, (or perhaps whatever he chooses to rename it to), and loop-aes is able to 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! I personally take issue with the i-patch predicated on several issues, the first being it is terribly difficult (at least it was for me), to try to use it on any kernel I choose. Loop-aes seems not to stick you with this issue, and that (to me) is a big gain. The i-patch, will one day have a big advantage when it is inclusive to all kernels by default (if accepted by Linus one day), but prior to that, it is very hard to justify all the effort (for an individual) to keep it working with different kernels, too much trouble (if you ask me). Well let me rephrase that, too much trouble with little gain over loop-aes, until now, when only one algorithm was present in loop-ase instead a multi algorithm implementation as Jari no doubt plans (I presume he intends to support the same algorithms the crypto patch does now) 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. 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. Having a crypto API within Linux is not only a necessity in the future, but also downright in demand. Once this is done, and a standard for crypto is built into Linux, we will be on a different page. I to this day do not understand why Linux has not (at minimum) been designed to have standard crypto API calls in it, which in the kernel could be dummy calls, which only would work if someone independently compiled and loaded modules not otherwise part of the kernel, in order to keep the kernel in its current world-exportable mode, but allow for standardization of crypto calls. If this cannot be accomplished (perhaps predicated on the current legislative state of affairs), then I feel that Linus ought to be the maintainer of a separate crypto based version of the kernel (separate from the non-crypto version), which has a crypto API built in, and maintained by his group of developers separately. As long as the i-patch is an independent effort, not under the scope or inclusive to those sources as other distributors of Linux (like RH, SuSE, etc.) are all working with the same problem of non-standard ability for implementation across all distribution kernel sources will exist. An answer to this problem must be achieved if the i-patch is ever to become a viable choice. I beseech someone to resolve this, as it is the method I prefer absent the prior objections I stated above. If the i-patch could easily be applied to any kernel source I choose, I would see it as the superior choice, it cannot easily do so, and this is a major flaw. A major flaw, not because you do not support all kernels know to mankind, but because it is not an accepted part of the kernel which by default ought to be in all kernels known to mankind. 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. Sunday, January 13, 2002 4:38 AM -----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 12:59 AM To: Jari Ruusu Cc: linux-crypto@nl.linux.org Subject: Re: loop-AES supported ciphers hello! 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 ;-) anyway, I can't help thinking that you're in the process of recreating the international kernel patch.... 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 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... 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/
