Re: Don't use S-boxes!

karl_m_at_acm.org
Date: 11/20/04

  • Next message: Douglas A. Gwyn: "Re: Limits of One-Time Pads?"
    Date: 19 Nov 2004 15:00:38 -0800
    
    

    David Wagner wrote:
    > >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.
    >
    > That counts as extremely slow -- so slow as to render this
    > implementation strategy pretty useless, most likely.

    Well, I guess it would be worthwile to study more. When I first saw
    Professor Burnstein's "Summary of AES" I skipped over it. Now that
    I've read it, and see that it's a highly optimized implementation that
    expands the SBoxes from 256 into thousands of bytes. No wonder there's
    a cache-timing attack.

    So my proposed re-layout to the 256 byte S-Box is totally unnecessary,
    and in fact my original implementation is immune to simple timing
    attacks. That's why I get random numbers from the timing attack on it.

    I'll look at optimizing the 227 (relatively constant) cycles per byte
    using the simple 256 byte S-Box table.

    Thanks, karl m


  • Next message: Douglas A. Gwyn: "Re: Limits of One-Time Pads?"

    Relevant Pages

    • Re: Successful remote AES key extraction
      ... > You are ignoring my larger point that such a timing attack involves ... needed by this embarrassingly simple timing attack. ... million packets (and used packet sizes much larger than the Internet ... TCP windows, Vernon? ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... Vernon Schryver wrote: ... > How do you figure that the present timing attack is feasable against ... > delayed by a data dependent N*5 microseconds? ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... How many L2 cache misses that have nothing to do with the AES code ... How many cache misses can be expected from a program with 1.3 resident ... the delays that a timing attack is trying to measure. ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... >> more than enough traffic to be a denial of service attack against ... >needed by this embarrassingly simple timing attack. ... >million packets (and used packet sizes much larger than the Internet ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... >target to carry the attack out. ... AES is only as secure as the least secure host within N ... I'm convinced this network timing attack on ... It is good to make your AES code or hardware take constant time, ...
      (sci.crypt)