Security of OpenSSL ECDSA signatures

Dan Kaminsky dan at
Tue May 24 18:21:26 EST 2011

On Tue, May 24, 2011 at 1:15 AM, Aris Adamantiadis <aris at>wrote:

> Le 24/05/11 10:08, Damien Miller a écrit :
> >
> > I guess if you wanted to dither (pun!) then you could do something like:
> >
> > +       duration = (duration + (arc4random() & 1) ? 999 : 0) / 1000;
> >
> > to make it random whether you round up or down, but I suspect that would
> > increase the infomation leaked rather than decrease it.
> >
> I think that shooting in the dark in order to block unknown timing
> attacks is likely to worsen the problem rather to mitigate it. Wouldn't
> be better to "simply" analyze the upstream algorithm and try to make it
> O(1), whatever the situation ?
> As said in the thread, putting timer loops will not stop side infoleaks
> like cpu load, cache misses etc.

 It's the quotes around "simply" that belie everything.  I had someone swear
up and down that MD5 was always constant time.  And it should be.

MD5 in Javascript isn't.  It just isn't, not even close.

Other people can pretend local security works; I'm simply going to focus on
the network case.  My assumption is that OpenSSH simply borrows the ECDSA
implementation from OpenSSL and doesn't have the degrees of freedom to learn
how to make it either constant or uncorrelated (as in RSA blinding) time.
 It does have the freedom to delay network traffic, however.

More information about the openssh-unix-dev mailing list