Re: Don't use S-boxes!

karl_m_at_acm.org
Date: 11/19/04


Date: 18 Nov 2004 15:59:31 -0800


"David Wagner" <daw@taverner.cs.berkeley.edu> wrote in message
news:cnj9he$q3f$1@agate.berkeley.edu...
> karl malbrain wrote:
> >The issue is a version of AES that can be implemented that
withstands
> >timing attacks.
>
> That's trivial to achieve. The real issue is whether it is possible
> to implement AES in a way that withstands timing attacks *and* is
relatively
> efficient, where "relatively efficient" means "not too much slower
than
the
> best existing (non-constant-time) AES implementations".
>
> Comparing to a very slow existing non-constant-time implementation is
> not interesting. You have to compare to the best existing
implementations
> to get a meaningful comparison -- or, you have to report absolute
performance
> numbers in some accepted metric (e.g., cycles/byte).

The specific values of cycles-per-byte for the encryption function with
a pre-expanded key increased from 375 to 750 cycles per byte on my
reference implementations. While I believe from assembly code
inspection the code has a constant length with process only jumps and
running through the entire s-box table 8 times per byte-transform, the
resultant cycles per byte timings are not constant for some unknown
reason.

Meanwhile, I'm having a major problem.

I'm unable to duplicate the published attack, and frankly don't
understand
how the "simple cache-timing attack on AES" keeps the S-BOX values out
of
the cache for reload-timings during its run-after-run collections of
cycle counts. Perhaps Professor Bernstein has not implemented
something correctly, or has a hardware misconfiguration where the Level
1 or Level 2 cache is turned-off. Has anyone been able to duplicate
his result? I'll post sample code on my web site shortly.
Thanks, Karl m



Relevant Pages

  • Re: AES Timing Attack Implementation & Karl Malbrain code...
    ... This code implements AES without using large tables. ... slow but will not be vulnerable to the DJB attack since this ... and 229 cycles per byte for the immune small table C ... Are you including or excluding the cost of setting up the key schedule? ...
    (sci.crypt)
  • Re: AES Timing Attack Implementation & Karl Malbrain code...
    ... This code implements AES without using large tables. ... slow but will not be vulnerable to the DJB attack since this ... and 229 cycles per byte for the immune small table C ... Are you including or excluding the cost of setting up the key schedule? ...
    (sci.crypt)
  • Re: AES Timing Attack Implementation & Karl Malbrain code...
    ... This code implements AES without using large tables. ... slow but will not be vulnerable to the DJB attack since this ... and 229 cycles per byte for the immune small table C ... I provide AES in x86 assembler code for using this technique. ...
    (sci.crypt)
  • Re: Quadruple Algorithms
    ... occurring" (a fatal flaw being found in AES, ... the most likely attack on your entire system, ... Threat one: Your implementation of AES has an undiscovered ... with the output of one cipher feeding ...
    (sci.crypt)
  • Re: Only people who originally frequent sci.crypt reply to this
    ... The mode of a cipher is one of the many, ... you need to get right in order to turn a secure algorithm into a secure ... there are no known attacks against AES. ... attack of any kind against a cipher, ...
    (sci.crypt)