[Cfrg] Review of draft-arciszewski-xchacha-02

[Neil Madden <[e-mail]>]

I’ve had a good look through draft-arciszewski-xchacha-02 from an implementor’s perspective. I think it’s a good draft that describes the algorithms well. I have some comments on a few parts of the text below:

Section 1, Introduction:

The text currently says:

"However, a more straightforward strategy can prevent nonce misuse
   conditions in environments where a large number of messages are
   encrypted.”

We should be careful with the word “prevent” here. Nonce reuse can still happen with large random nonces, even if it is less likely - e.g., with a broken or compromised PRNG. See for example failures in the Android SecureRandom implementation that led to compromise of a Bitcoin transaction due to nonce reuse in an ECDSA signature [1]. In this case the random nonce would have been 256 bits I believe, so even larger than that for XChaCha.

I think “more straightforward” is also potentially subject to debate (if you ignore the S2V parts, SIV is pretty simple). Perhaps wording along the following lines:

“However, misuse resistant cipher constructions come at a cost in
performance as they must necessarily make two passes over the 
message to be encrypted. An alternative strategy can significantly 
reduce the chance of accidental nonce reuse in environments 
where a large number of messages are encrypted. [Simply use …]”

Ironically, the main reason that I am interested in XChaCha20 is precisely because the larger nonce makes it more suitable for use in an SIV construction, as per my recent draft.

Section 2.1 Motivation for XChaCha20-Poly1305:

It might be worth clarifying that a 96-bit nonce is too short to generate randomly where you need to encrypt lots of messages with the same key (more than a few million). If you are doing DH with forward secrecy and generating fresh keys for each message anyway, then a 96-bit random nonce is fine.

The text: "A more
   conservative threshold (2^-32 chance of collision) still allows for
   2^64 messages to be sent under a single key.”

This should say “still allows for 2^80 messages to be sent under a single key.”

2.2 HChaCha20

This could do with a reference to RFC 7539 section 2.3. It could be a bit clearer that the ChaCha20 block counter is replaced with the first 32 bits of the nonce (in little-endian) and the remaining 96 bits are used as per usual in ChaCha20.

I have verified the supplied test vector with an independent implementation of HChaCha20 that I wrote, and it matches.

2.3.1 XChaCha20 Pseudocode:

The code doesn’t include the 4 NUL bytes in the nonce it passes to ChaCha20.

Test vectors:

I have verified that the test vectors in A.1 and A.2 and produce the same results as documented.

[1] https://www.symantec.com/connect/blogs/android-cryptographic-issue-may-affect-hundreds-thousands-apps

Kind regards,

Neil