Encryption Ciphers

Hi!

I just did some benchmarking on different ciphers for
cryptsetup-luks
and now I've got some questions:

1. Is it a valid way to benchmark by using "time dd
if=/dev/zero
of=/dev/mapper/cryptmapping -bs=1M"? The results seem
to match other
benchmarks but I just want to be sure.

2. I've tested every (sensible) cipher with 64, 128, 256 and
320bits
keysize (if supported). Apparently I can choose between:

Blowfish 64-256bit
Twofish 128-256bit
AES 128-256bit
Anubis 128-320bit

These are settings on which my harddisk limits transfer
speed, not the
encryption.

Surprisingly, Anubis is faster with 320bits than Blowfish
with the same
setting (Blowfish: 32MB/s, Anubis 37MB/s, hdparm -tT
38MB/s). Do you
think keysize is more important than choosing a cipher which
made it
further in the AES-contest and therefore using Anubis with
320bit would
be a better choice than AES or Twofish with 256bit? Might it
even be an
advantage because less people try to brake Anubis than AES
(although it
bears some similarity with AES and might be vulnerable to
the same
attacks)?

And if I need a faster cipher, do you think Blowfish with
64bit keys is
save for the next 3 years?

Thanks in advance!

Florian Philipp

Hello Florian 

Florian Philipp wrote:
> I just did some benchmarking on different ciphers for
cryptsetup-luks
I have not done benchmarks on my own, and cannot say if your
method is a 
good one. What I've read is, that
AES(Rijndael)-implementations have 
been optimized a lot on all platforms. The last test I've
read said, 
that the Linux AES (Rijndael) implementation is fastest
(compared with 
others in its class) at 128 bit, while at 256 bit Blowfish
is faster 
than AES (Rijndael). (This will most certainly differ on
other platforms!)

> Do you think keysize is more important than choosing a
cipher which
> made it further in the AES-contest and therefore using
Anubis with
> 320bit would be a better choice than AES or Twofish
with 256bit?
> Might it even be an advantage because less people try
to brake Anubis
> than AES (although it bears some similarity with AES
and might be
> vulnerable to the same attacks)?
 From what I've read, it is most important to use a well
understood and
heavily reviewed algorithm. That also means, that it is
good, if lots of
people have tried to break it.

> And if I need a faster cipher, do you think Blowfish
with 64bit keys
> is save for the next 3 years?
I think you should stick to Rijndael-128 or Blowfish-256 -
they are well 
optimized for your computer, heavily analyzed by
crypto-experts and 
provide both the cryptographic strength against most
attackers for the 
next few years (say the crypto-experts, to whom I do not
belong).

Bye,
Daniel

-- 
use PGP key  http://pgpkeys.pca.dfn.de/pks/lookup?search=0xB
B9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net
0xBB9D4887

Hi

> I just did some benchmarking on different ciphers for
cryptsetup-luks

will you share them somewhere?

for the other questions I can say the same as Daniel.

greets Pete
-- 
gentoo-securitylists.gentoo.org mailing list

On Thu, 2008-02-28 at 16:34 +0100, Peter Meier wrote:
> Hi
> 
> > I just did some benchmarking on different ciphers
for cryptsetup-luks
> 
> will you share them somewhere?
> 
> for the other questions I can say the same as Daniel.
> 
> greets Pete

I didn't test that much. I found many ciphers do not work
with
cryptsetup-luks. I think it's because of limitations on the
blocksize. I
also found that cryptsetup refuses to create partitions with
>=512bit
keys and I can't open ones with a keysize above 320bit
(still have to
check bug reports).

As I already wrote, I was only interested in whether they
are faster
than my HDD (38MB/s) and I've only checked 64,128,256 and
the maximum
supported keysize.

So here are the results:

Blowfish: 64,128 and 256bit. Speed at 320bit: 31MB/s
Twofish: 128,256bit
AES (Rijndael): 128,256bit
Serpent: none (26MB/s with 64bit keys)
Anubis: 128,256,320bit
Camellia: 128bit (I don't remember it's exact speed at
256bit but it
lost dramatically)
Cast6: none (Somewhere between 20 and 30MB/s)

My system:

Intel Celeron M 530  1.73GHz
Cache: 1024KB
Flags: SSSE3
RAM: DDR2-533
HDD: 2,5" 5400rpm
Kernel: 2.6.24-tuxonice-r2 64bit, preemtible

UPDATE: Just as I wrote this, I did some new tests on my new
kernel
which is not completely preemtible and I also used a nice
setting of -20
on dd. Apparently, now my system is fast enough for Blowfish
with
320bit. Therefore I did some new tests. 

This time I've watched CPU-utilization because Blowfish,
AES, Twofish
and Anubis all accomplished 38MB/s. Only Serpent still fails
with
26MB/s.

Here are the results for *-xts-plain:sha256 --key-size 256

with * =
AES:40-60%
Twofish:60%
Anubis: 65%
Blowfish: 90%

Some other tests: There seems to be no speed difference
between
cbc-essiv, lrw-benbi and xts-essiv/plain/benbi. 

The hash-function seems to have no influence, either. I've
tested
Whirlpool (wp512), SHA256, SHA-1 and Tiger (tgr128).

Please take my results with a big dose of salt. I only did
them for
myself, everything quick and dirty. I did not switch to
single-user mode
although I repeated tests if I thought that there was some
background
activity. I did not repeat tests to average the results or
something
like that.

In the end, I think I'll choose three ciphers:

Since Serpent is still considered the safest of them all
I'll use it for
very important data which is easily stolen, for example my
external HDD,
maybe my /home-partition as well.

Where speed is critical and other processes should not be
interrupted,
I'll use AES and possibly go down to 128bit, for example on
/var.

Where both security and speed are important, for example
when making
backups, I'll use Anubis with 320bit. I found some
documentation from
NESSIE on Anubis and it sound promising, especially because
additional
keysize adds more rounds to the encryption and thus making
serious
brakes harder to accomplish.

Talking about hashs, I'll stick with Whirlpool because it
made it
through the NESSIE-evaluation.

One last question for everyone who has read this rather long
mail (thank
you, btw): What exactly is benbi in aes-lrw-benbi:sha256 and
what should
I choose for XTS? The kernel description states plain but
essiv and
benbi work as well.  

On Thu, Feb 28, 2008 at 1:29 PM, Florian Philipp
<listsf_philipp.fastmail.net> wrote:
>  One last question for everyone who has read this
rather long mail (thank
>  you, btw): What exactly is benbi in
aes-lrw-benbi:sha256 and what should
>  I choose for XTS? The kernel description states plain
but essiv and
>  benbi work as well.
>

benbi is an IV generation algorithm. If you look at the
dm-crypt
sources [1], benbi stands for "big-endian 'narrow
block'-count" (not
sure where they got the `i' from...). There's also one
called bewbi,
which I thought was entertaining.

Sincerely,
Mansour Moufid

[1] http://www.cs.fsu.edu/~bake
r/devices/lxr/http/source/linux/drivers/md/dm-crypt.c#L110
-- 
gentoo-securitylists.gentoo.org mailing list

On Thu, 2008-02-28 at 15:19 -0500, Mansour Moufid wrote:
> On Thu, Feb 28, 2008 at 1:29 PM, Florian Philipp
> <listsf_philipp.fastmail.net> wrote:
> >  One last question for everyone who has read this
rather long mail (thank
> >  you, btw): What exactly is benbi in
aes-lrw-benbi:sha256 and what should
> >  I choose for XTS? The kernel description states
plain but essiv and
> >  benbi work as well.
> >
> 
> benbi is an IV generation algorithm. If you look at the
dm-crypt
> sources [1], benbi stands for "big-endian 'narrow
block'-count" (not
> sure where they got the `i' from...). There's also one
called bewbi,
> which I thought was entertaining.
> 
> Sincerely,
> Mansour Moufid
> 
> [1] http://www.cs.fsu.edu/~bake
r/devices/lxr/http/source/linux/drivers/md/dm-crypt.c#L110

Thanks!

So, am I right to believe that essiv is the best choice and
benbi just
some kind of special requirement for lrw or should I stick
with what's
recommended (although without reasons given for xts), e.g.
cbc-essiv,
lrw-benbi, xts-plain?

On Wednesday 27 February 2008 01:58:11 pm Florian Philipp
wrote:
> Hi!
>
> I just did some benchmarking on different ciphers for
cryptsetup-luks
> and now I've got some questions:
>
> 1. Is it a valid way to benchmark by using "time
dd if=/dev/zero
> of=/dev/mapper/cryptmapping -bs=1M"? The results
seem to match other
> benchmarks but I just want to be sure.
>
> 2. I've tested every (sensible) cipher with 64, 128,
256 and 320bits
> keysize (if supported). Apparently I can choose
between:
>
> Blowfish 64-256bit
> Twofish 128-256bit
> AES 128-256bit
> Anubis 128-320bit

I've never done any benchmarks myself, however a few years
back I did read 
up on which crytpo engine would be best for a large hard
disk or partition. 
I do remember clearly that there is a bug in AES's block
cyper that causes 
it to repeat keys on large disks/partitions. This
"feature" could make it 
easier for your key to be cracked. I personally use Twofish
256 with 
SHA256, ive never tried any other hash method. I also use
Serpent on my 
swap, for no other reason than to try something different -
and it's a cool 
name. (flame on!).

I tried to find that link that explains that AES flaw, but
to no avail. 
Maybe you'll have better luck if it's something that
concerns you.

ps. i am obviously no expert in cryptology - take my
comments with a grain 
of salt.


-- 
 -==========================================-

    Avoid the Gates of Hell. Use Linux.
      The choice of a GNU Generation.

   Daniel J Reidy       RipeID:  DJR9-RIPE
   dubkatgmail.com    GPG Key: 0x36833401
             http://sigterm.us/

 -==========================================-

On 080301 at 01:51, Dan Reidy wrote:
> I've never done any benchmarks myself, however a few
years back I did read 
> up on which crytpo engine would be best for a large
hard disk or partition. 
> I do remember clearly that there is a bug in AES's
block cyper that causes 
> it to repeat keys on large disks/partitions. This
"feature" could make it 
> easier for your key to be cracked. I personally use
Twofish 256 with 
> SHA256, ive never tried any other hash method. I also
use Serpent on my 
> swap, for no other reason than to try something
different - and it's a cool 
> name. (flame on!).

You may be talking about a generic problem when using a
block cipher in CBC mode.
The block size of a block cipher limits the total amount of
data that
can be encrypted using a single key, without reducing
security.

See also: h
ttp://en.wikipedia.org/wiki/Disk_encryption_theory

I'm pretty sure that there is no such bug in AES itself. A
known
problem however is the susceptibility to side-channel
attacks:
http://en.wikipedia.org/wiki/Advan
ced_Encryption_Standard#Side_channel_attacks
Ciphers can be designed to avoid side-channel attacks, but
NIST(sadly)
did not care about this problem during the AES contest.


About other algorithms...3DES is still considered very
secure due to
the very extensive review. AES is very new in comparison,
but has also
been heavily reviewed due to its status as encryption
standard. The
other AES finalists are probably about as secure. But if you
want to
use a different algorithm, or mode, adjust how a cipher is
used or
combine it with other ciphers, you should *really* know your
stuff.
And even then, you will probably miss something and the
result will be
less secure.


128bit are considered secure for the next several years. Its
much
easier and cheaper to guess your password, steal your
usb-key or
threaten your family than to break a 128 bit key by
bruteforce. If you
are afraid of quantum computers or aliens, you may want to
choose
256bit.


HTH,
pepe
-- 
pepeunixfan.net                            gpg --recv-key
A04D7875
Key fingerprint: B805 57BE E4AF 0104 CC51  77A1 CE6F 8D46
A04D 7875

On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz
<pepe_mlgmx.net> wrote:
>  128bit are considered secure for the next several
years.
>

On that subject, the CSEC (Communications Security
Establishment
Canada) publishes an updated summary of safe key
cryptoperiods for
different algorithms [1] which I like to use a reference.

Sincerely,
Mansour Moufid

[1] http://www.cse-cst.gc.ca/services/cryp
to-services/crypto-algorithms-e.html
-- 
gentoo-securitylists.gentoo.org mailing list

On Fri, 2008-02-29 at 22:31 -0500, Mansour Moufid wrote:
> On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz
<pepe_mlgmx.net> wrote:
> >  128bit are considered secure for the next several
years.
> >
> 
> On that subject, the CSEC (Communications Security
Establishment
> Canada) publishes an updated summary of safe key
cryptoperiods for
> different algorithms [1] which I like to use a
reference.
> 
> Sincerely,
> Mansour Moufid
> 
> [1] http://www.cse-cst.gc.ca/services/cryp
to-services/crypto-algorithms-e.html

"The use of HMAC with SHA-1 shall be discontinued by
the end of 2010."

Sounds like there is work to do for the cryptsetup-luks
developers...

One last thing: Serpent doesn't seem to loose performance
when used with
larger keys, still 28MB/s with 256bit keys.