Mailing List Archive

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
Re: Encryption Ciphers [ In reply to ]
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=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887
Re: Encryption Ciphers [ In reply to ]
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-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
I found something really interesting from an interview with Bruce Schneier who authored Blowfish and Twofish. He recommends using the newer Twofish algorithm.

"At this point, though, I'm amazed it's still (Blowfish) being used. If people ask, I recommend Twofish instead."

http://www.computerworld.com.au/index.php/id;1891124482;pp;3;fp;4194304;fpid;1

Brian Micek


Thursday February 28 2008 10:34 am, 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

-- gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
> > 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?
I think a 256 bit cipher has 2^256 combinations or 115792089237316195423570985008687907853269984665640564039457584007913129639936
I think a 320 bit cipher has this many combinations:
2135987035920910082395021706169552114602704522356652769947041607822219725780640550022962086936576

I think the number of particals in the universe is 10^72 to 10^87 (http://www.stormloader.com/ajy/reallife.html). I think both numbers are smaller than 2^256

Brian Micek


-- gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
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.
Re: Encryption Ciphers [ In reply to ]
On Thu, Feb 28, 2008 at 1:29 PM, Florian Philipp
<lists@f_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/~baker/devices/lxr/http/source/linux/drivers/md/dm-crypt.c#L110
--
gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
On Thu, 2008-02-28 at 15:19 -0500, Mansour Moufid wrote:
> On Thu, Feb 28, 2008 at 1:29 PM, Florian Philipp
> <lists@f_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/~baker/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?
Re: Encryption Ciphers [ In reply to ]
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
dubkat@gmail.com GPG Key: 0x36833401
http://sigterm.us/

-==========================================-
Re: Encryption Ciphers [ In reply to ]
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: http://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/Advanced_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
--
pepe@unixfan.net gpg --recv-key A04D7875
Key fingerprint: B805 57BE E4AF 0104 CC51 77A1 CE6F 8D46 A04D 7875
Re: Encryption Ciphers [ In reply to ]
On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz <pepe_ml@gmx.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/crypto-services/crypto-algorithms-e.html
--
gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
On Fri, 2008-02-29 at 22:31 -0500, Mansour Moufid wrote:
> On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz <pepe_ml@gmx.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/crypto-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.
Re: Encryption Ciphers [ In reply to ]
On Sat, Mar 1, 2008 at 10:43 AM, Florian Philipp
<lists@f_philipp.fastmail.net> wrote:
>
> On Fri, 2008-02-29 at 22:31 -0500, Mansour Moufid wrote:
> > On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz <pepe_ml@gmx.net> wrote:
<snip>

While I've been following this thread, I noticed this advert at the
top of my screen:

Break my cipher!: http://www.accessdata.co.nz/

Just thought I might share in case there was some budding
cryptographer fancied having a crack.


/me isn't affiliated with/doesn't know the owner of the site
--
gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
On Sat, 2008-03-01 at 11:48 +0000, Calum wrote:
> On Sat, Mar 1, 2008 at 10:43 AM, Florian Philipp
> <lists@f_philipp.fastmail.net> wrote:
> >
> > On Fri, 2008-02-29 at 22:31 -0500, Mansour Moufid wrote:
> > > On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz <pepe_ml@gmx.net> wrote:
> <snip>
>
> While I've been following this thread, I noticed this advert at the
> top of my screen:
>
> Break my cipher!: http://www.accessdata.co.nz/
>
> Just thought I might share in case there was some budding
> cryptographer fancied having a crack.
>
>
> /me isn't affiliated with/doesn't know the owner of the site

Well, the author of that site refers to his system as similar to a
One-Time-Pad. If it really is an OTP, you can't break it except by theft
of the key.
Re: Encryption Ciphers [ In reply to ]
I just wanted to jump in and say that I'm personally a fan of Serpent. I
like to use something that's a little less popular, but still open. It is
similar in strength (IMHO), but there will be more people trying to break
AES than Serpent. For example, I've read the XSL attack that can weaken AES
is too complex when used on Serpent -- it would be more expensive than a
brute force attack.

On Sat, Mar 1, 2008 at 5:28 AM, Florian Philipp <lists@f_philipp.fastmail.net>
wrote:

>
> On Sat, 2008-03-01 at 11:48 +0000, Calum wrote:
> > On Sat, Mar 1, 2008 at 10:43 AM, Florian Philipp
> > <lists@f_philipp.fastmail.net> wrote:
> > >
> > > On Fri, 2008-02-29 at 22:31 -0500, Mansour Moufid wrote:
> > > > On Fri, Feb 29, 2008 at 9:37 PM, Steffen Schulz <pepe_ml@gmx.net>
> wrote:
> > <snip>
> >
> > While I've been following this thread, I noticed this advert at the
> > top of my screen:
> >
> > Break my cipher!: http://www.accessdata.co.nz/
> >
> > Just thought I might share in case there was some budding
> > cryptographer fancied having a crack.
> >
> >
> > /me isn't affiliated with/doesn't know the owner of the site
>
> Well, the author of that site refers to his system as similar to a
> One-Time-Pad. If it really is an OTP, you can't break it except by theft
> of the key.
>
Re: Encryption Ciphers [ In reply to ]
Hi

> I just wanted to jump in and say that I'm personally a fan of Serpent. I
> like to use something that's a little less popular, but still open. It is
> similar in strength (IMHO), but there will be more people trying to break
> AES than Serpent. For example, I've read the XSL attack that can weaken AES
> is too complex when used on Serpent -- it would be more expensive than a
> brute force attack.

in my opinion quite a bad assumption. the more a crypto algorithm is
open, the more people it test, the more it can be assumed that it is
safe against current known attacks.

greets pete
--
gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
Hello,

Am Donnerstag, 6. März 2008 schrieb Peter Meier:
> > I just wanted to jump in and say that I'm personally a fan of Serpent. I
> > like to use something that's a little less popular, but still open. It
> > is similar in strength (IMHO), but there will be more people trying to
> > break AES than Serpent. For example, I've read the XSL attack that can
> > weaken AES is too complex when used on Serpent -- it would be more
> > expensive than a brute force attack.
>
> in my opinion quite a bad assumption. the more a crypto algorithm is
> open, the more people it test, the more it can be assumed that it is
> safe against current known attacks.

IMHO even worse: You will need not only enough people to have it tested (means
more to try it out), but enough people to have it _analyzed_ independently
(this one will constrain the set of possible persons a lot) _and_ made the
results public (I fear this one is also a working limit on that set).

Not that I want to correct you in any way, but I think that's the essence of
what you wanted to express - only to make things clear.

Kind regards!
Eckard
--
gentoo-security@lists.gentoo.org mailing list
Re: Encryption Ciphers [ In reply to ]
The idea of avoiding something less popular, is that if someone gets your
encrypted data, they could look through the algorithm and find a hole and
break it without you knowing. However, choosing Serpent is not a choice of
security through obscurity. Serpent is as open as AES, and in this day and
age we have fairly reliable ways of deciding what makes a strong encryption
cipher. Serpent came in 2nd in the AES contest, only beaten by Rijndael
(which directly became AES). It is a 32-round substitution-permutation
network where 16 rounds were deemed sufficient. Which, by the way, helped
against the XSL attack (which can weaken AES), when applied to Serpent it is
more expensive than a brute force attack (not true for AES).

There is probably more to gain by announcing you broke Serpent than by using
it for personal gain, where I would argue the opposite is true of AES. That
said, this conversation was initially about personal laptops and personal
computers, and I only ever suggest it for personal use. Of course if you
have government secrets or corporate data that needs to be secured, you
should use something under heavy scrutiny. There is a lesser chance of a
determined group of mathematicians getting at your data since many in the
academic world are actively trying to break it.

To say either AES or Serpent will never be broken is simply ignorant, but
when it happens there will likely be programs to decrypt such data. Lets
say which ever cipher you chose is broken tomorrow. I'm guessing the AES
tools will be easier to get, and use than the Serpent ones. So if some
random thief steals your laptop, they are more likely to decrypt it if you
use AES. This scenario is more likely if they make an image of the hard
drive to save for later. Again, all this changes if your data is very
valuable for some reason, but I don't consider it a bad choice for personal
use.

On Thu, Mar 6, 2008 at 8:30 AM, Peter Meier <peter.meier@immerda.ch> wrote:

> Hi
>
> > I just wanted to jump in and say that I'm personally a fan of Serpent.
> I
> > like to use something that's a little less popular, but still open. It
> is
> > similar in strength (IMHO), but there will be more people trying to
> break
> > AES than Serpent. For example, I've read the XSL attack that can weaken
> AES
> > is too complex when used on Serpent -- it would be more expensive than a
> > brute force attack.
>
> in my opinion quite a bad assumption. the more a crypto algorithm is
> open, the more people it test, the more it can be assumed that it is
> safe against current known attacks.
>
> greets pete
> --
> gentoo-security@lists.gentoo.org mailing list
>
>