[31808] in cryptography@c2.net mail archive
Re: NIST hash function design competition
daemon@ATHENA.MIT.EDU (Florian Weimer)
Thu Jul 20 17:16:39 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Florian Weimer <fw@deneb.enyo.de>
To: "Travis H." <solinym@gmail.com>
Cc: "Hal Finney" <hal@finney.org>, jamesd@echeque.com,
cryptography@metzdowd.com
Date: Thu, 20 Jul 2006 22:53:56 +0200
In-Reply-To: <d4f1333a0607130106k16ef114fqb5d6a23db6382ebe@mail.gmail.com>
(Travis H.'s message of "Thu, 13 Jul 2006 03:06:36 -0500")
* Travis H.:
> On 7/11/06, "Hal Finney" <hal@finney.org> wrote:
>> : So what went wrong? Answer: NIST failed to recognize that table lookups
>> : do not take constant time. =E2"Table lookup: not vulnerable to timing
>> : attacks," NIST stated in [19, Section 3.6.2]. NIST's statement was,
>> : and is, incorrect.
>
> That's interesting, since it is in line with conventional reasoning
> about algorithms. I've skimmed his paper, and I've taken a class on
> computer architecture and I haven't the foggiest idea where the
> variable timing comes from. Does anyone know if any of the following
> account for the phenomenon?
>
> 1) cache fills as we ascend through memory
> 2) additions (base+index) taking non-constant time (could be fixed
> with pointers if we're going sequentially)
> 3) virtual memory considerations (e.g. fetching new a page for a higher a=
ddress)
> 4) TLB misses
Is this about Colin Percival's work? IIRC, it's mainly about shared
associative caches which leak information about what addresses are
being cached across trust boundaries.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
