Re: [Cfrg] Poly1305 and timing attacks

[Yoav Nir <[e-mail]>]

On Mon, Mar 10, 2014 at 12:48 AM, Watson Ladd <[e-mail]> wrote:

> On Sun, Mar 9, 2014 at 3:00 PM, Yoav Nir <[e-mail]> wrote:
> >
> > On Mar 9, 2014, at 6:45 PM, Watson Ladd <[e-mail]> wrote:
> <snipped agreement>
> >
> >> For Poly1305 as used in this draft, I am very, very hesitant about
> >> approving any draft that says not-constant time is okay. However, if
> >> the entire keys are being generated pseudorandomly, then I think, if
> >> the side channel isn't gratuitously large, it's possibly safe. Saying
> >> anything more concrete would require a lot of painful analysis of what
> >> is leaked and how it can be used.
> >>
> >> Personally, I don't understand why making the crypto not constant
> >> time, and thus open to attacks, simplifies the security
> >> considerations. It might make the job of the implementor easier, but
> >> it makes the job of the person who builds on top harder.
> >
> > It makes the security considerations simpler because it makes all the
> talk about constant time implementations go away and eliminates the need
> for pointing people at how to accomplish this. I agree I probably can't do
> this, as this implementation might later be used as part of a library for
> other things. It's not generally good to instruct people on how to make an
> implementation with a warning label (that they will later ignore).
>
> Well, I have to fundamentally disagree with this. A constant-time,
> constant-memory access, constant-control flow implementation is far
> more reassuring than one which doesn't have these properties.


Hey, no need to pile it on. You've already convinced me that the text needs
to stay.

Do you have a reference I can point to on how to make the Poly1305
calculations constant-time?

Yoav