loop-AES changes since previous release:
- Fixed externally compiled module version multi-key-v3 ioctl
incompatibility with boxes running 64 bit kernel and 32 bit userland.
Kernel patch versions were not affected (2.4 and 2.6 kernels).
- Fixed bug that made v3 on-disk format always use file backed code path on
some 2.6 kernels that did not have LO_FLAGS_DO_BMAP defined. No data loss,
but file backed code path is not journaled file system safe. Same bug also
had cosmetic side effect of "losetup -a" status query always displaying
file backed v2 on-disk format as v3 on-disk format.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2
md5sum b295ff982cd4503603b38fdc54e604cc
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2.sign
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Jari Ruusu wrote:
> loop-AES changes since previous release:
> - Fixed externally compiled module version multi-key-v3 ioctl
> incompatibility with boxes running 64 bit kernel and 32 bit userland.
> Kernel patch versions were not affected (2.4 and 2.6 kernels).
> - Fixed bug that made v3 on-disk format always use file backed code path on
> some 2.6 kernels that did not have LO_FLAGS_DO_BMAP defined. No data loss,
> but file backed code path is not journaled file system safe. Same bug also
> had cosmetic side effect of "losetup -a" status query always displaying
> file backed v2 on-disk format as v3 on-disk format.
>
> bzip2 compressed tarball is here:
>
> http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2
> md5sum b295ff982cd4503603b38fdc54e604cc
>
> http://loop-aes.sourceforge.net/loop-AES/loop-AES-v3.0b.tar.bz2.sign
>
Is this eventually going in the mainline kernel? I'd like to use it, but
if I'm going to have to maintain my own crypto kernels indefinitely this
probably isn't the one for me.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Hi Bill,
On Sun, Jan 16, 2005 at 11:26:38PM -0500, Bill Davidsen wrote:
> Is this eventually going in the mainline kernel? I'd like to use it, but
> if I'm going to have to maintain my own crypto kernels indefinitely this
> probably isn't the one for me.
On a side note, I would say that this one is not particularly difficult to
apply, and Jari often includes up to date patches. Admittedly, when you want
to stick to an old kernel for a long time, it might become difficult. I've
been doing this for about 2 years now, and I cannot say that this one caused
me any nightmares yet. However, if it went into mainline, it would be better
of course !
Cheers,
Willy
Bill Davidsen wrote:
> Is this eventually going in the mainline kernel? I'd like to use it, but
> if I'm going to have to maintain my own crypto kernels indefinitely this
> probably isn't the one for me.
Unlikely to go to mainline kernel. Mainline folks are just too much in love
with their backdoored device crypto implementations [1]. If you want strong
device crypto in mainline kernel, maybe you should take a look at FreeBSD
gbde.
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=107419912024246&w=2
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
On Mon, 2005-01-17 at 17:08 +0200, Jari Ruusu wrote:
> Bill Davidsen wrote:
> > Is this eventually going in the mainline kernel? I'd like to use it, but
> > if I'm going to have to maintain my own crypto kernels indefinitely this
> > probably isn't the one for me.
>
> Unlikely to go to mainline kernel. Mainline folks are just too much in love
> with their backdoored device crypto implementations [1].
This is FUD. To get serious in-depth information about the problems
associated with dm-crypt and loop-aes read,
http://clemens.endorphin.org/LinuxHDEncSettings
This document has been reviewed by a couple of noteworthy people, also
partially to counter the on-going FUD postings, Jari Ruusu has been
posting to LKML repeatedly.
James Morris: Can we please talk about the merge of my LRW patches soon?
The insecurity of CBC based encryption such as dm-crypt and loop-aes is
the reason why I have been pushing this patch so hard for the last two
months now.
--
Fruhwirth Clemens <[email protected]> http://clemens.endorphin.org
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
> > Unlikely to go to mainline kernel. Mainline folks are just too much in love
> > with their backdoored device crypto implementations [1].
Just to add back in Jari's link, so the folks added know what you're talking
about:
> [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=107419912024246&w=2
--
Paul
On Mon, 17 Jan 2005 15:11:18 +0000, Jari Ruusu wrote:
> Mainline folks are just too much in love with their backdoored device
> crypto implementations [1]. If you want strong device crypto in mainline
> kernel, maybe you should take a look at FreeBSD gbde.
what about dm-crypt? I lost track, whether it is fixed or not.
(Or rather: whether secure modes where added, and which modes
are considered secure).
also my key is 32 random bytes and not a hash.
will I have any issue? dictionary attacks will
not work with that.
Thanks for your help.
Regards, Andreas
On Mon, 2005-01-17 at 19:29 +0000, Paul Walker wrote:
> On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
>
> > > Unlikely to go to mainline kernel. Mainline folks are just too much in love
> > > with their backdoored device crypto implementations [1].
>
> Just to add back in Jari's link, so the folks added know what you're talking
> about:
>
> > [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=107419912024246&w=2
You will find the same information on my site. Therefore, I do NOT
decline this vulnerability. I decline it's security implications. It's
on the same level as the vulnerability, that you will give away your
root password under torture.[2]
Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
should show me source code. Till then, treat it as FUD.
<off-topic>
[2] I think the torture vulnerability is more serious than any
watermarking "attack". "Rubberhosing" can be fixed btw.
http://web.archive.org/web/20031214064240/http://www.rubberhose.org/
Unfortunately, original site is down and source code outdated.
</off-topic>
--
Fruhwirth Clemens <[email protected]> http://clemens.endorphin.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fruhwirth Clemens <[email protected]> wrote:
> This is FUD. To get serious in-depth information about the problems
> associated with dm-crypt and loop-aes read,
>
> http://clemens.endorphin.org/LinuxHDEncSettings
excuse me, but that's just too academic for the end user. whatever
you're trying to say (apart from your obvious grudge against what
Jari is doing), it's not clear enough.
given the choices of dm-crypt, cryptoloop, and loop-aes it is awfully
clear what to use. your patches seem a bit like the cure to all and
everything which is suspicious like hell to me.
> This document has been reviewed by a couple of noteworthy people, also
> partially to counter the on-going FUD postings, Jari Ruusu has been
> posting to LKML repeatedly.
FUD crap for heaven's sake!
(i'm calming down, not given an example of the fuss about md5
collisions lately.... you're not applying double standards are you?!)
first of all, when whatever people review a document the document
itself is not understood any better afterwards than its virgin
cousin. as far as i'm concerned this whole silly review thing serves
the author's sleep but not the end user, so it could have been
reviewed by [email protected] for its comedy (or lack
thereof by [email protected]) ;-)
i'm not saying it's wrong, it's just that ppl don't get it who should
according to your way of communicating the matter.
btw, just being curious, but did/do you have something to add to
this?
maybe you're still just missing Jari's point.
http://lkml.org/lkml/2004/5/16/71
http://marc.free.net.ph/message/20040726.181150.d4b819be.en.html
yes, we know you replied to that message at
http://marc.free.net.ph/message/20040726.225933.cb46c940.en.html. and
there it is again: as an ordinary user i take it that you claim to
understand what Jari's point is _all along_ but yet you both fail to
communicate that clearly during the beginning of a discussion
(repeatedly as google assures me - for the fun of it?) and you yet
acknowledge that Jari's claims are legit. might i inquire why you do
so (plain and simple please it can't be that hard)?
all i see is you giving the ordinary user of crypto on linux systems
the impression that Jari's claims are untrue, and one should follow
you the hero that brings back strong crypto to mainline. everyone
else is too stupid too realise that, and so, please get going ppl.
makes me sick :(
i'm not talking about loop-aes being the best there is, it's just
that loop-aes is getting the job done. cryptoloop and dm-crypt fail
to do so, and yet you bash loop-aes instead of contributing your
academic knowledge to the project providing the best solution for the
end user so far.
which makes me wonder, there are 3 different crypto implementations
and still you had to come up with yet another one instead of being
able to somehow work together with (at least) one of the existing
ones... because of technical issues? i doubt it. loop-aes could have
been the ideal testing platform for your stuff.
> James Morris: Can we please talk about the merge of my LRW patches soon?
> The insecurity of CBC based encryption such as dm-crypt and loop-aes is
> the reason why I have been pushing this patch so hard for the last two
> months now.
several weeks back i got the impression those patches were to be
included into mainline really soon. what's the delay?
by whom have these patches of yours been tested? for how long, in
which environment? etc. "reviewed by funny people the ordinary user
doesn't know and there's no link one can check up on them on the page
reviewed" doesn't count for me i'm afraid.
i'm gonna stick to loop-aes, and sorry for the rant but i'm just sick
of wasting energy this way, kids.
@clemens: i'm not bashing your work, i'm ranting from an end user's
point of view.
- --
Bastard Administrator in $hell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFB7C2XLMyTO8Kj/uQRAi/5AJ4osZKT/D29NoHfjIT/+2cnIZXMhQCfQ31N
09aQfmhB2pwJIU1kkx6Fyf4=
=cQZG
-----END PGP SIGNATURE-----
On Mon, Jan 17, 2005 at 05:08:04PM +0200, Jari Ruusu wrote:
> Unlikely to go to mainline kernel. Mainline folks are just too much in
> love with their backdoored device crypto implementations [1]. If you want
"Backdoored" is a bit strong, I think; that tends to imply deliberate
placing of a gateway back in, rather than an oversight (which is what it
looks like to me from your email).
--
Paul
On Mon, Jan 17, 2005 at 10:04:49PM +0100, Fruhwirth Clemens wrote:
> You will find the same information on my site. Therefore, I do NOT decline
> this vulnerability. I decline it's security implications. It's on the same
I'm making no comment either way, I simply wanted to make sure everyone on
the copy list understood what you were replying to. You missed out the link
Jari referred to.
--
Paul
Brain: Are you pondering what I'm pondering?
Pinky: Well, I think so, Brain, but if they call them sad meals kids won't buy them.
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
> Fruhwirth Clemens <[email protected]> wrote:
> > This is FUD. To get serious in-depth information about the problems
> > associated with dm-crypt and loop-aes read,
> >
> > http://clemens.endorphin.org/LinuxHDEncSettings
>
> excuse me, but that's just too academic for the end user. whatever
> you're trying to say (apart from your obvious grudge against what
> Jari is doing), it's not clear enough.
I can't do nothing about that. Enlightenment is a gift everyone has to
fight for on it's own.
To the rest of your slightly emotional post. Most of the question have
been already answered. I'm not going to restate my answers, the archive
has it.
To your critiques of my reviewers:
Your personal opinion has the same importance to me as the my review
sources have to you. That's none.
What probably makes a different for others is, that the review sources
on my web pages includes kernel developers, regulars on the dm-crypt
mailing list and the IEEE chairman of Security in Storage Working Group.
I'm sorry for my ranting ignorance. Life time is a limited resource.
Especially mine.
--
Fruhwirth Clemens <[email protected]> http://clemens.endorphin.org
Hi Fruhwirth,
I don't want to take 'emotional' sides in this debate, but an
observation:
Re: "Enlightenment is a gift everyone has to fight for on it's own." If
I can contrast, Jari's code gets some good use/discussion because if a
question is raised, it gets answered *in detail* the same day (almost
always - I don't know how Jari finds the time). Now I am prepared to
accept your philosophy on life (to each his own) but OSS (open source
crypto even more so) lives (or dies) on the ability of the community to
support the software - and they will only do that if it can be
communicated effectively to the *users*. Now having been through your
web site (and most posts), I can see your interest in the subject, but
comments like this just don't help that communication!
I use loop-aes, and despite reading this debate each and every time it
comes up, not been convinced to change yet (still hoping for a
resolution and mainline merge though :-)).
Daniel.
--
Daniel Harvey <[email protected]>
On Tue, 2005-01-18 at 00:11 +0100, Fruhwirth Clemens wrote:
> On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
>
> > Fruhwirth Clemens <[email protected]> wrote:
> > > This is FUD. To get serious in-depth information about the problems
> > > associated with dm-crypt and loop-aes read,
> > >
> > > http://clemens.endorphin.org/LinuxHDEncSettings
> >
> > excuse me, but that's just too academic for the end user. whatever
> > you're trying to say (apart from your obvious grudge against what
> > Jari is doing), it's not clear enough.
>
> I can't do nothing about that. Enlightenment is a gift everyone has to
> fight for on it's own.
>
> To the rest of your slightly emotional post. Most of the question have
> been already answered. I'm not going to restate my answers, the archive
> has it.
>
> To your critiques of my reviewers:
>
> Your personal opinion has the same importance to me as the my review
> sources have to you. That's none.
>
> What probably makes a different for others is, that the review sources
> on my web pages includes kernel developers, regulars on the dm-crypt
> mailing list and the IEEE chairman of Security in Storage Working Group.
>
> I'm sorry for my ranting ignorance. Life time is a limited resource.
> Especially mine.
Hello,
i dont understand the current argument so would prefere not to enter it.
But it triggered my curiosity about current loop-aes security.
3 years ago i published a paper describing how an attacker would be able
to modify the content of the encrypted device without being detected.
http://off.net/~jme/loopdev_vul.html
i was just curious about the current state of loop-aes. Is it still
vulnerable to this attack ?
jerome etienne wrote:
> 3 years ago i published a paper describing how an attacker would be able
> to modify the content of the encrypted device without being detected.
> http://off.net/~jme/loopdev_vul.html
>
> i was just curious about the current state of loop-aes. Is it still
> vulnerable to this attack ?
Quote from loop-AES README file
"
Loop device encrypts data but does not authenticate ciphertext. In other
words, it delivers data privacy, but does not guarantee that data has not
been tampered with. Admins setting up encrypted file systems should ensure
that neither ciphertext, nor tools used to access ciphertext (kernel +
kernel modules, mount, losetup, and other utilities) can be trojaned or
tampered.
"
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
Fruhwirth Clemens wrote:
> Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
> should show me source code. Till then, treat it as FUD.
I have been submitting fix for this weakness to mainline mount (part of
util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix
it for *years* counts as intentional backdoor.
You call it whatever you want. I call it backdoor.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
On Tue, Jan 18, 2005 at 05:35:48PM +0200, Jari Ruusu wrote:
> Fruhwirth Clemens wrote:
> > Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
> > should show me source code. Till then, treat it as FUD.
>
> I have been submitting fix for this weakness to mainline mount (part of
> util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix
> it for *years* counts as intentional backdoor.
>
> You call it whatever you want. I call it backdoor.
Hi Jari,
Your crypto is good, your language is bad.
Clearly there is no intentional backdoor.
You do not gain any credibility by saying otherwise.
Next, confusing the kernel with util-linux is a strange trick.
Finally, in the time I maintained util-linux I have asked you
I don't know how often to come with a series of small clean
patches instead of a huge ugly all-or-nothing monolithic patch.
But you didnt.
Maybe you don't understand, but it does not suffice when code
is correct - it must also be maintainable.
Something rather similar is true for the kernel, I suspect.
A series of short clean patches would have solved all problems.
As it is, time may be running out - some years ago your stuff
was far superior to everything else. But alternative
approaches are being developed, and maybe loop-aes will soon
be some historic oddity.
Andries
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Andries et all,
As a loop-aes *user* and ex-cryptoloop user, I can tell you one thing - it
works, and is stable over multiple kernels, and backwards compatibility is
maintained as it evolves.
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:
loop-aes.sourceforge.net/loop-AES.README
Regarding the "backdoor", perhaps it is a poor choice of words, but clearly
exposing yourself to the watermark attack on large volumes is unnecessary and
unwarranted. How would I, a security person, explain to my customer why I did
not choose the better crypto?
Andries Brouwer wrote:
| On Tue, Jan 18, 2005 at 05:35:48PM +0200, Jari Ruusu wrote:
|
|>Fruhwirth Clemens wrote:
|>
|>>Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
|>>should show me source code. Till then, treat it as FUD.
|>
|>I have been submitting fix for this weakness to mainline mount (part of
|>util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix
|>it for *years* counts as intentional backdoor.
|>
|>You call it whatever you want. I call it backdoor.
|
|
| Hi Jari,
|
| Your crypto is good, your language is bad.
|
| Clearly there is no intentional backdoor.
| You do not gain any credibility by saying otherwise.
|
| Next, confusing the kernel with util-linux is a strange trick.
I do not see the confusion. Read the loop-AES readme.
|
| Finally, in the time I maintained util-linux I have asked you
| I don't know how often to come with a series of small clean
| patches instead of a huge ugly all-or-nothing monolithic patch.
| But you didnt.
|
| Maybe you don't understand, but it does not suffice when code
| is correct - it must also be maintainable.
It seems to have been maintained far better than cryptoloop, and is superior as
far as I can tell by using it.
|
| Something rather similar is true for the kernel, I suspect.
| A series of short clean patches would have solved all problems.
Every tried Jari's loop-AES module? For something maintained outside of
mainline, the modules compile and run perfectly across a range of kernels.
|
| As it is, time may be running out - some years ago your stuff
| was far superior to everything else. But alternative
| approaches are being developed, and maybe loop-aes will soon
| be some historic oddity.
Perhaps if you implement something like FreeBSD gbde.
http://www.freebsd.org/cgi/man.cgi?query=gbde&sektion=4
Until then I (and I am sure many others) will choose loop-AES because of its
clean set of instructions, strong multi-key crypto, on the fly multi key swap
or volume (/tmp for instance), easy instructions for GPG backed encrypted root
with key on USB dongle. Did I forget to mention tireless support by the author
of loop-AES?
I don't care to start a flame war, or to even participate in this one or the
politics of kernel code (I've gathered from the archives and elsewhere that the
author of loop-AES has tried repeatedly in the past to get his code in the
kernel), or to offend any kernel gods, but single key crypto for large volumes
is out of the question. Sorry.
Best regards,
- ---Venkat.
- -------------------------------------------------------------------------
Venkat Manakkal Tel:+1-607-546-7300 Fax: 1-607-546-7387
[email protected] http://www.rayservers.com/
[email protected] Computers. Installed Secure. Wholesale Prices.
PGP/GPG Key: https://www.rayservers.com/keys/0x12430522.asc
Get Windows Privacy Tools for free: http://winpt.sf.net/
- -------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7Ve6WdkW/RJDBSIRAtTXAJ9QHuLqs3o+RHXTezu9X8+ArYcKowCg1ANW
shO6GFnAQq7kQprQU12+BKE=
=x8bp
-----END PGP SIGNATURE-----
http://clemens.endorphin.org/LinuxHDEncSettings
Did you ever take a look at that page?!
I did. I?d say the best are the photos. The rest isn
?t much of a help.
Ever since I grabbed me SuSE Linux 8.2 and managed to
compile some standard kernel according to the
loop-aes.readme it?s proven to the world:
You do no longer need to study "Computer Science &
Economics" to encrypt 200GB serial ata drives with
128bit on AMD64 CPUs under linux.
As there is no replacement for loop-aes to be found
in the download section I?ll have to live with aes in
its "weak" CBC implementation.
Is there anyone out to think I?ll exchange
AMD64-optimized, rock solid code & working software
for dm-cryptoloop?
In case there are more complaints concerning loop-aes
everyone is free to launch either fixes or reveal
urls with something better at hand.
It should be:
-easy to compile
-rock solid in everyday usage
-survive power losses & crashes (yes, I play UT2004
from encrypted root + swap)
-compatible with the future
-third-party stand-alone software (not a kernel
patch)
-optimized for AMD64 CPU
-well documented
-bootable from removeable media
(usb-hdd/SD-Cards/etc.)
-able to move partition table from encrypted drive to
removable medium
I?m looking forward to read about your solutions!
--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f?r Mail, Message, More +++
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...
at the very least someone should merge in the assembler loop-aes routines.
all other architectural arguments/whining aside, is there any good reason
not to do this?
-Dan
On Jan 18, 2005, at 19:18, 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...
>
> at the very least someone should merge in the assembler loop-aes
> routines.
> all other architectural arguments/whining aside, is there any good
> reason
> not to do this?
As far as I am aware, from monitoring the various threads of this
discussion for a
few years, the only reason is that nobody has compiled and submitted a
set of
small, discreet, and obvious patches. I suspect if someone were to do
that, it
would be applied without much fuss or whining. The primary complaints
against
loop-AES WRT merging it (or any subset) with the mainstream kernel was
that it
is a single bigdiff, with no real subdivision.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
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.
Undoubtedly your idea of unusably slow is far more demanding than mine...
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 [email protected]:
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.
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.
[1] http://clemens.endorphin.org/patches/lrw/
--
Fruhwirth Clemens <[email protected]> http://clemens.endorphin.org
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
> I've rewritten some CBC code to fit the facilities I introduce in my LRW
> patch[1]. Here are the results for my [email protected]:
>
> 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.
This looks promising. I wonder if the generic scatterwalker solves the
null encryption performance problem that was reported a little while back.
- James
--
James Morris
<[email protected]>
On Wed, 2005-01-19 at 16:24 -0500, James Morris wrote:
> On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
>
> > I've rewritten some CBC code to fit the facilities I introduce in my LRW
> > patch[1]. Here are the results for my [email protected]:
> >
> > 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.
>
> This looks promising. I wonder if the generic scatterwalker solves the
> null encryption performance problem that was reported a little while back.
I've done some testing initially. The problem, at least with respect to
CBC, is that the NULL cipher's block size is 1. The CBC path isn't zero
originally and not even in my code (although I planned to do a zero copy
version).
However, my patch will surely bring some relieve, as my scatterwalk code
does not give up the kmapping after every block, but wait for a page to
be completely processed. So that's one kmap/kunmap instead of 4096.
P.S.: The list of recipients have grown too long and topic moved a bit.
I will remove a bunch of people if I post another follow-up. Please
check the archive if interested and not subscribed.
--
Fruhwirth Clemens <[email protected]> http://clemens.endorphin.org
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 [email protected]:
>
> 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 <[email protected]> http://clemens.endorphin.org
>
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fruhwirth Clemens <[email protected]> wrote:
> On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
>
> > Fruhwirth Clemens <[email protected]> wrote:
> > > This is FUD. To get serious in-depth information about the problems
> > > associated with dm-crypt and loop-aes read,
> > >
> > > http://clemens.endorphin.org/LinuxHDEncSettings
> >
> > excuse me, but that's just too academic for the end user. whatever
> > you're trying to say (apart from your obvious grudge against what
> > Jari is doing), it's not clear enough.
>
> I can't do nothing about that. Enlightenment is a gift everyone has to
> fight for on it's own.
yet you continue to stick the end user's nose into those hills and
mountains of enlightment (still largely to be fought for), knowing
for sure it won't do the end user any good.
so it seems to me that you're not interested in a mere end user's
feedback and even mock one's frustration about you communicating your
viewpoint.
> To the rest of your slightly emotional post. Most of the question
> have been already answered. I'm not going to restate my answers,
> the archive has it.
so i won't get answers to the questions not answered in the archives.
at least that's an answer not dripping with ... stuff.
> To your critiques of my reviewers:
>
> Your personal opinion has the same importance to me as the my
> review sources have to you. That's none.
read my lips. humor is for the gifted ones, and for everyone else
there's smilies. to repeat my feedback, unwrapped this time: include
additional info about your reviewers, a link will do just fine.
there's the slight possibility that your site's visitors may benefit
from these links, because your site does a pretty good job of leaving
end users in the dark.
let me summarize, i did not criticise your reviewers, i still am
criticising you for not stating the above on your site. may i suggest
you do so in the near future?
> What probably makes a different for others is, that the review
> sources on my web pages includes kernel developers, regulars on the
> dm-crypt mailing list and the IEEE chairman of Security in Storage
> Working Group.
not all these ppl are ignoring end users - why are you?
you seem to be anxious to state these facts on your site, be it just
for clarity's sake. seems that hill of enlightment is a full-grown
mountain, so be it. i can't tickle you every now and then for helpful
information though.
not every plant is a flower, and not everyone considers hunting down
information (which common sense would expect in plain sight) a worthy
fight for enlightment (hint hint).
> I'm sorry for my ranting ignorance. Life time is a limited
> resource. Especially mine.
I guess this is copyrighted under the GPL. please mention that fact
in the future.
/EOD
- --
Bastard Administrator in $hell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFB8DLbLMyTO8Kj/uQRAnMHAJ9zpnhjXEg24uP8zmTK1ltqNgNNtACeKhB6
HXbcBNp6xgxlcEDDK/n88Qs=
=dR7Q
-----END PGP SIGNATURE-----
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
> http://clemens.endorphin.org/LinuxHDEncSettings
I found two typos on your page:
- In LinuxHDEncSettings: at the beginning, 'pose a thread', should be 'threat'
- In 'cryptography': AFsplitter written as AFspliter.
Sytse