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

[Scott Arciszewski <[e-mail]>]

Hi Jason,

I strongly agree that this is an important question to tackle. I've taken
my first swing at addressing it here:
https://github.com/bikeshedders/xchacha-rfc/pull/9

The construction seems "obvious", and it's easy to extend the same
arguments in the XSalsa20 paper (in particular regarding the design of
HSalsa20) to ChaCha. The logic is quite straightforward between the two
designs. However, I similarly cannot find any papers formalizing this
argument.

Note: Lacking any university affiliations, I don't have any means of
getting a formal peer-reviewed paper published (that I'm aware of, anyway).
If anyone else would like to take the initiative on this, it would be
greatly welcomed and appreciated.

Aside from that, if anyone can sanity-check the argument being made here,
please feel free to do so.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>


On Thu, Oct 11, 2018 at 4:42 PM Jason Cooper <[e-mail]> wrote:

> 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)
>