[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-crypto
Subject:    RE: loop-AES supported ciphers
From:       "IT3 Stuart Blake Tener, USNR-R" <stuart () bh90210 ! net>
Date:       2002-02-28 13:23:12
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]