Subject: [Cfrg] Comments on draft-irtf-cfrg-xchacha-01

From: Kyle Den Hartog <[email-masked]>
Date: Tue, 29 Oct 2019 11:32:14 +1300

I've recently implemented the draft-irtf-cfrg-xchacha-01 in
xchacha20poly1305
<https://github.com/StableLib/stablelib/blob/master/packages/xchacha20poly1305/xchacha20poly1305.ts>
and
xchacha20
<https://github.com/StableLib/stablelib/blob/master/packages/xchacha20/xchacha20.ts>
in
Stablelib and wanted to provide some feedback on the RFC.

*Editorial*
I found that the decryption part of things was rather difficult because it
was under-specified (albeit it's just the reverse of encryption with tag
verification which I was able to reuse) and I was wondering if adding
details into this would be useful? Also, the details around reusing
chacha20poly1305 ran me into some confusion. I wasn't sure how to implement
it using just the HChacha and XChacha parts because the description says to
just call into the implementation of chacha20poly1305 in the description of
AEAD_XChaCha20_Poly1305. Is it common for implementations to make the call
directly into a full AEAD implementation or to combine the XChacha with a
poly1305 authentication tag and reference RFC 8439 for that?

*Security*
In terms of the security of the cipher, I believe that the method of
deriving a subkey with the hchacha function provides proper security given
the CSPRNG is generating random numbers properly. I was trying to figure
out if the prepending of 4 null bytes to the front end of the nonce would
create problems to comply with RFC 7539 in terms of having a 12-byte nonce.
More details about this can be found in section 2.3 step 2. Could someone
with a greater understanding evaluate this aspect of the RFC and identify
if it's a cause for concern?

In total, I found that this work is on the right track and is worth greater
evaluation. Specifically, I found it useful for long-term key usage in
instances where rotating keys per message is not always possible. It seems
to meet a unique need that Chacha20poly1305 is not necessarily designed to
achieve.

Thanks,
Kyle Den Hartog

-- 
This communication, including any attachments, is confidential. If you are 
not the intended recipient, you should not read it - please contact me 
immediately, destroy it, and do not copy or use any part of this 
communication or disclose anything about it. Thank you. Please note that 
this communication does not designate an information system for the 
purposes of the Electronic Transactions Act 2002.