Jeremy Linton
Guest
|
 Posted:
Wed Dec 08, 2004 3:19 am Post subject:
Re: AES constant time table access |
|
|
From an earlier post it sounds like you were getting Pentium I u-v
pipeline conflicts, you might try using two copies of the table
interleaved on different cache line boundaries, reference one with the u
pipe instructions and the other with the v pipe instructions. It will
take up twice the cache, but reduce the cache conflicts.
karl malbrain wrote:
| Quote: | "Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:cp53id$ucb$1@osl016lin.hda.hydro.com...
karl malbrain wrote:
I tend to agree that the overall effect is randomization -- but these
are
cryptographer folk who work with terms of 2^128 complexity factors. The
effect that causes the skepticism is the timing attack on an
uninitialized
cache.
That is the easiest part: Simply iterate over the 4K table before
starting, this would require just 64 load operations 64 bytes apart, and
make the timing constant
I don't see any problem with this -- it would be 128 loads 32 bytes apart to
support the pentium, and add 128 cycles to a 500 cycle function. karl m
|
|
|
karl malbrain
Guest
|
| Posted:
Wed Dec 08, 2004 3:24 am Post subject:
Re: AES constant time table access |
|
|
"Jeremy Linton" <replytothelist@nospam.com> wrote in message
news:P%ptd.468$RC4.70@fe1.texas.rr.com...
| Quote: | From an earlier post it sounds like you were getting Pentium I u-v
pipeline conflicts, you might try using two copies of the table
interleaved on different cache line boundaries, reference one with the u
pipe instructions and the other with the v pipe instructions. It will
take up twice the cache, but reduce the cache conflicts.
|
We have to completely eliminate cache-bank-conflict stalls. They're also a
problem on the multiple issue Athlon processors when two "nearby"
instructions request data from the same cache bank, the second instruction
stalls for a cpu-cycle. karl m |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in