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/
