Re: [openpgp] [Cfrg] streamable AEAD construct for stored data?

Natanael <natanael.l@gmail.com> Fri, 30 October 2015 13:18 UTC

Return-Path: <natanael.l@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E381B2C40 for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2015 06:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable
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 Q8ZVqCz7wgJO for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2015 06:18:15 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 8690C1B2C39 for <openpgp@ietf.org>; Fri, 30 Oct 2015 06:18:14 -0700 (PDT)
Received: by wicfv8 with SMTP id fv8so10607731wic.0 for <openpgp@ietf.org>; Fri, 30 Oct 2015 06:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8bxE7WQenuJqupi5pxYa3SXHYq+Hiu3Yr52Bbn/C2VY=; b=o28Md3cNX36AUzPDBejHXY0hKdXb4JLZ6Wo90Tcuceku8PLyDjKVIt62DmnJljGqEb LmmO9yup4t8dapFVLvrhl32lQtQTC9X+KzLX/NmJtSMeZnmy3AVJV2qiBZ71DNg3lbge tcHCcs8RO0+cV3Fe5vqiTKIaii5jjtUXZd60DBO0XiBLxZL/VwvSHQe9gS0XsUC31YSW HSrEpbkzeUpy18tRE3yy86/ZL8+Q7VBlSPqezF9Pg0XEUHPZUZoXziYwbV1w57UwZl5z yCV/01ESMC5iT9qHafUvqC8s9Y4zt2xuCJaGlmP5NZpcbi/Mac8Axoe/qyTNo61d4tPL 6XUQ==
MIME-Version: 1.0
X-Received: by 10.194.187.41 with SMTP id fp9mr9651844wjc.14.1446211093158; Fri, 30 Oct 2015 06:18:13 -0700 (PDT)
Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 06:18:12 -0700 (PDT)
Received: by 10.194.175.33 with HTTP; Fri, 30 Oct 2015 06:18:12 -0700 (PDT)
In-Reply-To: <CACsn0cm=t3XCTu8O7bxpB79n-ksodZOEGsChspvD25V_4xjhQw@mail.gmail.com>
References: <87twp91d8r.fsf@alice.fifthhorseman.net> <CAAt2M19s-grQ9No9kAhBDCKKTw6oj9wHdiU5XuGjLO5Y8B87dA@mail.gmail.com> <CACsn0cm=t3XCTu8O7bxpB79n-ksodZOEGsChspvD25V_4xjhQw@mail.gmail.com>
Date: Fri, 30 Oct 2015 14:18:12 +0100
Message-ID: <CAAt2M19RBjJCaQ8oAqDa_58gG79v+qNshA8xzWNnqFfNHrwnxQ@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb03a6e7a611305235242c4
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/kX-zpBZ9gbmUSmgP44TLMGGugC8>
X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:58 -0800
Cc: openpgp@ietf.org, cfrg@irtf.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [openpgp] [Cfrg] streamable AEAD construct for stored data?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2015 13:18:16 -0000

Den 30 okt 2015 13:30 skrev "Watson Ladd" <watsonbladd@gmail.com>;:
>  On Oct 30, 2015 8:25 AM, "Natanael" <natanael.l@gmail.com>; wrote:
>> [...]
> Use authenticated encryption so no signatures are required. Detached
signature verification is used for large public messages already: no
streaming needed.

I'm not sure if we read the requirements differently. He asked for
immutable signed files, as in that an AEAD authentication key is
insufficient because the other recipients all have the same key and can
substitute the ciphertext. There's an explicit requirement that the
capabilities of the sender and (potentially multiple) receivers are
different.

Yes, the signature would fail if combining standard AEAD with a full
ciphertext signature and one receiver modified the ciphertext, but see the
reasoning for why it is necessary again - by the time the failure is
detected, the software that's performing the streaming decryption and
processing may already have taken some undesired action, or might fail to
cancel a future undesired action (by not deleting the resulting plaintext).
Preemptively preventing mistakes done by the client software.

It isn't just AEAD, it is seekable streaming AEAD with per-block
verification of immutability. Allowing you to look up any block
individually and confirm *that block* hasn't been modified by anybody but
the original sender.

Imagine for example an encrypted video or a large archive of files being
sent to multiple receivers. With AES-GCM and a signature at the end, you
either decrypt and verify everything before viewing or you decrypt just one
part and accept that another one of the receivers may have tampered with
your copy of the video/files (if it for example is stored on a NAS).

Or worse, the software parsing the plaintext might have an exploitable bug,
which may then already have been exploited when the signature verification
fails, so that even if the decryption software rolls back everything it did
then you now have malware on your system anyway.

The other option is of course the sender creating multiple ciphertexts with
separate keys for every recipient. Very much not ideal for large files.

> > To solve B what you need to do is something like signing a list of
ciphertext hashes/authentication tags.
>
> The idea below demands conditions beyond MAC security.

Feel free to explain what conditions those are. I'll happily admit I'm just
a cryptography novice, I'm willing to learn why this might be flawed or
insufficient.