Re: Announce loop-AES-v3.0b file/swap crypto package

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:

> On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote:
> > On Tue, 18 Jan 2005, Dan Hollis wrote:
> > 
> > > On Tue, 18 Jan 2005, Venkat Manakkal wrote:
> > > > As for cryptoloop, I'm sorry, I cannot say the same. The password hashing
> > > > system being changed in the past year, poor stability and machine lockups are
> > > > what I have noticed, besides there is nothing like the readme here:
> > > 
> > > cryptoloop is also unusably slow, even on my x86_64 machines...
> > 
> > I'm obviously doing something wrong, I just copied about 40MB of old
> > kernels (vmlinuz*) and some jpg files into a subdir on my cryptoloop
> > filesystem, and I measured 4252.2375kB/s realtime and 18819.7879 kB/s CPU
> > time. This doesn't seem unusably slow, even on my mighty P-II/350 and
> > eight year old 4GB drives. The hdb is so old it has to run in pio mode, to
> > give you an idea, and the original data was not in memory.
> 
> I've rewritten some CBC code to fit the facilities I introduce in my LRW
> patch[1]. Here are the results for my P4@xxxxxx:
> 
> loop-aes, CBC: ~30.5mb/s
> dm-crypt, CBC prior to my rewrite: ~23mb/s
> dm-crypt, CBC with my LRW patch: ~27mb/s
> dm-crypt, LRW with my LRW patch: ~27mb/s (slightly faster than CBC)
> 
> As you can see my LRW patches (actually it's the generic scatterwalker
> which is part of the LRW patch set) halves the gap to loop-aes. 

Actually I was using the built-in cryptoloop, not aes, I was just noting
that on a really slow CPU it's still usefully fast in my estimation.

> 
> I'm sure dm-crypt is never going to achieve the speed of loop-aes.
> That's just the price you pay, when you have to do things right and
> clean, so they get merged into main. Kernel developers are choosey
> customers, you know.

Yes, I delighted that cryptoloop is in the kernel. The dm-crypt is an
interesting method suitable for technically adept users who do all their
own sysadmin and need better crypto to protect something very valuable or
illegal.

But for a company trying to protect information on laptops from casual
laptop theves, the existing cryptoloop is fine, and the greater complexity
of dm-crypt isn't cost effective. Speed isn't an issue, ease of use and
avoiding training costs is.

> 
> [1] http://clemens.endorphin.org/patches/lrw/
> 
> -- 
> Fruhwirth Clemens <clemens@xxxxxxxxxxxxx>  http://clemens.endorphin.org
> 

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux