Re: [TLS] Pull Request: Removing the AEAD explicit IV

Brian Smith <> Mon, 23 March 2015 02:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7544E1A8773 for <>; Sun, 22 Mar 2015 19:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBI91zuwe6IR for <>; Sun, 22 Mar 2015 19:10:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35C6B1A8772 for <>; Sun, 22 Mar 2015 19:10:57 -0700 (PDT)
Received: by oier21 with SMTP id r21so130029759oie.1 for <>; Sun, 22 Mar 2015 19:10:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Om4xy2KOTMHiekQxx1sA4PNaiZ1n9B88PNtNpL4vrYM=; b=BaSJMzz80zN9K5aIP7lTNshoVfxUbeqv4f1Dib+XW260HRt0HXYM/lZaRHXaZInWDb RR9QYtH2Qgvk6SVohs44HQK42QXZ/9erw3hBDRMM8u6WkLvpfXixYF4ZYZu+/cNGyYrL zzEp1sbRt79rPRcYZcGVMT+hCsxnWenbF1KkfZrNEuYgL2e2PJrM1HS9y5xLAuKKW8M2 QHL5v+07PFNw0UJsCj+9JtBVHZl7PUMo53/DoS9KKBVK3viQUPOnwZcUqsN6uxHScbRr +6LyZZlBmAGo+5xmKyZhjsnPl4O40xczWMBQA+2j6w1CxWy+P2O1EjHf8nVLdoomQwEB fxAA==
X-Gm-Message-State: ALoCoQneBxw62P3/G4YN/fZptnPyQSGBqgM3LEgkb5/vkL+NifsBXh7RsReGIANFsDgH7oG1atoa
MIME-Version: 1.0
X-Received: by with SMTP id g6mr30261698oej.7.1427076656675; Sun, 22 Mar 2015 19:10:56 -0700 (PDT)
Received: by with HTTP; Sun, 22 Mar 2015 19:10:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sun, 22 Mar 2015 16:10:56 -1000
Message-ID: <>
From: Brian Smith <>
To: Eric Rescorla <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Adam Langley <>, "" <>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2015 02:10:58 -0000

Eric Rescorla <> wrote:
> Adam, Brian, what would you think of XOR rather than addition?
> E.g., generate a per-connection value V and then do:
> Nonce = Seq XOR V?

Would the sequence number be logically the same size as the nonce (128
bits or 256 bits), or would the spec will forbid sending 2^64 or more
records under the same key? Either solution prevents the need to worry
about the record number overflowing, but my answer depends on which
approach is chosen.

The advantage of XOR is that it is easy to implement correctly,
because mutli-machine-word XOR is easier to implement than
multi-machine-word unsigned integer addition with wraparound during
overflow. However, XOR is also easier to implement *wrongly* without
anybody noticing, by only doing the XOR for a single machine word
(e.g. only the lower 32 bits on a 32-bit machine). It's not so
practical to do a conformance test that sends/receives 2^32+1 or
2^64+1 records..

It seems harder to implement addition wrongly without anybody noticing
because all of the overflow cases should be triggered during interop
testing and thus any bugs found and corrected. So, without knowing the
answer to my question above, I prefer addition.