Re: [Cfrg] [RFC] [DRAFT] eXtended-nonce ChaCha and AEAD_XChaCha20-Poly1305 (updated)

[Jason Cooper <[e-mail]>]

Hi Scott,

On Fri, Oct 05, 2018 at 01:36:47PM -0400, Paragon Initiative Enterprises Security Team wrote:
> I've uploaded draft01, which contains some typo fixes and an additional
> test vector for XChaCha20 directly.
> 
> https://datatracker.ietf.org/doc/draft-arciszewski-xchacha/
> 
> If anyone would like to contribute to this document directly, its
> development is being facilitated on GitHub:
> https://github.com/bikeshedders/xchacha-rfc
> 
> Of course, I'm also open to feedback/criticism via email as well.

This has been a long-sought low-hanging goal of mine, and I'm glad to
see someone picking it up!

I've asked this question before[1], and it seems now is the proper time
to bring it up again.  When DJB wrote "Extending the Salsa20 nonce"[2],
he included a security analysis of the construction.  To date, I've not
seen a similar proof for extending the Chacha20 nonce.

It seems as though care was taken to select the 256 bits (Section 2.2 of
your current version) which were not nibbles originally containing the
key.  Similar selection was done in XSalsa20.

So, my question is: Why is this ok?  I freely admit I've neither the
experience nor the mathematical prowess to understand DJB's XSalsa20
proof.  And it certainly *seems* correct to follow the pattern for
XChaCha20.

However, I'd really like to see this addressed in the RFC.  Either by
providing a similar proof to XSalsa20, or by referencing it and
justifying the extension.


Thanks,

Jason.

[1] http://www.metzdowd.com/pipermail/cryptography/2017-December/033256.html
[2] https://cr.yp.to/snuffle/xsalsa-20110204.pdf (referenced in RFC)
    https://cr.yp.to/snuffle/xsalsa-20081128.pdf (referenced in my email)