[Cfrg] questions on performance and side channel resistance for ChaCha20 and Poly1305 for IPsec and TLS

[David McGrew <[e-mail]>]

Hi Adam and Yoav,

I have some questions and comments on these crypto algorithms and their 
use in TLS and IPsec.

On 01/21/2014 01:06 PM, Adam Langley wrote:
> On Tue, Jan 21, 2014 at 11:47 AM, Yoav Nir <[e-mail]> wrote:
>> Reviews and comments would be greatly appreciated, as well as anyone checking my examples.
> In the introduction: I think ChaCha20+Poly1305 are useful for software
> implementations, beyond their use as a backup to AES. AES in not
> suitable for pure, software implementations and they tend to be be
> slow and have side-channels. (AES-GCM even more so.)

The claims that ChaCha20+Poly1305 are faster than AES GCM in pure 
software environments should be quantified in (at least one of) the 
drafts.   I am not challenging the fact that ChaCha20+Poly1305 will 
perform better than a side-channel resistant implementation of AES GCM 
on some processors, and I support the development of an alternative AEAD 
mechanism for TLS, for diversity's sake even if there were no other 
considerations.   But as performance is cited as a motivation for 
adoption, it is important to document the true state of affairs by 
citing some relevant performance study for the combined AEAD algorithm, 
or at the very least extrapolate the performance of the combined 
algorithm from published performance of the constituent algorithms.

The important questions that I see:

- how much faster is ChaCha20+Poly1305 on typical 16 or 32-bit 
processors, when no hardware support for AES or GF multiplication are 
available?   The most interesting "typical" processor, I think, would be 
a mobile phone class processor, like a Snapdragon.

- how much slower is ChaCha20+Poly1305 when that hardware support is 
available?

It would also be interesting to look into the power used by the 
different algorithms, since battery life is important on mobile devices.

Another goal for this ciphersuite is to avoid side channel attacks, 
though it is not directly mentioned in the draft.    The design 
rationale for Salsa describes how timing channels are avoided by not 
using multiplication in that function.   However, Poly1305 uses *lots* 
of multiplication operations, by a fixed constant.  Unless I am missing 
something, this is an inconsistency with the motivation for the 
ciphersuite.  In any case, if Poly1305 requires implementation 
techniques to avoid side channels, they should be documented in the 
draft that specifies that function.

As a side note: the timing channels in GCM and Poly1305 can potentially 
leak the authentication key, but this would not affect 
confidentiality.   A timing channel in an AES implementation, on the 
other hand, could leak the encryption key.    So using ChaCha in some 
environments (a CPU small enough that bitslicing AES is unwieldy, for 
instance) seems well motivated.   Perhaps the timing channel on Poly1305 
is smaller than that of GHASH, at least for some implementation 
techniques, but regardless, the use of Poly1305 as a replacement for 
GHASH is less well motivated.

I assume that the timing channels are the major concern, and that the 
attack model is one in which an untrusted process running on a trusted 
operating system aims to discover the key of a ciphersuite in use by 
some other process.   It would be good to document that fact, to give 
implementers an idea of what the important channel is.   (Otherwise, 
they might mistakenly think that the attacker is only able to observe 
network traffic.)  Is it also a goal to avoid power analysis attacks?    
It would be good to document that fact, either way.

I think your goal here is to have both client and server use a 
hardware-friendly ciphersuite when they both have the right hardware, 
and to use a software-friendly ciphersuite otherwise. This would imply 
that the hardware-friendly ciphersuite comes first in the proposal when 
it is available; does it also mean that when the hardware support is 
absent, that the hardware-friendly ciphersuite is not offered?    Also, 
it seems that it would be necessary, in TLS, to have ciphersuites 
offered in hardware/software pairs, to ensure that an appropriate 
authentication method is available.   Maybe I misunderstood the goal, if 
so I trust that you will set me straight.   But if this is the goal, it 
would make sense to include guidance to this effect in the draft.

regards,

David