[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 20:42:11
[Download RAW message or body]

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/

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