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

Björn Edström <be@bjrn.se> Sat, 31 October 2015 09:20 UTC

Return-Path: <bjorn.edstrom@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 B56621A2182 for <openpgp@ietfa.amsl.com>; Sat, 31 Oct 2015 02:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 c5pxCUTut_ya for <openpgp@ietfa.amsl.com>; Sat, 31 Oct 2015 02:20:53 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 9312C1A212A for <openpgp@ietf.org>; Sat, 31 Oct 2015 02:20:53 -0700 (PDT)
Received: by pacfv9 with SMTP id fv9so101057000pac.3 for <openpgp@ietf.org>; Sat, 31 Oct 2015 02:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=DEr72vcBgTxDVytE/ejqomrO8ot9jHxhyD9MunCoM9Y=; b=tBrBtGLpowU+y0nsZZlByuLpXZv5MQAiF2C3CcbpgsOrukGUmKW8AmhWiqA/TDOGsL oFkMiYLWcO1AnSbfvoDRP585zHet9MRf/4CEKu+cuoimf1vT+SiJlRomTjCCTMKMjD4d 4hpdrXV7LnfaavdTdchJaPPfcwZ1HtoAaMbAjhSji9uaacoyIhbG9R0a4SGVk8QrH76a xtQPzW4pIH95OLyXghfCUUQZtPJD2bkm8VoS9ITxtxzi2v70Iv7ELydllJp715MB2D0s U2KJXN0IuBtrUB7nwjyNALP3RfxmFeXVrQxFHoaPq8/usm36QfyWhPjR0tUJcGGPxOD+ fbeA==
MIME-Version: 1.0
X-Received: by 10.66.124.135 with SMTP id mi7mr14249569pab.86.1446283253279; Sat, 31 Oct 2015 02:20:53 -0700 (PDT)
Sender: bjorn.edstrom@gmail.com
Received: by 10.66.156.132 with HTTP; Sat, 31 Oct 2015 02:20:53 -0700 (PDT)
In-Reply-To: <87twp91d8r.fsf@alice.fifthhorseman.net>
References: <87twp91d8r.fsf@alice.fifthhorseman.net>
Date: Sat, 31 Oct 2015 10:20:53 +0100
X-Google-Sender-Auth: JOiG9IHvAaC4-B5oy9zVHVOI_1w
Message-ID: <CAA4PzX28EJ_Rtntn05vfP0bzBz_PNyDA8Q4r-XGm0H9D7XHirw@mail.gmail.com>
From: =?UTF-8?B?QmrDtnJuIEVkc3Ryw7Zt?= <be@bjrn.se>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/zTrDl-THjPHklhzlEQQaaL8T430>
X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:56 -0800
Cc: openpgp@ietf.org, cfrg@irtf.org
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: Sat, 31 Oct 2015 09:20:54 -0000

On Fri, Oct 30, 2015 at 12:11 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net>; wrote:
> But one of our constraints is the OpenPGP use case that streams
> decrypted data, like this:
>
>  pgp --decrypt <backup.pgp | tar x
>
> It's unlikely that this use case will go away.

Is that constraint really set in stone?

PGP is a complicated system to use and understand for most people and
the more an implementation can do to prevent potential dangers the
better. I think it could be worthwhile of the spec to have security
guidelines for implementers to make dangerous invocations more
difficult.

To use your example, consider the following further examples:

pgp --decrypt --file backup.pgp | tar x

The above is fine. Run two passes over the file, one for integrity,
one for output.

pgp --decrypt < small-backup.pgp | tar x

The above is fine. The file is small and it fits into some predefined
buffer in memory before reaching EOF. Similar to the above: check
before outputting anything.

pgp --decrypt < backup.pgp | tar x

The above is *not* fine, and the user should have to go through hoops
to make it work (for example some kind of --unsafe option, or big
warning pop up box in a GUI application).

In general I think the OpenPGP spec should have more guidelines for
implementors since it's very easy for the user to screw up if the user
is not familiar with intricate details of the system. This is to a
greater extent than other specs, that mostly concern specialists
anyway.

Removing the constraint above, and living in the normal world where
you do 1 pass integrity before decrypting, you can use much more
boring and standard cryptographic constructs, which I personally would
prefer in this case.

Cheers
Björn