Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt

[Yoav Nir <[e-mail]>]

Hi, James

The 96/32 split is dictated by the recommendation in RFC 5116. While any sane use of symmetric keys will never use the same keys for either 2^96 messages or 2^64 messages, being able to safely split the range of acceptable nonces is an advantage. Neither regular IPsec nor regular TLS need this, but multi-sender IPsec (GDOI) and multi-sender DTLS can benefit.

As it is, the current TLS 1.3 draft defines AEAD ciphersuites as those described by RFC 5116. So yes, it’s possible to decide on a 64-bit nonce and state clearly in both this draft and the draft for ChaCha20-Poly1305 for TLS that we’ve decided to ignore the recommendation in 5116, but I don’t think that’s a good idea.

Yoav

On Oct 7, 2014, at 12:25 AM, James Cloos <[e-mail]> wrote:

> [I thought I sent on this subect weeks ago, but I cannot find it in
> the archives, ... -JimC]
> 
> I have to object to defaulting to a 96/32 split.
> 
> The rfc should specify Dan's 64/64 split as default, and only offer
> 96/32 as an option.
> 
> Chacha isn't only useful for in-flight encryption.  One should not
> have to bother with multiple keys or IVs to encrypt large files.
> And 128 Gigs is not all that large for things like backups (tar,
> cpio, et cetera), disk images, some AV files and the like.
> 
> It is very reasonable to presume that larger and larger files will
> become more and more common as the storage devices sizes and demand
> for higher resolution media files each continue to escalate.
> 
> The RFC should be a valid reference for all potential uses of chacha.
> 
> Even in the IETF, OpenPGP encrypts files at rest.
> 
> Secsh should continue to use 64/64; OpenPGP and SMIME should add chacha
> with 64/64; I would prefer 64/64 for TLS.
> 
> But if IPSEC insists on 96/32, that should be an option, not the primary
> scenario.
> 
> -JimC
> -- 
> James Cloos <[e-mail]>         OpenPGP: 0x997A9F17ED7DAEA6
>