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

Bryan Ford <brynosaurus@gmail.com> Fri, 26 February 2016 13:51 UTC

Return-Path: <brynosaurus@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 45BB61A1BA7 for <openpgp@ietfa.amsl.com>; Fri, 26 Feb 2016 05:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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 md62txMLY9fx for <openpgp@ietfa.amsl.com>; Fri, 26 Feb 2016 05:51:40 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 585171A1BA4 for <openpgp@ietf.org>; Fri, 26 Feb 2016 05:51:40 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id x1so31776917qkc.1 for <openpgp@ietf.org>; Fri, 26 Feb 2016 05:51:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ADrf2eiLCxCBgCYsZHewUm8nsGniED9tEGAKc3SWjwE=; b=l2rqQp2qqJ39fSdpBHjA7iycsWB3iuLTztdLg4bepne7zcxzds6Ymc99dTT5vAnOQc szcpVMIzL7R5aowbMSeFL4iA7QPrt+a7wEJ6P1nY1tj79aPs/50lRR3hBV5mqBOV/GoO Jje8cb+x4reLFQOrviXH2ZOzr2fUTFr4Df3GZyjbTBvuVlgfZuclv8KaBAdCnX/lR9vD RilJpBTo2cOusBssNq0328rYmdCDUHxrfXdiNU3y7x0Nl/rJ1TQMRLWTyYqCfYpiFZXf ILRWjl1r/FSwIDTL15J/MvlOf08wq1slmZqLqEM0U3iDdouBDzkCHcbtM55S9l5Nflxa yGMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ADrf2eiLCxCBgCYsZHewUm8nsGniED9tEGAKc3SWjwE=; b=hTDEf7XRO763FWLSwBmaDcVBwbYb4PjqK4KObUftLhotdsh+HFA4vGzhb6lwMoGrIg Hlu1DUYmhqnEC2lEQB9ly+eqkcL9+0BJ7JOtTBeKS/W9loHQovLySNNw7x+rzxhEJU2O Op4NLeM4Z6PgCmp2zAFMAN/sGprCm17uAk+GV4skCWGtIEwhX4R74DTf0zH5Y9YLiZrp YlIkSkdQgAYBkQCZgIrFnYm4UynKX0wUVjfiMloWDIlPXLYtq3u33sCmhs3VBOPe9G6g VcH3ppFBJiotSYjFeDrDIuriKgcPX3fyMkWJQHHfdpI7aCPNRUCp0R3f2S+e8xELgrnO SeTw==
X-Gm-Message-State: AD7BkJI9Qi7vQURwOILcVRE7cqAqYGmgmS/3cMEmxxVb4WICrJdN7afiTovqSZ6iChYROg==
X-Received: by 10.55.82.85 with SMTP id g82mr1942470qkb.107.1456494699534; Fri, 26 Feb 2016 05:51:39 -0800 (PST)
Received: from [10.0.0.200] (173-9-75-145-NewEngland.hfc.comcastbusiness.net. [173.9.75.145]) by smtp.gmail.com with ESMTPSA id n35sm5350663qgn.10.2016.02.26.05.51.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 05:51:38 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_18834A69-CACF-4138-9C5B-770A3B0B9E08"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Bryan Ford <brynosaurus@gmail.com>
In-Reply-To: <6CC794D8-3BE2-454C-A53B-AAA67E2DE84D@gmail.com>
Date: Fri, 26 Feb 2016 08:51:47 -0500
Message-Id: <17F4B1B2-F2E4-441D-9B2E-066293FBD860@gmail.com>
References: <87twp91d8r.fsf@alice.fifthhorseman.net> <CAM_a8Jy-ZoGJ3qTgN5PFA2ZKnbtSy5GWhWhUeF2NHYgWUQ0zYA@mail.gmail.com> <3A98EA92-0C2F-46A7-8D06-880FC83CB110@gmail.com> <56BBB13B.3000507@googlemail.com> <6CC794D8-3BE2-454C-A53B-AAA67E2DE84D@gmail.com>
To: Nils Durner <ndurner@googlemail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/xLh3QF0t3aUSVOTSaw1gAm6nmek>
Cc: openpgp@ietf.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: Fri, 26 Feb 2016 13:51:42 -0000

P.S. Wherever ‘reputable’ appears in the message below that should have said ‘repudiable’.  Thanks Apple for spelling auto-corrections that completely obliterate the technical meaning of sentences… :(

On Feb 23, 2016, at 12:36 PM, Bryan Ford <brynosaurus@gmail.com>; wrote:
> On Feb 10, 2016, at 1:52 PM, Nils Durner <ndurner@googlemail.com <mailto:ndurner@googlemail.com>> wrote:
>> Hi,
>> 
>>> To be clear, there are two separate use-cases, each of which make
>>> sense without the other and require different technical solutions (but
>>> could also make sense together):
>>> 
>>> 1. Streaming-mode integrity protection:
>>> 
>>> [...]
>>> 
>>> To achieve goal #1 properly, it appears that what we need is not only
>>> a MAC per chunk but a signature per chunk.
>> 
>> Different ideas:
>> 
>> 1. asymmetrically encrypt and sign the MAC key, make this a new packet
>>   type to be prepended to the symmetrically encrypted data
> 
> By this, do you mean just write one asymmetrically encrypted-and-signed MAC key at the beginning of the stream, followed by a bunch of records that are only MAC-authenticated with that symmetric key?  
> 
> This would appear insecure to me, at least in the case the stream is encrypted to two or more recipients.  Say Alice signs-and-encrypts a stream to Bob and Charlie.  Bob takes Alice’s encrypted-and-signed MAC key record, then uses the same MAC key to construct a completely different stream of actual content (all of whose MAC records verify just fine) and sends it to Charlie, claiming that it’s from Alice.
> 
> Maybe this is only a problem in the two-or-more-receivers case, but even if so it makes me nervous.  If PGP had a reputable, non-signing sender-authentication mode for 2-party communication only, then it might make sense for an asymmetric “repudiable authentication record” to be followed by a stream of MAC-authenticated records. But that seems like a fairly different protocol (or at least a fairly different mode).
> 
>> 2. derive the MAC key from the symmetric encryption key, sign it (but
>>   do not store it) and make this a new packet type to be prepended
>>   (thus saving the asymmetric encryption from #1)
>> 3. use an authenticating sym cipher mode with intermediate
>>   authentication tags, with the symmetric key asymmetrically signed
>>   (like #2)
> 
> Assuming I’m correctly understanding that in cases #2 and #3 also just have one asymmetric record at the beginning of the stream, it seems like the same considerations apply as with #1.  Perhaps OK for 2-party repudiable authentication, but not if we need to retain the signed-message semantics that PGP currently provides especially in the multiple-receiver case.
> 
> Cheers
> Bryan