Re: MC2
- From: tomstdenis@xxxxxxxxx
- Date: 26 Dec 2005 21:31:24 -0800
Miroslav Stampar wrote:
> Well, then I wouldn't have anything against if you help me make F
> function better. I know that some new ciphers shortcircuit this problem
> with bad boxes by taking them from Rijndael (AES), but I am not that
> kind of guy.
AES wasn't the first cipher to use inversion [also known as
"exponential" sboxes]. See MISTY1, Square, SHARK and a few others I
think.
Inversion sboxes [exponential ... x^3 in odd sized fields is also
another, infact x^3 has the best DC and LC profiles of all possible
functions. It also is weak against algebraic attacks which gets you
the catch-22].
Basic properties of an sbox you want
Security [implementation agnostic]
1. Low [but not minimal] DC and LC profiles
2. High algebraic degree [e.g. you want each output bit to be a
function of highest degree of all input bits, and you want them to be
linearly independent]
3. Usually avoiding points of involution and fixed points is ideal
4. Usually bijections are more ideal
Security [implementation specific]
1. You want a sbox with a good hardware footprint, e.g. efficiently
computable in the smallest area with an eye to DPA
2. You want a sbox with a good software implementation, e.g. small,
computable in fixed time over the entire domain.
Generally from a practical standpoint a random sbox is better than an
exponential. Conventional wisdom used to be you want the LC and DC
profiles as low as possible [hence Misty1, SQUARE, SHARK and AES] but
more and more they're become troublesome. The problem is that they're
highly subject to algebraic modelling in their respective fields
[usually GF(2)[x]] . Introducing things line non-linear addition or
multiplication [e.g. in Z or Z/pZ] influence the LC and DC profile and
make the design harder to analyze.
So in generally in practice you're better off with a scheme where sbox
counting is easy [e.g. wide-trail] with a random [but well scrutinized]
sbox.
[plug] My CS^2 cipher shows how to use small 4x4s to make an 8x8 and
then use that in a 16-point FPHT. The cipher achieves perfect
diffusion [resists integration attacks], has a branch of 12 [resists LC
and DC] and is ideally high on the algebraic order [e.g. more difficult
to get a MVQ condition]. I use the round function as the key schedule
which makes a pipeline with high key agility a possibility [it also
makes the key schedule resistant to related key attacks]. In software
the design sucks. It was designed solely for hardware.
Then you have people like DJB with Salsa20 where they use a series of
rotations plus "non isomorphic" operations to achieve a good deal of
non-linearity. The design in practice is secure but it's hard to
analyze. He did this for a high level of timing security on 32-bit
processors at an expense of simplicty. Similarly with Phelix...
A good tradeoff is the Noekeon design which is almost wide-trail [I
disproved that a while ago] but achieves good branch with the specific
sbox and it's entirely timing invariant. It isn't as fast as Salsa20
or Phelix but it's easier to analyze [it's like Serpent and THREEWAY in
that respect].
.....
Too much info ... 12:31am ...
Tom
.
- References:
- Prev by Date: Re: Use of CRC to verify encrypted data integrity
- Next by Date: Re: Information regarding LRW-AES
- Previous by thread: Re: MC2
- Next by thread: Re: MC2
- Index(es):
Relevant Pages
|
|
