Re: Successful remote AES key extraction

From: BRG (brg_at_nowhere.org)
Date: 04/18/05

  • Next message: Eirik Seim: "Looking for accelerator cards for file encryption, not VPN" 
    Date: Mon, 18 Apr 2005 11:11:09 +0100

    D. J. Bernstein wrote:

    > BRG wrote:
    >
    >>I am simply pointing out that in comparing the speed of your assembler
    >>code with the speed of other people's C code you are not comparing like
    >>with like.
    >
    > Speed is speed. I'm simply reporting all the timings I found; I'm not
    > excluding any particular programming language. When I say that your AES
    > code reportedly takes 482 Pentium-III cycles (202 for expansion, 280 for
    > encryption), I'm making no comments about how that speed was achieved.

    My point is not about your comments on the speed of my code, its a more
    general point (I do think that your commentary on my code is wrong but
    that's not an issue that worries me).

    > If someone wants to explain bad performance or timing leaks by saying
    > ``I decided to use C and couldn't do better in C,'' that's useful data
    > for implementors choosing programming tools. But saying ``I decided to
    > use C and it's unfair to be compared to asm'' is silly.

    My point is not about fairness, its about accuracy and completeness
    given the purpose for which you are presenting comparisons.

    > Anyway, all I was saying was that the published aes_ppro code takes 23
    > Pentium III cycles per round with compressed tables, and nobody claims
    > that uncompressed tables can do better than 20 cycles, so obviously
    > there's not a serious slowdown from compressed tables. In fact, I see
    > no reason to disbelieve Agner Fog's statement that there's zero penalty
    > for arbitrary alignment within lines on the PPro/PII/PIII.

    I might look at this on current processors if I find the time.

      Brian Gladman

  • Next message: Eirik Seim: "Looking for accelerator cards for file encryption, not VPN"

    Relevant Pages

    • Re: The Times
      ... latter may now permit cyclists. ... Try comparing with a little further back. ... Remember, of course, that cars are unwelcome, and actively discouraged from using most of central London. ... Also don't forget that in the Netherlands cars and cycles are segregated at every opportunity, with cycles being banned from many motor roads, and cars are banned from cycle tracks. ...
      (uk.rec.cycling)
    • Re: Successful remote AES key extraction
      ... > code with the speed of other people's C code you are not comparing like ... code reportedly takes 482 Pentium-III cycles (202 for expansion, ... If someone wants to explain bad performance or timing leaks by saying ... Pentium III cycles per round with compressed tables, ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... >>I don't accept your speed comparisons with other published code because ... > is taking 23 Pentium M cycles. ... Moreover comparing AES code designed for high key agility (on the fly ...
      (sci.crypt)
    • Re: Successful remote AES key extraction
      ... > choice of programming tools, that's something that should be emphasized, ... Whether C or assembler is the better choice for implementation will be ... I am simply pointing out that in comparing the speed of your assembler ... >>key expansion) with code designed for static keying (pre computed key ...
      (sci.crypt)
    • Re: [crit] Fallen
      ... It's very close to assembler... ... by the compiler for what purpose, ... But, comparing mathematical ... programming to systems-level programming is a fairly apples/oranges ...
      (rec.arts.sf.composition)