Announce loop-AES-v3.0b file/swap crypto package
Jari Ruusu
- 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
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
Bill Davidsen
> 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 <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Willy Tarreau
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
Jari Ruusu
> 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
-
Fruhwirth Clemens
> 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 <cle...@endorphin.org> http://clemens.endorphin.org
Paul Walker
> > 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
Fruhwirth Clemens
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>
markus reichelt
Hash: SHA1
Fruhwirth Clemens <cle...@endorphin.org> 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 mickey...@duck.tales.org for its comedy (or lack
thereof by jim....@fun.guaranteed.net) ;-)
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-----
Paul Walker
> 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
Paul Walker
> 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.
Fruhwirth Clemens
> Fruhwirth Clemens <cle...@endorphin.org> 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.
Daniel Harvey
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 <dan...@amristar.com.au>
Christian Kujau
Hash: SHA1
Paul Walker schrieb:
> 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).
i second that, "backdoored" sound like "with evil intent". an weak
implementation it is. and i hope someday Jari and the cryptoloop+dm-crypt
folks (clemens!) will join forces and present a strong storage-crypto for
mainline.
Christian
(a happy loop-aes user, and being only a *user* alarmed by the crypto-loop
weakness)
- --
BOFH excuse #285:
Telecommunications is upgrading.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7Ivl+A7rjkF8z0wRAs9OAKCQUBRKnKX5mbAqIAgFGsjjNjaYVACgt1ND
bbCKJbDNgvSmVYPliLhv0Ag=
=j/R7
-----END PGP SIGNATURE-----
jerome etienne
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 ?
Jari Ruusu
> 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
-
Jari Ruusu
> 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.
Andries Brouwer
> 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
Venkat Manakkal
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
ven...@rayservers.com http://www.rayservers.com/
rayse...@hushmail.com 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-----
Pete...@gmx.de
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 +++
jerome etienne
> 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
security isnt part of your requirement ?
Dan Hollis
> 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
Dan Hollis
> Pete...@gmx.de wrote:
> > 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:
> security isnt part of your requirement ?
If the alternatives are so cumbersome, inflexible, unstable and unusable,
then its pointless if its the most secure in the universe -- nobody will
use it anyway.
-Dan
jerome etienne
> On Wed, 19 Jan 2005, jerome etienne wrote:
>
>>Pete...@gmx.de wrote:
>>
>>>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:
>>>[...]
>>
>>security isnt part of your requirement ?
>
>
> If the alternatives are so cumbersome, inflexible, unstable and unusable,
> then its pointless if its the most secure in the universe -- nobody will
> use it anyway.
i likely miss something. why using a encrypted fs if security isnt part
of your requirement ?
-
Dan Hollis
> i likely miss something. why using a encrypted fs if security isnt part
> of your requirement ?
if the security you get is "good enough" (for that user's purposes, and
i'm sorry but you cannot be omniscient and know or dictate that to them),
they will use it. also there is nothing better at the moment (that is
usable).
as i said, if the alternative is unusable, whats the point? something is
better than nothing at all.
-Dan
Paul Walker
> as i said, if the alternative is unusable, whats the point? something is
> better than nothing at all.
That does depend on whether the something is actually making things worse
(by giving them a false sense of security) or not.
(This is totally unrelated to loop-aes or dm-cryptoloop, but an observation
borne of spending the afternoon reading Steve Gibson's pronouncements...)
--
Paul
"We are ALL Chartered Accountants." "Except me. I am a gorilla."
Dan Hollis
> On Tue, Jan 18, 2005 at 04:35:10PM -0800, Dan Hollis wrote:
> > as i said, if the alternative is unusable, whats the point? something is
> > better than nothing at all.
> That does depend on whether the something is actually making things worse
> (by giving them a false sense of security) or not.
so is it your contention loop-aes is worse than nothing at all?
-Dan
Paul Walker
> so is it your contention loop-aes is worse than nothing at all?
No. As, in fact, I said in the part of my email which you cut.
--
Paul
jerome etienne
> 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 ?
so loopaes is still vulnerable to this 3-years old attack... but one
minute before answering my email, you complained to somebody else that
"Refusing to fix it for *years* counts as intentional backdoor."
funny no :)
<joke>
if the loop-aes users have the same logic than the loop-aes author, they
should deduce that he intentionnally backdoored loop-aes.
</joke>
i *obviously* dont believe it is true, it was just a funny bug.
>
> 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.
> "
>
Bill Davidsen
> 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 <davi...@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Fruhwirth Clemens
> 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 P...@1.8GHZ:
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/
Paul Wayper
> Jari Ruusu wrote:
>
>> 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 ?
>>
>
> so loopaes is still vulnerable to this 3-years old attack... but one
> minute before answering my email, you complained to somebody else that
> "Refusing to fix it for *years* counts as intentional backdoor."
> funny no :)
The one who isn't funny is you. This is all very tedious, meaningless
pointscoring on an issue which is, actually, not very interesting to
(I'd say) a lot of us on the list. I'm not partisan in this, I've just
had to put up with you and Fruhwirth stirring up trouble for a couple of
days and I'd like you to stop.
Though I'm not an expert on the code nor have I read through all the
previous arguments, I'd say that your '3-year old attack' is not an
attack on the loop-AES package nor something that patching it can fix.
Otherwise, presumably, you'd have submitted a fix for it like a good
Open Source Citizen. Since you don't seem to have done this, I can only
assume you're just stirring up trouble. It sounds to me like your
attack would work equally well on other crypto packages that don't guard
the kernel and its tools from intruders.
I'm not interested in replies, since I don't want to waste any more time
listening to this kind of one-upmanship.
Paul
--
-- Paul Wayper at ANU - +61 2 6125 0643
Christian Kujau
Hash: SHA1
jerome etienne schrieb:
>>> to modify the content of the encrypted device without being detected.
>>> http://off.net/~jme/loopdev_vul.html
are the working implementations / patches for loop-aes/cryptoloop around?
- --
BOFH excuse #125:
we just switched to Sprint.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB7vui+A7rjkF8z0wRAinxAJ9Im7r7izMmhvB+/mUfSHt0WtAY/wCgriXg
rs3MiK8V+g7xlevwalJrb6c=
=BMFr
-----END PGP SIGNATURE-----
Pete...@gmx.de
> i likely miss something. why using a encrypted fs if security isnt part
> of your requirement ?
Encryption = safety. A common misunderstanding.
I guess the question whether you use aes in CBC or LRW or else
implementation is of less importance for security of your data as the
question where you safe your keys and what passphrases you choose.
Encryption is one single utility to keep data away from intruders. You could
also hide your disk in some "secret" place or hide your data in mp3 files,
store it on removable medium to take it with you or else.
But doesn´t encryption benefit from the possibility to store your keys and
mount utils on removable medium so that nobody can temper them while you are
away? Mr. ING. Fruhwirth listed that loop-aes is vulnerable to modifications
to losetup and the utilities needed to set up an encrypted device. Sure, but
you have such probs allways and loop-aes comes very close leaving nothing
behind but an entirely encrypted drive that looks like shredded.
Would you start a brute force attack on a device where you don´t know if it
contains encrypted data or if it is just shredded or been exposed to intense
electomagnetic curls? Don´t forget, you can allways launch brute force
attacks. The question will be, attack on what?
Loop-aes leaves behind a boot sector with master boot record and a partition
table that tells attackers where the data is. As Mr. ING. Fruhwirth
explained it is possible to find blocks with same IV, right? Four partitions
with different setup will protect each other if attacker doesn´t know that
there are four, or more and where they start/end.
Or how about the idea to use several layers of loop-aes encryption? Using
one layer aes-256 and than one more with twofish-256 works pretty fine - you
don´t even have to know a bit about C.
Currently loop-aes uses 64 keys in multi-key mode. I guess it would be
possible to use more. As loop-aes can load and use other chiphers. Mr. ING.
Fruhwirth could write just a module with something else than CBC
implementation of aes. I guess I know why he does not.
http://clemens.endorphin.org/LinuxHDEncSettings is full of academics about
encryption but the whole site lacks installable code. So I don´t see the
problem. Loop-aes is ready and available, optimized for AMD64 and runs
stable on SuSE 8.2 - 9.2. dm-cryptoloop and it´s various "better"
implementations are in a pre-testing phase. Until aes in CMC or LRW or else
will become available to end-users I will have to use my phantasy and think
about how all traces of data can be removed to keep attackers from looking
for content.
Maybe "sniffing some more glue", Mr. ING. Fruhwirth, will give me the right
inspiration.
Regards,
Peter
--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
-
jerome etienne
> 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 ?
>
> Though I'm not an expert on the code nor have I read through all the
> previous arguments, I'd say that your '3-year old attack' is not an
> attack on the loop-AES package nor something that patching it can fix.
the paper describing the attack propose 2 simple ways to fix the
vulnerabilities. people, who care that an attacker could modify their
content without being detected, may code or poke people who code to
implement it
jerome etienne
> jerome etienne schrieb:
>
>>>>to modify the content of the encrypted device without being detected.
>>>>http://off.net/~jme/loopdev_vul.html
>
>
> are the working implementations / patches for loop-aes/cryptoloop around?
if i understand what you ask, as far as i know, nobody implemented the
fix for this attack. Jari Ruusu said it was still vulnerable so i guess
there is no patch.
if you care about this attack, a little google search pointed me to
another way to automatically secure file, encfs, which seems to protect
against this attack. it provides "per-data block MAC authentication
headers : authenticate every byte of data in a file." which is the fixed
i proposed when i published the paper.
it is pretty easy to code and may be done in a compatible way. moreover
i think it could be a nice project.
Bill Davidsen
> 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 P...@1.8GHZ:
>
> 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 <cle...@endorphin.org> http://clemens.endorphin.org
>
--
Jari Ruusu
> the paper describing the attack propose 2 simple ways to fix the
> vulnerabilities. people, who care that an attacker could modify their
> content without being detected, may code or poke people who code to
> implement it
To modify encrypted data on hard disk partition means that attacker has to
root the box first. If attacker successfully roots a box, it is "game over"
securitywise right there. Only sane option after that is reinstallation
and/or restore from known good backup.
Your paper effectively says that "compromized box is insecure" which is like
saying "water is wet".
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
-
jerome etienne
> To modify encrypted data on hard disk partition means that attacker has to
> root the box first. If attacker successfully roots a box, it is "game over"
> securitywise right there. Only sane option after that is reinstallation
> and/or restore from known good backup.
well it is a valid argument if you assume the OS has been corrupted.
Nevertheless this assumption isnt mandatory, here is a scenario where it
doesnt apply:
1. a user encrypt a whole removable disk with loop-aes
2. he goes in a conference and leave it unattended in a room (bad
practice but it happen)
3. an attacker gets it, insert chosen data in it and put it back
4. the user replugs the removable device
=> with the current loop-aes, the attack succeed
o the modification goes undetected and the user uses attacker's data
as if they were legitimate.
=> with a loop-aes patched with authentication, the attack fails
o it is detected by the authentication and the user can act
appropriatly
my point is to make people aware of the security limit offered by the
tool they use. After, they can do the knowledgeable decision to use them
or not, depending on their own requirements. Thus they dont loose/leak
important informations because they were not aware of those limits.
Jari Ruusu
> well it is a valid argument if you assume the OS has been corrupted.
> Nevertheless this assumption isnt mandatory, here is a scenario where it
> doesnt apply:
> 1. a user encrypt a whole removable disk with loop-aes
> 2. he goes in a conference and leave it unattended in a room (bad
> practice but it happen)
> 3. an attacker gets it, insert chosen data in it and put it back
> 4. the user replugs the removable device
>
> => with the current loop-aes, the attack succeed
> o the modification goes undetected and the user uses attacker's data
> as if they were legitimate.
Only if the user failed to RTFM.
loop-AES' README clearly states that it does not authenticate ciphertext,
and as such, does not protect against ciphertext tampering attacks.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
-
Boyd Waters
Agreed, loop-AES (and all other block-level-encryption methods I know about)
do not protect against this attack, and were not designed to do so.
It raises an interesting attack:
1. Disk is encrypted
2. Inserted data satisfies watermark of
(copyrighted material, top-secret plans, whatever)
3. Victim must reveal encryption keys to prove they do not
have watermarked data.
The idea here is to insert a bit of data anywhere in the encrypted area that
will cause a "hit" for someone scanning for watermarks.
If the attacker inserted a plain-text document into the partition, it would
stand out as plaintext. The attacker can insert an encrypted document, which
will look like it belongs to the victim.
Victim could reveal encryption keys, show that with those keys the
watermarked document is still ciphertext (as the victim's key is not the
same as the attacker's key. If the attacker could insert data with the
victim's key then this attack is not necessary.)
~boyd
Boyd Waters
Socorro, New Mexico
On 1/20/05 1:32 PM, "Jari Ruusu" <jari...@users.sourceforge.net> wrote:
> jerome etienne wrote:
>> well it is a valid argument if you assume the OS has been corrupted.
>> Nevertheless this assumption isnt mandatory, here is a scenario where it
>> doesnt apply:
>> 1. a user encrypt a whole removable disk with loop-aes
>> 2. he goes in a conference and leave it unattended in a room (bad
>> practice but it happen)
>> 3. an attacker gets it, insert chosen data in it and put it back
>> 4. the user replugs the removable device
>>
>> => with the current loop-aes, the attack succeed
>> o the modification goes undetected and the user uses attacker's data
>> as if they were legitimate.
>
> Only if the user failed to RTFM.
>
> loop-AES' README clearly states that it does not authenticate ciphertext,
> and as such, does not protect against ciphertext tampering attacks.
-
Pete...@gmx.de
> > Nevertheless this assumption isnt mandatory, here is a
scenario where it
> > doesnt apply:
> > 1. a user encrypt a whole removable disk with loop-aes
> > 2. he goes in a conference and leave it unattended in a room
(bad
> > practice but it happen)
> > 3. an attacker gets it, insert chosen data in it and put it
back
my drive remains at home. You can break a door and enter. You can
steal and erase my whole drive - no doubt - 100% data loss. But
please tell me what do you want to insert, and where do you want
it?
In case you intend to leave me a message behind that you broke my
door just write me an email.
Regards,
Peter
--
GMX im TV ... Die Gedanken sind frei ... Schon gesehen?
Jetzt Spot online ansehen: http://www.gmx.net/de/go/tv-spot
markus reichelt
Hash: SHA1
Fruhwirth Clemens <cle...@endorphin.org> wrote:
> On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
>
> > Fruhwirth Clemens <cle...@endorphin.org> 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-----
Christian Kujau
Hash: SHA1
jerome etienne schrieb:
>
> if i understand what you ask, as far as i know, nobody implemented the
sorry for being unclear. no, i meant "implementaion for crpto-filesystem
with authentication", eg. "loop-aes with HMAC for the whole fs".
> if you care about this attack, a little google search pointed me to
> another way to automatically secure file, encfs, which seems to protect
> against this attack. it provides "per-data block MAC authentication
encfs describes itsself as
"it works on files at a time, not an entire block device."
and i was more looking for a implemenatation of your proposed fix, working
in practice, aka "show me the code, fellow" ;-)
Christian.
- --
BOFH excuse #49:
Bogon emissions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB8GUk+A7rjkF8z0wRAvttAKCHwLyIJHUYxnfliB9cWi12Sh27HACeMJXC
25KMk9E67/nB7urc9nJVuRg=
=o5Tq
-----END PGP SIGNATURE-----
jerome etienne
>>jerome etienne wrote:
>>>3. an attacker gets it, insert chosen data in it and put it back
>
> Question: What do you insert where?
the attack is described in the paper. it is availble at
http://off.net/~jme/loopdev_vul.html
Jari Ruusu
> > > 3. an attacker gets it, insert chosen data in it and put it
> back
>
> Question: What do you insert where? My usb-stick is in my pocket,
> my drive remains at home. You can break a door and enter. You can
> steal and erase my whole drive - no doubt - 100% data loss. But
> please tell me what do you want to insert, and where do you want
> it?
If attacker knows that you installed distro X, and that distro installer
created /etc directory on your encrypted root partition at byte offset Y,
and installer placed directory entry for file /etc/hosts.deny at byte offset
offset Z, and if attacker has full physical acceess, then attacker can
overwrite encrypted data at byte offset Z with random junk. When that random
junk at byte offset Z is decrypted, the file name will decrypt to different
random junk, which is not /etc/hosts.deny . Being able to rename tcp wrapper
or firewall or some other important configuration file names does have
security impact.
If encrypted data is also authenticated, then decrypt code is able to detect
ciphertext tampering and output error message to kernel log and return I/O
error for that tampered data block. Unfortunately file systems do not deal
with I/O errors too well. ext3 file system for example appears to treat I/O
error on directory read as end-of-directory, and refuse to read any further.
So directory data tampering in authenticated case most likely results in
more files lost than just one or two files renamed.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
-
jerome etienne
> then attacker can
> overwrite encrypted data at byte offset Z with random junk. When that random
> junk at byte offset Z is decrypted, the file name will decrypt to different
> random junk, which is not /etc/hosts.deny .
good description of the attack. just a little precision, the attacker
can choose, to a certain extend, the inserted data and so the resulting
plaintext.
http://off.net/~jme/loopdev_vul.html sec 2.2
Pete...@gmx.de
> good description of the attack. just a little precision, the attacker
> can choose, to a certain extend, the inserted data and so the resulting
> plaintext.
> http://off.net/~jme/loopdev_vul.html sec 2.2
prerequesits that attacker knows a partition is encrypted and loop-aes
takes guard of a suse distro. As I said. This scenario is unlikely. You
could also blame loop-aes for not providing protection again a dd
if=/dev/zero of=/dev/hda bs=64 .........
But you are creative!
How about following:
A small device that is to be plugged between harddrive and mainboard and
monitors first 1GB of data when PC is started. All data I/O is recorded to
a memory chip. Later attacker should be able to boot the pc by a playback
of this first 1GB.
Or how about pieces of hardware that fit into a keyboard and send all
keystrokes via radiofrequency? I´d say software will never be able to
secure a compromised machine.
So your attack is rather an idea than a danger.
Regards
Peter
--
10 GB Mailbox, 100 FreeSMS http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
-