[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loop-AES and Twofish on 64-bit CPU

Peter_22@xxxxxx wrote:

--- Ursprüngliche Nachricht ---
Von: markus reichelt <ml@xxxxxxxxxxxxx>
An: linux-crypto@xxxxxxxxxxxx
Betreff: Re: Loop-AES and Twofish on 64-bit CPU
Datum: Sun, 07 May 2006 23:32:57 +0200

* Peter_22@xxxxxx wrote:



Blow- and Twofish are the only alternatives to AES. I?d like to use
two loops on one partition and use at least two ciphers to gain
better security.



First I would like to mention that this is not likely to increase the security in any way. The ciphers
are well analyzed and have no known attacks. If there are weak spots in the scheme it is likely
to be in the loop-implementation itself, since this is far less analyzed, and in that case an extra
layer of encryption is more likely to weaken security than to strengthen it. (Note: I don't know of
any exploitable holes in the loop implementation, I just say that more people have tried to find holes
in AES)

There's also serpent.



Which is, to my knowledge, derived from AES.

Serpent is not derived from AES. It was one of the five final canditates to be AES, which the
algorithm Rijndael (now known as just AES) won. So it was a competing candidate for being
AES, and based on a quite different design. The other final candidates were Twofish and RC6 and Mars.
Serpent is considered by many cryptographers to be a good number two, others like Twofish. Nobody
like Mars, and RC6 is patented. All of them are belived to be secure.

I´d wonder if serpent is
optimized for amd64 cpu. So far I can assure to everyone that the 64bit
optimization for AES was a breakthrough.



Unlike AES, Serpent don't have immidiate gain from a 64-bit CPU, as it is quite close to
optimal on a 32-bit chip, and it don't need the extra registers on the AMD64 architecture to be fast.
In fact it does only read the keys and the input during an encryption. Just look at the emited assembly
code of the serpent function (-O2 -fomit-frame-pointer), and it is quite well optimized.

One difference however, is that the AMD chips has more ALUs, and can thus do more arithmetric
operation in parallel, which means that different sets of sbox-functions will be optimal on the two
CPUs, but the one being optimal on opteron will be almost optimal on PIII and PIV, so this set
of sboxes is already in the current implementation of serpent.

Another thing is that since serpent don't gain so much from a new instruction set, the differences between
the 64-bit CPUs from AMD and intel may be as important as the difference between the 64 and 32-bit
chips.

What you can gain from a 64-bit CPU is that serpent then can run two encryptions in parallell
(but not in CBC-mode unfortunatly) or two decryptions in parallell (also in CBC-mode), and this will
double the speed of serpent. Unfortunatly this does not fit with the kernel API for crypto, so it is not
implemented. Brian Gladman developed such an implementation once using the MMX instuction set,
as this was before the AMD64 existed.

Dag Arne Osvik's paper on optimization of Serpent: http://www.osvik.no/pub/aes3.pdf

This paper describe a search function for sboxes for serpent. The sboxes in the current implementation
was found with a bit different method, but you get an impression.

-Gisle

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/