Re: [TLS] ChaCha and IVs

Dr Stephen Henson <lists@drh-consultancy.co.uk> Tue, 04 March 2014 18:30 UTC

Return-Path: <lists@drh-consultancy.co.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65A1A02CE for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 10:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no
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 3i7zqp7Pt8sw for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 10:30:13 -0800 (PST)
Received: from claranet-outbound-smtp08.uk.clara.net (claranet-outbound-smtp08.uk.clara.net [195.8.89.41]) by ietfa.amsl.com (Postfix) with ESMTP id BA56A1A01F1 for <tls@ietf.org>; Tue, 4 Mar 2014 10:30:11 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:12056 helo=[192.168.7.9]) by relay18.mail.eu.clara.net (relay.clara.net [81.171.239.38]:10465) with esmtpa (authdaemon_plain:drh) id 1WKu6N-0001v4-S5 for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Tue, 04 Mar 2014 18:30:03 +0000
Message-ID: <53161BA7.3070405@drh-consultancy.co.uk>
Date: Tue, 04 Mar 2014 18:29:59 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: tls@ietf.org
References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TGA3gngMcdCZdAE4Fj_RdX3ueD8
Subject: Re: [TLS] ChaCha and IVs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 18:30:16 -0000

On 04/03/2014 17:57, Nikos Mavrogiannopoulos wrote:
> On Tue, 2014-03-04 at 11:53 -0500, Stephen Kent wrote:
> 
>> An algorithm implementation submitted for FIPS evaluation 
>> must be independently evaluable 
> 
>>From the wording I don't understand how this is relevant to your point
> for nonces. Could you elaborate?
> 

In the case of AES-GCM there are some requirements for how the IV is generated
for FIPS (and FIPS 140-2) compliance.

It has been a while since I looked at this in detail but from memory it
effectively meant the explicit part of the IV had to be generated by the module
itself on encrypt (various schemes were permissible). An application couldn't
specify an arbitrary value which would seem to preclude the use of the sequence
number directly.

So on encrypt you'd typically call the module to generate the explicit part of
the IV and then use that generated value in the protocol (for TLS copy it to the
explicit IV part of the record).

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.