Re: [Cfrg] Poly1305 and timing attacks

Hi Yoav,

I disagree with the argument as it is currently stated. Suppose 96 bits of a 128-bit MAC key leak via a side channel analysis from a single invocation of the MAC. (Somewhat extreme but within the scope of the scenario you mention.)

Then an active MITM adversary can successfully inject a modified packet for the same key/sequence number with probability 2^{-32}, simply by guessing the missing key bits. That is, the effect of partial key leakage on security is not "null", even in the scenario where keys are only used once.

The argument you cite needs to be more carefully stated to properly account for this weakness.

Cheers

Kenny

Sent from my iPad

On 9 Mar 2014, at 14:56, "Yoav Nir" <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> wrote:

Hi

I mentioned this during the meeting, but there was no discussion on this subject there, so I thought I'd raise it here.

I got a private message in response to draft-nir-cfrg-chacha20-poly1305 that questions the text about constant time implementations for Poly1305. The argument can be outlined as follows:

Side channels in general and timing vulnerabilities in particular are bad because they reveal either parts of the plaintext they work on, or parts of the key that is used. However, Poly1305 works on the ciphertext that is sent on the wire anyway, so exposing that does not matter. Also, Poly1305 requires a different one-time key for each invocation, so revealing some information about that one-time key doesn't matter, because it will not be used again. So in summary, timing attacks on Poly1305 don't matter.

This argument is very attractive to me, because if it is valid, it makes the security considerations much simpler, and significantly reduces the complexity of implementing these algorithms (the "competent" vs "good" coder from slide 2).

So can anyone on this list comment on this argument?

Thanks

Yoav

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org<mailto:Cfrg@irtf.org>
http://www.irtf.org/mailman/listinfo/cfrg