IETF Logo Mail Archive

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

James Cloos <cloos@jhcloos.com> Tue, 07 October 2014 17:28 UTC

Return-Path: <cloos@jhcloos.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343311A7028 for <cfrg@ietfa.amsl.com>; Tue, 7 Oct 2014 10:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.787
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bN0FMQfJdyn for <cfrg@ietfa.amsl.com>; Tue, 7 Oct 2014 10:28:52 -0700 (PDT)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6321A7021 for <cfrg@irtf.org>; Tue, 7 Oct 2014 10:28:52 -0700 (PDT)
Received: by ore.jhcloos.com (Postfix, from userid 10) id DF3E81E2C1; Tue, 7 Oct 2014 17:28:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1412702931; bh=CQU8S+0Nm/A3GKOxpyurq3H1dzSotR4oaayvDoZi55w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iAlsPNOXGyYqvMp/BO8Xb8IMo8CcvXlrBzssVa69yyhXhecPUOonHBBE126Ps3azm vCf+GJRxhPeIL4SWVIdFzmRQO14MRdTmAoUFzkW1WIFl890N9S0k8TzQ8zMX4mCYRv /vUYl8qCgLV1zNa/nwZVJq5JbK/SlvF8CBqGzwAM=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4AC2860023; Tue, 7 Oct 2014 17:26:17 +0000 (UTC)
From: James Cloos <cloos@jhcloos.com>
To: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com> (Yoav Nir's message of "Tue, 7 Oct 2014 19:49:08 +0300")
References: <542D48CD.9060404@isode.com> <m3k34clwkt.fsf@carbon.jhcloos.org> <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2014 James Cloos
OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Tue, 07 Oct 2014 13:26:17 -0400
Message-ID: <m38ukrkczq.fsf@carbon.jhcloos.org>
Lines: 26
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:28:141007:ynir.ietf@gmail.com::3oXmSK42ZCWhaPiU:000000000000000000000000000000000000000004vgXf
X-Hashcash: 1:28:141007:cfrg@irtf.org::sI693B0KLk+uFseF:000sUp/F
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PDSdbBbcEb2tUZgkhe1042thsTY
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 17:28:54 -0000

>>>>> "YN" == Yoav Nir <ynir.ietf@gmail.com> writes:

YN> The 96/32 split is dictated by the recommendation in RFC 5116.

YN> Neither regular IPsec nor regular TLS need this, but multi-sender
YN> IPsec (GDOI) and multi-sender DTLS can benefit.

Yes, I read all of the prior discussions.

My argument is that 96/32 should be limited to those multi-sender
environments.

The RFC can spec 64/64, and then note that the upper 32 bits of the
counter can be initialized to something other than 0 whenever more
than 64 IV bits are required.

Just like it should mention that when not using reliable transports like
tcp and when the extra data includes any kind of a packet/frame number
which has a consistent function to the chacha counter, the receiver can
recognize missing packets and decode what it does get by basing its
chacha counter on said (authenticated) extra data.  Which would allow
dtls to avoid retransmission for things like rtp.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

v2.23.0 | Report a Bug | By Email