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

List:       linux-crypto
Subject:    RE: Announce loop-AES-v1.3b file crypto package
From:       "IT3 Stuart B. Tener, USNR-R" <stuart () bh90210 ! net>
Date:       2001-07-10 16:15:24
[Download RAW message or body]

Mr. Ruusu:

	So your saying if your playing a CD on the laptop at the same time as doing
work, the CD will get funky, hmmmm....okay.

Well, the IV problem is being resolved, so lets put that to the side for the
moment, and review the solution when it comes forth very soon.

	I do admit that doing certain things in user-space vs. kernel-space does
have some advantages, and certain can make installation and maintenance
easier, however, I would hope the crypto API would find implementation
across the kernel for doing some of things addressed in the email posted
today (encrypting swap space, etc.).


Very Respectfully,

Stuart Blake Tener, IT3, USNR-R, N3GWG
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.

Tuesday, July 10, 2001 3:23 AM

-----Original Message-----
From: root@Misty.com [mailto:root@Misty.com]On Behalf Of Jari Ruusu
Sent: Tuesday, July 10, 2001 2:29 AM
To: stuart@bh90210.net
Cc: Dale Amon; linux-crypto@nl.linux.org
Subject: Re: Announce loop-AES-v1.3b file crypto package

"IT3 Stuart B. Tener, USNR-R" wrote:
> Mr. Ruusu:
>
>         Let us stay focused on bugs, and not latency issues. After all, I
am
> running a laptop with no other users (but me) on it, so performance is not
> going to sway the bulk of crypto users whom are individuals unless the
> performance hit is grossly unacceptable, obviously not if no one has
> mentioned it yet.

CD quality audio does not tolerate large delays in scheduling.

>         Are you arguing that my issuing an mkfs with the proper block
size,
> the I-patch would still be a time bomb?

mkfs, fsck and other user level tools do not currently set the block size
variable (which resides in kernel RAM). Even when mounting (kernel code
executing) the superblock is read using a default block size. Shit hits the
fan when disk is read with different block size from what was used to write
it.

>         Now on the issue of "fatware" as you note, I disagree predicated
> more on a philosophical issue, that the integration of crypto into the
> kernel will be cause for more people to leverage it across a greater
number
> of applications. I also do not "just want" loop aes I want it all. Crypto
> for PPP, Crypto for logon passwords, Crypto for whatever.

What exactly does international crypto patch offer besides encrypted
loopback and bloat that nobody uses? Read the source, man.

>         If IV was 512-byte based, how would this resolve the issue for
CD-ROM
> users?

512 byte based IV would recalculate new IV and restart the CBC chaining
after every 512 bytes transferred.

>         A better solution (IMHO) would be to create an I-patch that does
not choke
> on most distributions, and does not REQUIRE the Linus kernel to work.

You just described what loop-AES does, and does it well. This is from
loop-AES README file: "This package does *not* modify your kernel in any
way, so you are free to use kernels of your choice, with or without cool
patches."

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/

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