[dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Henrik Theiling]

Hi!

While trying to make a decision of how to encrypt a large disk, I
found no good answer yet.  What I am searching for is a site that
gives me a simple overview of pros and cons of the different choices
to be made when selecting LUKS algorithms.  Yet, I found nothing like
that.

In this particular case: for a 1,5 TB partition, should I use
cbc-essiv or xts-plain?

It seems cbc-essiv is susceptible to watermarking (according to
Wikipedia, which claims that no IV obfuscation algorithm protects
against this except in the initial block.  Unfortunately, I cannot
verify this, so it sounds bad to me.

And then, xts-plain is said to become weaker on large disks, and some
crypto implementations warn about this weakness for disks as small as
500GB.  So what's the alternative?  (If I understand correctly, LUKS
has no multi-key XTS option for large disks, right (in case that would
overcome the problem)?)

I don't seem to be able to make a decision on my own, so I'd like to
ask for help.  Which problem is worse?  Or are there ways to overcome
both problems?  I could probably split the disk and re-assemble the
xts-plain encrypted parts in a RAID, but that seems very complex.
There don't need to be simple answers -- I am willing to evaluate my
problem thoroughly, but so far I found no good comparison.

Bye,
  Henrik

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

On 03.08.2009, Henrik Theiling wrote: 

> In this particular case: for a 1,5 TB partition, should I use
> cbc-essiv or xts-plain?

Encryption is only one piece in the security chain. You didn't even
tell us _why_ you want to have your data encrypted.

> It seems cbc-essiv is susceptible to watermarking (according to
> Wikipedia, which claims that no IV obfuscation algorithm protects
> against this except in the initial block.  Unfortunately, I cannot
> verify this, so it sounds bad to me.

ESSIV has been develop to address this problem and is not prone to
watermarking. The developer of ESSIV is here on the list, and maybe 
you're lucky and he will explain this a little bit closer to you.

> And then, xts-plain is said to become weaker on large disks, and some
> crypto implementations warn about this weakness for disks as small as
> 500GB.  So what's the alternative?

So they who has raised these claims you described above didn't provide an
explanation for their statements? 

> I don't seem to be able to make a decision on my own, so I'd like to
> ask for help.

We shall decide for you? That's generally a bad idea. There's only one
person with the whole knowledge, and that's you. I don't know why you want
to have your harddisk encrypted, what kind of data you have, how important
they are for yourself and others, how the potentially encrypted harddisk
is secured else, and so on and so on...

> There don't need to be simple answers -- I am willing to evaluate my
> problem thoroughly, but so far I found no good comparison.

You can take a look at dm-crypt.c to find out what methods of IV generation
are supported by LUKS/dmcrypt.

Don't know if this helps, I encrypted my Laptop (which carries a lot of
private data, e.g. the password to my online bank account) using

 -c twofish-cbc-essiv:sha256 

in case it gets lost or stolen, to prevent the thieves from getting access
to my money. I decided to use just this algorithm because I did some benchmarking
and it performed best (the major drag on a Laptop is the slow harddisk). 

A lot of distributions also use "-c aes-xts-benbi:sha256".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Henrik Theiling]

Hi!

Thank you for you interesting reply!

Heinz Diehl writes:
>> It seems cbc-essiv is susceptible to watermarking (according to
>> Wikipedia, which claims that no IV obfuscation algorithm protects
>> against this except in the initial block.  Unfortunately, I cannot
>> verify this, so it sounds bad to me.
>
> ESSIV has been develop to address this problem and is not prone to
> watermarking. The developer of ESSIV is here on the list, and maybe
> you're lucky and he will explain this a little bit closer to you.

Yes, I know he is on this list.  And I know it was invented for that
purpose.  But still, Wikipedia claims:

> To protect against the watermarking attack, a stream cipher is often
> used to generate the IVs from the key, so that an adversary cannot
> predict them. In particular, the ESSIV approach discussed below uses
> a block cipher in CTR mode to generate the IVs. Another option would
> supplement this IV with a hash function applied to every block but
> the first. However, neither of these options guards against the
> decryption attack above.
Q: http://en.wikipedia.org/wiki/Disk_encryption_theory

Quite obviously not all is true that's written out there, but there we
are: I just do not know. If any trustworthy person told me that the
above is rubbish, it would be fine with me.

>> And then, xts-plain is said to become weaker on large disks, and some
>> crypto implementations warn about this weakness for disks as small as
>> 500GB.  So what's the alternative?
>
> So they who has raised these claims you described above didn't provide an
> explanation for their statements?

IIRC, the weakness itself was discussed on this list a few months ago.
Here's another source:

> According to the IETF NIST submission[0] for the tweakable block
> cipher xts (and I paraphrase here, as the document prohibits direct
> quotation): the proof yields strong security guarantees as long as
> the same key is not used to encrypt much more than 1 terabyte of
> data. Up until this point, no attack can succeed with probability
> better than approximately one in eight quadrillion. However this
> security guarantee deteriorates as more data is encrypted with the
> same key. With a petabyte the attack success probability rate
> decreases to *at most* eight in a trillion, with an exabyte, the
> success probability is reduced to *at most* eight in a million.
Q: http://tinyurl.com/np9wum

I'd like to use an algorithm without such a weakness.

>> I don't seem to be able to make a decision on my own, so I'd like to
>> ask for help.
>
> We shall decide for you?

No, of course not!  I'd be very happy with pointers to more
information so I can judge myself which problems are bad for me and
how I can avoid them.

> That's generally a bad idea. There's only one person with the whole
> knowledge, and that's you.

I'd love that to be true!  But I do not have all knowledge concerning
the likelihoods of the attacks, and also lack knowledge about how to
avoid the weaknesses.

> I don't know why you want to have your harddisk encrypted, ...
> what kind of data you have, how important they are for yourself and
> others, how the potentially encrypted harddisk is secured else, and
> so on and so on...

There is no immediate threat or strict confidentiality involved, but
I'd like to keep all my data private, e.g. in case it is stolen, and
because it's easily done.  Plus very secure erasure of encrypted hard
disks is very quick by overwriting the keys (in case I don't want to
use them anymore).  Further, if a disk is broken, I can send it in
without companies being able to read plain text.

But I'd like to avoid mistakes of using a weak encryption algorithm,
so I would like to understand what are the pros and cons for cbc-essiv
or xts-plain or any other alternative.

> You can take a look at dm-crypt.c to find out what methods of IV
> generation are supported by LUKS/dmcrypt.

Encryption algorithms are very complex beasts, and I do not think from
reading source code I could see any subtle weaknesses myself.

>  -c twofish-cbc-essiv:sha256
>
> in case it gets lost or stolen, to prevent the thieves from getting
> access to my money. I decided to use just this algorithm because I
> did some benchmarking and it performed best (the major drag on a
> Laptop is the slow harddisk).

So you decided by speed alone?  Because you think any option is strong
enough security for you?  Speed is not really an issue for me -- any
simple option is very propably fast enough for me (except maybe
multi-layered encryption, which would seem like overkill to me).

I read a lot of manuals, all using one or another particular setting
for -c, but without explaining why exactly that one was chosen for the
examples.  Is feels arbitrary.  E.g. I used aes-cbc-essiv:sha256
before, because I found this recommendation in a manuals.  But now I
have larger disks and, of course, there are new algorithms and more
understanding of old ones, so now the recommendation might not be
valid anymore (it was without explanation in the first place).

> A lot of distributions also use "-c aes-xts-benbi:sha256".

And why do they do so?

**Henrik

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

On 03.08.2009, Henrik Theiling wrote: 

> Yes, I know he is on this list.  And I know it was invented for that
> purpose.  But still, Wikipedia claims:
[....]

So we'll never know unless someone with enough expertise can tell us the
truth.

> > the proof yields strong security guarantees as long as
> > the same key is not used to encrypt much more than 1 terabyte of
> > data. Up until this point, no attack can succeed with probability
> > better than approximately one in eight quadrillion. However this
> > security guarantee deteriorates as more data is encrypted with the
> > same key. With a petabyte the attack success probability rate
> > decreases to *at most* eight in a trillion, with an exabyte, the
> > success probability is reduced to *at most* eight in a million.

> I'd like to use an algorithm without such a weakness.

The weakness is not related to the algorithm itself, but to the IV generator.
I would maybe have used xts in this case and had the harddisk divided in three
partitions with 500GB, using a different key for all of them.

> There is no immediate threat or strict confidentiality involved, but
> I'd like to keep all my data private, e.g. in case it is stolen, and
> because it's easily done.  Plus very secure erasure of encrypted hard
> disks is very quick by overwriting the keys (in case I don't want to
> use them anymore).  Further, if a disk is broken, I can send it in
> without companies being able to read plain text.

Ok, if your data are not likely to get stolen by one of the organisations
with the three huge letters, I would say that it makes no difference what
algorithm or method you are using. I would have choosen the one which
provides the highest speed. I think that 99.9999999% of all people in the
world are not able to do a successful attack on one of the supported
algorithms and operation modes. So it does not matter if you are using it
for wiping a harddisk, storing your data securely or have to send in a
broken harddisk to the servicefolks.

The main weaknesses are often related to a bad passphrase or different
circumstances which makes it easy for an adversary to get it, e.g.
writing down the passphrase or choosing not enough entropy.

> But I'd like to avoid mistakes of using a weak encryption algorithm,
> so I would like to understand what are the pros and cons for cbc-essiv
> or xts-plain or any other alternative.

To know that for shure, this is up to the people who have written this
beautiful piece of software, who have designed the methods/algorithms
by themselves or ones who are able to fully understand the sourcecode.

> > You can take a look at dm-crypt.c to find out what methods of IV
> > generation are supported by LUKS/dmcrypt.
 
> Encryption algorithms are very complex beasts, and I do not think from
> reading source code I could see any subtle weaknesses myself.

That was not my intention, they are all listed in this file, and you can
see what you will have to choose from.

> So you decided by speed alone?  Because you think any option is strong
> enough security for you? 

Yes.

> Speed is not really an issue for me -- any
> simple option is very propably fast enough for me (except maybe
> multi-layered encryption, which would seem like overkill to me).

Multi-layered encryption is just stupid. See Kerckhoff's principle:
http://en.wikipedia.org/wiki/Kerckhoffs%27_principle

With regards to my little knowledge, the algorithm which is most secure per today is serpent,
I probably would have choosen "-c serpent-xts-benbi:sha256 -s 512" and had
the harddisk gotten divided into three partitions of 500GB. This results in
Serpent-256 encryption (256 bits go to XTS).

> > A lot of distributions also use "-c aes-xts-benbi:sha256".
 
> And why do they do so?

That's the question :-)
I simply don't know. We can only guess. There's so much disinformation and
uncertainty out there. I don't know.

PGP WDE e.g. uses (hardcoded) AES-256 in EME mode, and the key is derived
via the STR2KEY function. But _why_ they use it (maybe they think or know
this is the securest possibility?!), I don't know either.

Sorry I can't help you out.

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

On 03.08.2009, Heinz Diehl wrote: 

> The weakness is not related to the algorithm itself, but to the IV generator.

s/IV generator/mode of operation

Sorry!

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Peter Pfundstein]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

Dear Henrik Theiling,

hope I address this email properly.

Just read a message from you in a portal about the " use cbc-essiv or xts-plain" from Aug 3, 2009.
You gave some explanation about the differences.

I just want to express my thanks for this very in-depth explanation that you made public available for others to learn.
Of course Google helped finding it. The explanation is excellent and understandable also for people not permanently involved in the matter.

Thanks a lot for sharing this knowledge and best regards from Germany !

Peter Pfundstein

-- 
Peter Pfundstein * Jordanstr. 6 * 35764 Sinn

---xxx---


[-- Attachment #2: Type: text/html, Size: 849 bytes --]

Re: [dm-crypt] E3E-2A1 - 1, 5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

My mail to the list has been rejected by the spamfilter with
the message "invalid recipient". What's wrong??


On 03.08.2009, Henrik Theiling wrote: 

> In this particular case: for a 1,5 TB partition, should I use
> cbc-essiv or xts-plain?

Encryption is only one piece in the security chain. You didn't even
tell us _why_ you want to have your data encrypted.

> It seems cbc-essiv is susceptible to watermarking (according to
> Wikipedia, which claims that no IV obfuscation algorithm protects
> against this except in the initial block.  Unfortunately, I cannot
> verify this, so it sounds bad to me.

ESSIV has been develop to address this problem and is not prone to
watermarking. The developer of ESSIV is here on the list, and maybe 
you're lucky and he will explain this a little bit closer to you.

> And then, xts-plain is said to become weaker on large disks, and some
> crypto implementations warn about this weakness for disks as small as
> 500GB.  So what's the alternative?

So they who has raised these claims you described above didn't provide an
explanation for their statements? 

> I don't seem to be able to make a decision on my own, so I'd like to
> ask for help.

We shall decide for you? That's generally a bad idea. There's only one
person with the whole knowledge, and that's you. I don't know why you want
to have your harddisk encrypted, what kind of data you have, how important
they are for yourself and others, how the potentially encrypted harddisk
is secured else, and so on and so on...

> There don't need to be simple answers -- I am willing to evaluate my
> problem thoroughly, but so far I found no good comparison.

You can take a look at dm-crypt.c to find out what methods of IV generation
are supported by LUKS/dmcrypt.

Don't know if this helps, I encrypted my Laptop (which carries a lot of
private data, e.g. the password to my online bank account) using

 -c twofish-cbc-essiv:sha256 

in case it gets lost or stolen, to prevent the thieves from getting access
to my money. I decided to use just this algorithm because I did some benchmarking
and it performed best (the major drag on a Laptop is the slow harddisk). 

A lot of distributions also use "-c aes-xts-benbi:sha256".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Moji]

Here is the report that NIST released comparing, MARS, RC6, Twofish, Serpent, and Rijndael(AES), skip to page 88 for the summary: http://csrc.nist.gov/archive/aes/round2/r2report.pdf

Benbi is a big-endian, narrow block algorithm using 64-bit, plain uses 32-bit. Here is a paper by NIST citing that XTS is not suitable for information in chunks larger than 1TB per key: http://csrc.nist.gov/groups/ST/.../XTS/revised_XTS_comments-Seagate.pdf

I am sorry but I do not have any additional information that was not already cited about ESSIV to add here.

As for devices larger than 1TB, when ever this is brought up and discussed the only solution I have ever seen is using multiple keys to break up larger devices into smaller chunks to avoid weaknesses. Then use RAID/LVM to bring them back together or change your disk management practices to split up your data.
This includes newer ciphers because the more data you encrypt with a single key, and right now dm-crypt only allows for single keys, the more susceptible your algorithm is regardless which one you use.

I hope this helps you,

-MJ

On Mon,  3 Aug 2009 14:53:42 +0200 (CEST)
theiling@absint.com (Henrik Theiling) wrote:

> Hi!
> 
> While trying to make a decision of how to encrypt a large disk, I
> found no good answer yet.  What I am searching for is a site that
> gives me a simple overview of pros and cons of the different choices
> to be made when selecting LUKS algorithms.  Yet, I found nothing like
> that.
> 
> In this particular case: for a 1,5 TB partition, should I use
> cbc-essiv or xts-plain?
> 
> It seems cbc-essiv is susceptible to watermarking (according to
> Wikipedia, which claims that no IV obfuscation algorithm protects
> against this except in the initial block.  Unfortunately, I cannot
> verify this, so it sounds bad to me.
> 
> And then, xts-plain is said to become weaker on large disks, and some
> crypto implementations warn about this weakness for disks as small as
> 500GB.  So what's the alternative?  (If I understand correctly, LUKS
> has no multi-key XTS option for large disks, right (in case that would
> overcome the problem)?)
> 
> I don't seem to be able to make a decision on my own, so I'd like to
> ask for help.  Which problem is worse?  Or are there ways to overcome
> both problems?  I could probably split the disk and re-assemble the
> xts-plain encrypted parts in a RAID, but that seems very complex.
> There don't need to be simple answers -- I am willing to evaluate my
> problem thoroughly, but so far I found no good comparison.
> 
> Bye,
>   Henrik
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Milan Broz]

Moji wrote:

> This includes newer ciphers because the more data you encrypt with a single key,
> and right now dm-crypt only allows for single keys, the more susceptible your algorithm
> is regardless which one you use.

Just small note: dm-crypt (kernel part) have one key per mapped segment,
you can create as many segments with different keys (even with different algorithms)
(imagine simple Logical Volume in LVM split over several areas of disk -
the same logic can be used for crypt segments.)

Another option is stacking - create several encrypted devices and and
map another volume(s) over it (LVM over LUKS is exactly that).

Only userspace (cryptsetup) is not able to configure it easily - you have to use
dmsetup directly (or stack LVM/MD over several LUKS devices).

Milan
--
mbroz@redhat.com

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Henrik Theiling]

Hi!

Moji writes a lot in interesting stuff and finally:
>...
> I hope this helps you,

This helped a lot, yes, thank you!


And Milan wrote:
> Just small note: dm-crypt (kernel part) have one key per mapped
> segment, you can create as many segments with different keys (even
> with different algorithms) (imagine simple Logical Volume in LVM
> split over several areas of disk - the same logic can be used for
> crypt segments.)

Interesting!

> Only userspace (cryptsetup) is not able to configure it easily - you have to use
> dmsetup directly (or stack LVM/MD over several LUKS devices).

:-(  But at least it's possible, I did not know that.


And Heinz wrote:
> The main weaknesses are often related to a bad passphrase or different
> circumstances which makes it easy for an adversary to get it, e.g.
> writing down the passphrase or choosing not enough entropy.

Right.  I try to remember extremely long passphrases (people tend to
have strange looks on their faces when I type a hard disk passphrase),
but of course, I'm no computer. :-)

**Henrik

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Moji]

I am so sorry, I hit send before I had finished writing, I was delayed trying to find an article that I thought would help you with more explanation but I could not remember where I read it.

Finally I did locate it, it should provide some information on ESSIV for you: http://clemens.endorphin.org/LinuxHDEncSettings

Also, based on the information I have posted, and assuming that you will not be using raid to break up the device, I would recommend:

serpent-cbc-essiv:sha256

serpent because it is very strong cipher, even though it has not as much testing as AES, and cbc-essiv, because I have not seen any reports of inherent vulnerabilities on larger devices.

-MJ

On Mon,  3 Aug 2009 14:53:42 +0200 (CEST)
theiling@absint.com (Henrik Theiling) wrote:

> Hi!
> 
> While trying to make a decision of how to encrypt a large disk, I
> found no good answer yet.  What I am searching for is a site that
> gives me a simple overview of pros and cons of the different choices
> to be made when selecting LUKS algorithms.  Yet, I found nothing like
> that.
> 
> In this particular case: for a 1,5 TB partition, should I use
> cbc-essiv or xts-plain?
> 
> It seems cbc-essiv is susceptible to watermarking (according to
> Wikipedia, which claims that no IV obfuscation algorithm protects
> against this except in the initial block.  Unfortunately, I cannot
> verify this, so it sounds bad to me.
> 
> And then, xts-plain is said to become weaker on large disks, and some
> crypto implementations warn about this weakness for disks as small as
> 500GB.  So what's the alternative?  (If I understand correctly, LUKS
> has no multi-key XTS option for large disks, right (in case that would
> overcome the problem)?)
> 
> I don't seem to be able to make a decision on my own, so I'd like to
> ask for help.  Which problem is worse?  Or are there ways to overcome
> both problems?  I could probably split the disk and re-assemble the
> xts-plain encrypted parts in a RAID, but that seems very complex.
> There don't need to be simple answers -- I am willing to evaluate my
> problem thoroughly, but so far I found no good comparison.
> 
> Bye,
>   Henrik
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Henrik Theiling]

Hi!

Moji writes:
>...
> Also, based on the information I have posted, and assuming that you
> will not be using raid to break up the device, I would recommend:
>
> serpent-cbc-essiv:sha256
>
> serpent because it is very strong cipher, even though it has not as
> much testing as AES, and cbc-essiv, because I have not seen any
> reports of inherent vulnerabilities on larger devices.

Thanks for the recommendation and the explaining!

From what I understand, the Wikipedia lists a decryption attack
against any form of CBC regardless of the IV method.  It always works
because of the simple chaining using the previous cypher text: for
decrypting any but the first block of a sector, you do not need the
IV, but the only thing you need is the previous encrypted block, which
you naturally have.  So if you can ask for decryption of a single
sector on the device, you can decrypt all but the first block of any
other sector of the device, too, by simply copying the desired block
to the block you can decrypt.

However, I think if anyone can decrypt a single sector of my harddisk,
they can decrypt any sector anyway, so this seems like no problem to
me.

From the wording of the Wikipedia article, however, it is not
completely clear to me how serious the watermarking attack on CBC is.
The IV function is known, so can two blocks be easily constructed in
such a way that their cbc-essiv:sha256 encryption (with whatever main
algorithm) is identical?  You'd need to know the sector for that plus
break SHA256, because ESSIV uses the hash of the encryption key plus
the sector number to generate the IV, right?  If I understood that
correctly, then I can safely get back to relaxing, enjoying the summer
and drinking beer instead of thinking about this any longer.

**Henrik

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Moji]

On Tue, 04 Aug 2009 15:27:20 +0200
Henrik Theiling <theiling@absint.com> wrote:

> >From the wording of the Wikipedia article, however, it is not  
> completely clear to me how serious the watermarking attack on CBC is.
> The IV function is known, so can two blocks be easily constructed in
> such a way that their cbc-essiv:sha256 encryption (with whatever main
> algorithm) is identical?  You'd need to know the sector for that plus
> break SHA256, because ESSIV uses the hash of the encryption key plus
> the sector number to generate the IV, right?  If I understood that
> correctly, then I can safely get back to relaxing, enjoying the summer
> and drinking beer instead of thinking about this any longer.

From Clemens Fruhwirth:
"ESSIV
E(Sector|Salt) IV, short ESSIV, derives the IV from key material via encryption of the sector number with a hashed version of the key material, the salt. ESSIV does not specify a particular hash algorithm, but the digest size of the hash must be an accepted key size for the block cipher in use. As the IV depends on a none public piece of information, the key, the sequence of IV is not known, and the attacks based on this can't be launched."

This covers watermarks, I hope this provides for drinking much beer.

-MJ

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Mon, Aug 3, 2009 at 18:46, Moji<lordmoji@gmail.com> wrote:
> I am so sorry, I hit send before I had finished writing, I was delayed trying to find an article that I thought would help you with more explanation but I could not remember where I read it.
>
> Finally I did locate it, it should provide some information on ESSIV for you: http://clemens.endorphin.org/LinuxHDEncSettings
>
> Also, based on the information I have posted, and assuming that you will not be using raid to break up the device, I would recommend:
>
> serpent-cbc-essiv:sha256
I really liked this one, using aes-cbs-essiv:sha256 [keysize=256] i
was able to get only 0.89MB/s reading via NFS from my ARM 266Mhz.
Using serpent-cbc-essiv:sha256[keysize=256] i can get 2,66MB/s, which
is really good.
>
> serpent because it is very strong cipher, even though it has not as much testing as AES, and cbc-essiv, because I have not seen any reports of inherent vulnerabilities on larger devices.
>
> -MJ
>
> On Mon,  3 Aug 2009 14:53:42 +0200 (CEST)
> theiling@absint.com (Henrik Theiling) wrote:
>
>> Hi!
>>
>> While trying to make a decision of how to encrypt a large disk, I
>> found no good answer yet.  What I am searching for is a site that
>> gives me a simple overview of pros and cons of the different choices
>> to be made when selecting LUKS algorithms.  Yet, I found nothing like
>> that.
>>
>> In this particular case: for a 1,5 TB partition, should I use
>> cbc-essiv or xts-plain?
>>
>> It seems cbc-essiv is susceptible to watermarking (according to
>> Wikipedia, which claims that no IV obfuscation algorithm protects
>> against this except in the initial block.  Unfortunately, I cannot
>> verify this, so it sounds bad to me.
>>
>> And then, xts-plain is said to become weaker on large disks, and some
>> crypto implementations warn about this weakness for disks as small as
>> 500GB.  So what's the alternative?  (If I understand correctly, LUKS
>> has no multi-key XTS option for large disks, right (in case that would
>> overcome the problem)?)
>>
>> I don't seem to be able to make a decision on my own, so I'd like to
>> ask for help.  Which problem is worse?  Or are there ways to overcome
>> both problems?  I could probably split the disk and re-assemble the
>> xts-plain encrypted parts in a RAID, but that seems very complex.
>> There don't need to be simple answers -- I am willing to evaluate my
>> problem thoroughly, but so far I found no good comparison.
>>
>> Bye,
>>   Henrik
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Henrik Theiling]

Hi!

Salatiel Filho writes:
>>....
>> serpent-cbc-essiv:sha256
> I really liked this one, using aes-cbs-essiv:sha256 [keysize=256] i
> was able to get only 0.89MB/s reading via NFS from my ARM 266Mhz.
> Using serpent-cbc-essiv:sha256[keysize=256] i can get 2,66MB/s,
> which is really good.

Fascinating.  I thought Serpent was universally the slowest of the
three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
you wanted highest security margins.  Your speed test results come
quite unexpected for me, especially since AES and Twofish have
assembler modules while Serpent has only a C implementation in the
kernel (as of last time I checked).

For me, speed is quite secondary, because I have a fast machine which
crypts much faster than the USB-2.0 interface can possibly serve the
data.

**Henrik

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

On 06.08.2009, Henrik Theiling wrote: 

> Fascinating.  I thought Serpent was universally the slowest of the
> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
> you wanted highest security margins.  Your speed test results come
> quite unexpected for me...

The question is: how has this been measured, and is it faster on both read
and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.

How about a bonnie++ run, e.g. something like
"bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Thu, Aug 6, 2009 at 12:24, Heinz Diehl<htd@fancy-poultry.org> wrote:
> On 06.08.2009, Henrik Theiling wrote:
>
>> Fascinating.  I thought Serpent was universally the slowest of the
>> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
>> you wanted highest security margins.  Your speed test results come
>> quite unexpected for me...
>
> The question is: how has this been measured, and is it faster on both read
> and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.
>
I just encrypted the partition , put some random data there [i do not
care about write speed in this particular storage, it is just a NAS
(ARM 266 + 128RAM running debian lenny)], then drop_caches , export
the data using nfs, mount from another machine and copy that file.
Repeated the proccess using aes and using serpent. Serpent is much faster ...
I really don't know which cipher is/shouldbe faster, but serpent gives
me a great speed ...

> How about a bonnie++ run, e.g. something like
> "bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Thu, Aug 6, 2009 at 13:00, Salatiel Filho<salatiel.filho@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 12:24, Heinz Diehl<htd@fancy-poultry.org> wrote:
>> On 06.08.2009, Henrik Theiling wrote:
>>
>>> Fascinating.  I thought Serpent was universally the slowest of the
>>> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
>>> you wanted highest security margins.  Your speed test results come
>>> quite unexpected for me...
>>
>> The question is: how has this been measured, and is it faster on both read
>> and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.
>>
> I just encrypted the partition , put some random data there [i do not
> care about write speed in this particular storage, it is just a NAS
> (ARM 266 + 128RAM running debian lenny)], then drop_caches , export
> the data using nfs, mount from another machine and copy that file.
> Repeated the proccess using aes and using serpent. Serpent is much faster ...
> I really don't know which cipher is/shouldbe faster, but serpent gives
> me a great speed ...
>
>> How about a bonnie++ run, e.g. something like
>> "bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"
i will try to do this tonight.

>>
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>
>
>
> --
> []'s
> Salatiel
>
> "O maior prazer do inteligente é bancar o  idiota
>   diante de um  idiota que banca o inteligente".
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Thu, Aug 6, 2009 at 13:02, Salatiel Filho<salatiel.filho@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 13:00, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>> On Thu, Aug 6, 2009 at 12:24, Heinz Diehl<htd@fancy-poultry.org> wrote:
>>> On 06.08.2009, Henrik Theiling wrote:
>>>
>>>> Fascinating.  I thought Serpent was universally the slowest of the
>>>> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
>>>> you wanted highest security margins.  Your speed test results come
>>>> quite unexpected for me...
>>>
>>> The question is: how has this been measured, and is it faster on both read
>>> and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.
>>>
>> I just encrypted the partition , put some random data there [i do not
>> care about write speed in this particular storage, it is just a NAS
>> (ARM 266 + 128RAM running debian lenny)], then drop_caches , export
>> the data using nfs, mount from another machine and copy that file.
>> Repeated the proccess using aes and using serpent. Serpent is much faster ...
>> I really don't know which cipher is/shouldbe faster, but serpent gives
>> me a great speed ...
>>
>>> How about a bonnie++ run, e.g. something like
>>> "bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"
> i will try to do this tonight.
>


I changed the bonnie parameters cause this machine is really slow and
it has only 128Mb RAM. Here are the results, which i'd be glad if
someone could explain then to me :)

# bonnie++ -d /mnt -f -n0 -m serpent -s 250
[ext4,cipher=serpent-cbc-essiv:sha256,size=256]
Using uid:1000, gid:1000.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Version 1.03d       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
serpent        250M            1607   5   910   3            2403   3
126.8   3
serpent,250M,,,1607,5,910,3,,,2403,3,126.8,3,,,,,,,,,,,,,



# bonnie++ -d /mnt -f -n0 -m aes -s 250
[ext4,cipher=aes-cbc-essiv:sha256,size=256]

Using uid:1000, gid:1000.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Version 1.03d       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
aes            256M             623   2   400   1            1319   1
116.2   3
aes,256M,,,623,2,400,1,,,1319,1,116.2,3,,,,,,,,,,,,,















>>>
>>>
>>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>
>>
>>
>> --
>> []'s
>> Salatiel
>>
>> "O maior prazer do inteligente é bancar o  idiota
>>   diante de um  idiota que banca o inteligente".
>>
>
>
>
> --
> []'s
> Salatiel
>
> "O maior prazer do inteligente é bancar o  idiota
>   diante de um  idiota que banca o inteligente".
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Fri, Aug 7, 2009 at 09:16, Salatiel Filho<salatiel.filho@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 13:02, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>> On Thu, Aug 6, 2009 at 13:00, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>>> On Thu, Aug 6, 2009 at 12:24, Heinz Diehl<htd@fancy-poultry.org> wrote:
>>>> On 06.08.2009, Henrik Theiling wrote:
>>>>
>>>>> Fascinating.  I thought Serpent was universally the slowest of the
>>>>> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
>>>>> you wanted highest security margins.  Your speed test results come
>>>>> quite unexpected for me...
>>>>
>>>> The question is: how has this been measured, and is it faster on both read
>>>> and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.
>>>>
>>> I just encrypted the partition , put some random data there [i do not
>>> care about write speed in this particular storage, it is just a NAS
>>> (ARM 266 + 128RAM running debian lenny)], then drop_caches , export
>>> the data using nfs, mount from another machine and copy that file.
>>> Repeated the proccess using aes and using serpent. Serpent is much faster ...
>>> I really don't know which cipher is/shouldbe faster, but serpent gives
>>> me a great speed ...
>>>
>>>> How about a bonnie++ run, e.g. something like
>>>> "bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"
>> i will try to do this tonight.
>>
>
>
> I changed the bonnie parameters cause this machine is really slow and
> it has only 128Mb RAM. Here are the results, which i'd be glad if
> someone could explain then to me :)
>
> # bonnie++ -d /mnt -f -n0 -m serpent -s 250
> [ext4,cipher=serpent-cbc-essiv:sha256,size=256]
> Using uid:1000, gid:1000.
> Writing intelligently...done
> Rewriting...done
> Reading intelligently...done
> start 'em...done...done...done...
> Version 1.03d       ------Sequential Output------ --Sequential Input-
> --Random-
>                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> /sec %CP
> serpent        250M            1607   5   910   3            2403   3
> 126.8   3
> serpent,250M,,,1607,5,910,3,,,2403,3,126.8,3,,,,,,,,,,,,,
>
>
>
> # bonnie++ -d /mnt -f -n0 -m aes -s 250
> [ext4,cipher=aes-cbc-essiv:sha256,size=256]
>
> Using uid:1000, gid:1000.
> Writing intelligently...done
> Rewriting...done
> Reading intelligently...done
> start 'em...done...done...done...
> Version 1.03d       ------Sequential Output------ --Sequential Input-
> --Random-
>                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
> --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
> /sec %CP
> aes            256M             623   2   400   1            1319   1
> 116.2   3
> aes,256M,,,623,2,400,1,,,1319,1,116.2,3,,,,,,,,,,,,,
>
>
>
>
I am going to redo the test , apparently i used 250M for serpent and
256M for aes ...
repost results soon.

>
>
>
>
>
>
>
>
>
>
>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dm-crypt mailing list
>>>> dm-crypt@saout.de
>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>
>>>
>>>
>>>
>>> --
>>> []'s
>>> Salatiel
>>>
>>> "O maior prazer do inteligente é bancar o  idiota
>>>   diante de um  idiota que banca o inteligente".
>>>
>>
>>
>>
>> --
>> []'s
>> Salatiel
>>
>> "O maior prazer do inteligente é bancar o  idiota
>>   diante de um  idiota que banca o inteligente".
>>
>
>
>
> --
> []'s
> Salatiel
>
> "O maior prazer do inteligente é bancar o  idiota
>   diante de um  idiota que banca o inteligente".
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Fri, Aug 7, 2009 at 09:20, Salatiel Filho<salatiel.filho@gmail.com> wrote:
> On Fri, Aug 7, 2009 at 09:16, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>> On Thu, Aug 6, 2009 at 13:02, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>>> On Thu, Aug 6, 2009 at 13:00, Salatiel Filho<salatiel.filho@gmail.com> wrote:
>>>> On Thu, Aug 6, 2009 at 12:24, Heinz Diehl<htd@fancy-poultry.org> wrote:
>>>>> On 06.08.2009, Henrik Theiling wrote:
>>>>>
>>>>>> Fascinating.  I thought Serpent was universally the slowest of the
>>>>>> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
>>>>>> you wanted highest security margins.  Your speed test results come
>>>>>> quite unexpected for me...
>>>>>
>>>>> The question is: how has this been measured, and is it faster on both read
>>>>> and write operations? E.g. a simple "hdparm -tT /dev/xxx" is not sufficient.
>>>>>
>>>> I just encrypted the partition , put some random data there [i do not
>>>> care about write speed in this particular storage, it is just a NAS
>>>> (ARM 266 + 128RAM running debian lenny)], then drop_caches , export
>>>> the data using nfs, mount from another machine and copy that file.
>>>> Repeated the proccess using aes and using serpent. Serpent is much faster ...
>>>> I really don't know which cipher is/shouldbe faster, but serpent gives
>>>> me a great speed ...
>>>>
>>>>> How about a bonnie++ run, e.g. something like
>>>>> "bonnie++ -u htd:users -d /mnt/test -s 16016m -m liesel -n 16:100000:16:6"
>>> i will try to do this tonight.
>>>
>>
>>
>> I changed the bonnie parameters cause this machine is really slow and
>> it has only 128Mb RAM. Here are the results, which i'd be glad if
>> someone could explain then to me :)
>>
>> # bonnie++ -d /mnt -f -n0 -m serpent -s 250
>> [ext4,cipher=serpent-cbc-essiv:sha256,size=256]
>> Using uid:1000, gid:1000.
>> Writing intelligently...done
>> Rewriting...done
>> Reading intelligently...done
>> start 'em...done...done...done...
>> Version 1.03d       ------Sequential Output------ --Sequential Input-
>> --Random-
>>                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
>> --Seeks--
>> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
>> /sec %CP
>> serpent        250M            1607   5   910   3            2403   3
>> 126.8   3
>> serpent,250M,,,1607,5,910,3,,,2403,3,126.8,3,,,,,,,,,,,,,
>>
>>
>>
>> # bonnie++ -d /mnt -f -n0 -m aes -s 250
>> [ext4,cipher=aes-cbc-essiv:sha256,size=256]
>>
>> Using uid:1000, gid:1000.
>> Writing intelligently...done
>> Rewriting...done
>> Reading intelligently...done
>> start 'em...done...done...done...
>> Version 1.03d       ------Sequential Output------ --Sequential Input-
>> --Random-
>>                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
>> --Seeks--
>> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
>> /sec %CP
>> aes            256M             623   2   400   1            1319   1
>> 116.2   3
>> aes,256M,,,623,2,400,1,,,1319,1,116.2,3,,,,,,,,,,,,,
>>
>>
>>
>>
> I am going to redo the test , apparently i used 250M for serpent and
> 256M for aes ...
> repost results soon.
>
>>
>>
Here :



Version 1.03d       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
serpent        256M            2050   7  1209   3            2959   4
138.8   3
serpent,256M,,,2050,7,1209,3,,,2959,4,138.8,3,,,,,,,,,,,,,


Version 1.03d       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
aes            256M             625   2   445   1            1455   2
113.5   3
aes,256M,,,625,2,445,1,,,1455,2,113.5,3,,,,,,,,,,,,,




>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dm-crypt mailing list
>>>>> dm-crypt@saout.de
>>>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> []'s
>>>> Salatiel
>>>>
>>>> "O maior prazer do inteligente é bancar o  idiota
>>>>   diante de um  idiota que banca o inteligente".
>>>>
>>>
>>>
>>>
>>> --
>>> []'s
>>> Salatiel
>>>
>>> "O maior prazer do inteligente é bancar o  idiota
>>>   diante de um  idiota que banca o inteligente".
>>>
>>
>>
>>
>> --
>> []'s
>> Salatiel
>>
>> "O maior prazer do inteligente é bancar o  idiota
>>   diante de um  idiota que banca o inteligente".
>>
>
>
>
> --
> []'s
> Salatiel
>
> "O maior prazer do inteligente é bancar o  idiota
>   diante de um  idiota que banca o inteligente".
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Heinz Diehl]

On 08.08.2009, Salatiel Filho wrote: 

Serpent:

>  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP  
>       2050   7  1209   3  2959   4  138.8   3
        ^^^^      ^^^^      ^^^^      ^^^^^

AES:

>  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
>       625   2   445   1   1455   2  113.5   3

It shows that on your machine, serpent is _by far_ faster than AES.
I would be very interested in what kind of Linux you are using (32/64bit)
and in the output of "cat /proc/cpuinfo".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Salatiel Filho]

On Sat, Aug 8, 2009 at 05:27, Heinz Diehl<htd@fancy-poultry.org> wrote:
> On 08.08.2009, Salatiel Filho wrote:
>
> Serpent:
>
>>  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
>>       2050   7  1209   3  2959   4  138.8   3
>        ^^^^      ^^^^      ^^^^      ^^^^^
>
> AES:
>
>>  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP
>>       625   2   445   1   1455   2  113.5   3
>
> It shows that on your machine, serpent is _by far_ faster than AES.
> I would be very interested in what kind of Linux you are using (32/64bit)
> and in the output of "cat /proc/cpuinfo".


root@LS-GL7D6:~# cat /etc/debian_version
5.0.1

root@LS-GL7D6:~# uname -a
Linux LS-GL7D6 2.6.30 #1 PREEMPT Sat Jun 27 00:17:47 BRT 2009 armv5tel GNU/Linux


root@LS-GL7D6:~# cat /proc/cpuinfo
Processor	: Feroceon rev 0 (v5l)
BogoMIPS	: 266.24
Features	: swp half thumb fastmult edsp
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 0

Hardware	: Buffalo Linkstation Pro/Live
Revision	: 0000
Serial		: 0000000000000000


root@LS-GL7D6:~# free -m
             total       used       free     shared    buffers     cached
Mem:           123        119          3          0          2         70
-/+ buffers/cache:         46         76
Swap:            0          0          0






>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".

Re: [dm-crypt] 1,5 TB partition: use cbc-essiv or xts-plain?

[Sam]

I believe that in the papers the Serpent team submitted for the AES 
competition they claim that Serpent is faster than Rijndael on X86-64.

Sam

> Hi!
>
> Salatiel Filho writes:
> >>....
> >> serpent-cbc-essiv:sha256
> >
> > I really liked this one, using aes-cbs-essiv:sha256 [keysize=256] i
> > was able to get only 0.89MB/s reading via NFS from my ARM 266Mhz.
> > Using serpent-cbc-essiv:sha256[keysize=256] i can get 2,66MB/s,
> > which is really good.
>
> Fascinating.  I thought Serpent was universally the slowest of the
> three big algorithms (AES/Rijndael, Twofish, Serpent) that was used if
> you wanted highest security margins.  Your speed test results come
> quite unexpected for me, especially since AES and Twofish have
> assembler modules while Serpent has only a C implementation in the
> kernel (as of last time I checked).
>
> For me, speed is quite secondary, because I have a fast machine which
> crypts much faster than the USB-2.0 interface can possibly serve the
> data.
>
> **Henrik
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt