Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

Adam Langley <agl@imperialviolet.org> Thu, 19 January 2017 17:15 UTC

Return-Path: <alangley@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CE4129447 for <cfrg@ietfa.amsl.com>; Thu, 19 Jan 2017 09:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5RD1SI75VVUV for <cfrg@ietfa.amsl.com>; Thu, 19 Jan 2017 09:15:00 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6126412942F for <cfrg@ietf.org>; Thu, 19 Jan 2017 09:15:00 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id v96so42738784ioi.0 for <cfrg@ietf.org>; Thu, 19 Jan 2017 09:15:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=KreUggLNyH6yWtECTyHTLka554sS77vuk2At/kRKMks=; b=WgnUysV8BX4ZpQoc8SVQRgJq0hiRnL6YitBOCSaRUAvMD7CdM/hiw2C1YthIwamHm2 XTUJ7w6J9ylK289LUMOO8a1yjdik2ge5gXPpYlib+f9rMfZpjkTlCpSlT04Mb2Y6+e2I ZDK2e/3j6X/f5QqAjfxATzDFbjqhGY2PNW+Golrha2q6FbwSEzDYAeMwZ3TExLznkK1c +QD9R518MxqtARw/0LpiyzFBaczIty5pl+hGriTJTApT0c1ACBQiYA647U2Arfe8OdfR 79HdH8IUHTH8bEvo5dYlNSRZqvx6JFyVhcrGCCTWJBFmrMA+9bujZ32pUIFMbwN4D5vi 3r5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=KreUggLNyH6yWtECTyHTLka554sS77vuk2At/kRKMks=; b=DlHzvodnAzMmrt8J8D000McVvVhIbCazxQM8eKNHSsPMj06Ge5t1a3f6vpsaGjZjsl Ph76YxuAiIAYXsUG6jrOIuLSdTAubL1cUhdgN0tQLY+TxQtlHE1+p39jzT24q9sR3Y5K vNZOQ7SOnORn7vuRWDM3vth1p+OfiLVfmC16DnJHOdiaSBxwFYhVdoJEgm5eYzaEdZ0I tOPm6u9MH3ksrP9/nBOsviG9tgCWmmhIv3T8InJhynSpBu35hGpD+ic3WPdOavP2nlJS +J5iCL8fFbGkpF9Pwkg+qmB+c9WFshgyorevuPvzgPKMqMOeLUjzXehexpa4Qjnl17mv PHyA==
X-Gm-Message-State: AIkVDXJuk37T+RmBWJfpJgVKJDVqSu/oZ5mN1oEN2zdYo6XdxZFFq6pWgxzTGUvF7rRGgtnH3X7hAaptk9Ec2g==
X-Received: by 10.107.141.80 with SMTP id p77mr9569035iod.97.1484846099598; Thu, 19 Jan 2017 09:14:59 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.144.4 with HTTP; Thu, 19 Jan 2017 09:14:58 -0800 (PST)
In-Reply-To: <D4A64D7D.58413%john.mattsson@ericsson.com>
References: <148476063144.1938.2025448065922517313.idtracker@ietfa.amsl.com> <D4A59386.5822C%john.mattsson@ericsson.com> <CAMfhd9XQSi17mLKE1AFUa2ZG8nJq4MfccMomFm+0ctsKm_Ab9w@mail.gmail.com> <D4A64D7D.58413%john.mattsson@ericsson.com>
From: Adam Langley <agl@imperialviolet.org>
Date: Thu, 19 Jan 2017 09:14:58 -0800
X-Google-Sender-Auth: q544l9wRDgBoHlKz1dDhgLugbLw
Message-ID: <CAMfhd9VvjGrFCnkKyfOFKDCjajnLkUfz5_vntTKqvVL+mR_J7g@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/m5iS3Y-C8FtVN7HFBUgCJGFD9CM>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 17:15:02 -0000

On Thu, Jan 19, 2017 at 2:19 AM, John Mattsson
<john.mattsson@ericsson.com> wrote:
> - The use of one-time authentication keys has the benefit that it
> mitigates Fergusson’s authentication key recovery attack on GCM in the
> two-party case. In case of multicast the attack remains (but significantly
> restricted). This makes GCM-SIV a little bit more suitable for truncated
> tags than GCM. I think these advantages should be mentioned.

Thanks. I've added a TODO locally to think about this. I'm not sure
that we want to mention truncating authentication tags because that
seems contrary to the general thrust of robustness here. I'll see
whether I can say something about the advantages of the one-time
authentication keys in general however.

>>So I actually quite like that the tag is at the end of the message
>>with AES-GCM-SIV because it makes it harder to do what I think is the
>>"wrong" thing.
>
> I would agree with you if placing the tag last actually improved anything,
> but the fact is that GCM-SIV actually forces processing of unauthenticated
> ciphertext by design (a change from GCM). I cannot see any security
> benefits with (C, T) compared to (T, C). The only difference I can see is
> that (C, T) increases the latency for decryption on multicore.

I don't understand why AES-GCM-SIV forces the processing of
unauthenticated plaintext. I think we might have different
definitions.

To me, processing authenticated plaintext means that the crypto API
releases plaintext for other processing before it has authenticated
it. It doesn't mean that the plaintext cannot sit in memory during
decryption while the AEAD checks the tag. (Indeed, many GCM
implementations interleave decryption and calculation of the GHASH
value.)

So putting the tag at the end prevents such APIs from being written,
which I think is a benefit.

A second benefit to putting tags at the end is that it's generally
easier to have extra space at the end of a buffer than the beginning.
This is not precise and might be a result of my C/C++/Go-based
environment, but I'm going to claim that a (buf, len, max) pattern is
easier for people to do with in an API than a (buf,
initial-padding-length, len).

In a case where space at the end of a buffer is easier to deal with,
putting the tag at the end is nicer because, otherwise,
encryption-in-place has to write ciphertext blocks 16 bytes in advance
of where it read them. In order to avoid clobbering the next plaintext
block, that has to copied first. I admit it's only a minor problem.

On the other hand, I'm not sure that I see the benefits of putting the
tag first in terms of latency on multicore machines. The AEAD model is
that the whole ciphertext is in memory when the operation is called so
it's as easy to read the tag from the end as from the beginning.

I can see an advantage in cases where the system could start
decrypting while the remainder of the record was still being read. Was
that what you had in mind? At least for multicore machines, I don't
think records should be so large that it makes a difference though.



Cheers

AGL