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

Thanks for the review and feedback, Neil.

I've made some other changes on Github and was going to get draft03 ready
today. I'll incorporate your suggestions as well.

Aside: Based on the responses to the "Adoption call for
draft-arciszewski-xchacha" thread
<https://www.ietf.org/mail-archive/web/cfrg/current/msg09854.html>, I
believe this will also be the last draft before CFRG adoption (which
presumably will change the filename in future editions).
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Tue, Dec 18, 2018 at 7:15 AM Neil Madden <neil.e.madden@gmail.com> wrote:

> 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
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>