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

James Cloos <> Mon, 06 October 2014 21:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 091761A6FD6 for <>; Mon, 6 Oct 2014 14:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.787
X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XJhL6x9i5UNn for <>; Mon, 6 Oct 2014 14:27:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31FAB1A8A44 for <>; Mon, 6 Oct 2014 14:27:12 -0700 (PDT)
Received: by (Postfix, from userid 10) id 6412B1E273; Mon, 6 Oct 2014 21:27:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ore14; t=1412630830; bh=a6KLKvG29W/4t23eXulrGqeuXCMq4QxxtP2IAHVemVU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nVwOqbhx/7vRZKC/8Op1GKJzVLXj+P9abX8cOyI3+lBwA1Gfx2s9alClZvWtwI9+v bxzqxd2fG6/BMxk6iFWr4jJ0NjWVzhVaAuTm93hcMW7Gr3A7UmdtnBXhXFdLeoVRRP 8MLIqQHoiALqclU4Ym0iK0cgRVGAYaZ1LyzSPNBc=
Received: by (Postfix, from userid 500) id ECF3F60023; Mon, 6 Oct 2014 21:25:38 +0000 (UTC)
From: James Cloos <>
To: <>
In-Reply-To: <> (Alexey Melnikov's message of "Thu, 02 Oct 2014 13:45:01 +0100")
References: <>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)
Copyright: Copyright 2014 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Mon, 06 Oct 2014 17:25:38 -0400
Message-ID: <>
Lines: 30
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Oct 2014 21:27:14 -0000

[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

James Cloos <>         OpenPGP: 0x997A9F17ED7DAEA6