Re: cgd(4) ciphers

   Date: Wed, 02 Oct 2013 21:09:05 +0200
   From: Jean-Yves Migeon <[email protected]>

   Le 02/10/13 17:32, Taylor R Campbell a écrit :
   >     Date: Tue, 01 Oct 2013 00:14:17 +0200
   >     From: Jean-Yves Migeon <[email protected]>
   >
   >     What makes you think that Serpent fills that role better than AES/Rijndael?
   >
   > I thought I addressed this in my message.

   Not really. Both have same block size, side channels are indeed a 
   problem but is more a matter of implementation than algorithm. So I 
   cannot see why implementing Serpent would be any more useful than using 
   the actual AES

Threefish and Serpent were designed to be easy to implement fast in
software without timing side channels: they involve no data-dependent
branches or memory references (nor multiplication/division, &c.; that
is, they involve only add, rotate, shift, xor, and data-independent
memory references).

AES's data-dependent S-boxes make this difficult.  As far as I know,
there is no performance-competitive software implementation of AES-CBC
without data-dependent memory references, and there have been a number
of semipractical and practical attacks reported in the literature
using cache timing to recover AES keys, including AES used for disk
encryption.

                  (except that we lose hardware acceleration in some cases, 
   as well as a more the testing and review from AES).

Currently cgd can't take advantage of hardware acceleration anyway,
and part of the appeal of Threefish and Serpent is to support users
who lack the amenities of hardware acceleration, without subjecting
them to the dangers of timing side channels.

   > But I meant to focus on
   > Threefish, with the older Serpent as a more conservative fallback.

   IMHO I would not bother with Serpent for that case then.

I mentioned Serpent alongside Threefish for more or less the same
reason that cgd included 3DES alongside AES: to provide a more
historically conservative choice.