Victor Duchovni wrote:
(b) Is there a better way to scramble the timing of an AES operation
without going to the last resort of padding everyting to worst-case timing?
Perhaps something along the lines of:
"Provably Secure Masking of AES": http://eprint.iacr.org/2004/101.pdf
Just found
On Friday 24 June 2005 04:36, Beryllium Sphere LLC wrote:
> >1) How do you generate this in a way that does not leak information about
> the permutation generated?
>
> >2) How many times can you re-use a single indirection array?
>
> >3) How quickly can you generate new indirection arrays?
>
> G
On Fri, Jun 24, 2005 at 03:36:19AM -, Beryllium Sphere LLC wrote:
> (b) Is there a better way to scramble the timing of an AES operation
> without going to the last resort of padding everyting to worst-case timing?
Perhaps something along the lines of:
"Provably Secure Masking of AES": h
>1) How do you generate this in a way that does not leak information about
the permutation generated?
>2) How many times can you re-use a single indirection array?
>3) How quickly can you generate new indirection arrays?
Good questions, which probably require empirical answers.
The added cost
On Thu, 23 Jun 2005, Beryllium Sphere LLC wrote:
Can you destroy the relationship between key contents and timing without
hurting average run time?
Each round of AES has sixteen table lookups. If you permute the order in which
the implementation does the lookups, then you get a completely
Can you destroy the relationship between key contents and timing without
hurting average run time?
Each round of AES has sixteen table lookups. If you permute the order in which
the implementation does the lookups, then you get a completely different
pattern of cache hits and misses. If you pe
