IETF Logo Mail Archive

Re: [Cfrg] Discuss/standardize Preview extension to AEAD abstraction?

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

Return-Path: <brynosaurus@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035E81ACE68 for <cfrg@ietfa.amsl.com>; Fri, 26 Feb 2016 08:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 2uKuwCs1q0uG for <cfrg@ietfa.amsl.com>; Fri, 26 Feb 2016 08:40:02 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (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 8D1191ACE6C for <cfrg@irtf.org>; Fri, 26 Feb 2016 08:40:01 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id y9so70057191qgd.3 for <cfrg@irtf.org>; Fri, 26 Feb 2016 08:40:01 -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=XltrqLFKhIJoYiGNIVG9JvQ9+Dcyfl8nE1WdX9vhdzo=; b=k/ig+XayuJcK/kFgMnRrpeWODLCg0Gkn9Kzs8Xso2HpdyTM411HdPEEMCgWd1Hl76a p9vd7Udu+RsphbIPi4jT6R4t9v7Lf6bI6ROeb90wTXRhzDq9EVRdI1deursxPv42g0Ig LL+gM+fQjejfYtHMwlgP27sVrVHGGAm18k1JpDRF/W1lqX9F0BQ2vwtMmpEmfoaqwy7e OEFA6PmxBlIv8AvELh3I+Yg9ySncSYSfpaa0sjFpRTE41nQfA5qi3yT3LBA5TeIUaQOM CQ+R1Gl0tJieGX+EKLauCcplDCeQp5BTzcUhm4fMJ7cTMmuJyzxXuEPgWbr4OglOaF25 q0bQ==
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=XltrqLFKhIJoYiGNIVG9JvQ9+Dcyfl8nE1WdX9vhdzo=; b=B8VOBCn5LqM+ywMOUcg0TnORapXM1ST2bXPvdha90cW9Tffe7vmxGHvfgihSe9EIHh 2BChHEmQszjC5Fxb/TkcLatC4ERyYCxbxOEEIEcOSA6yO7D76fNg/vo15eyQDhr/1ebh rKBbF26923yU+l4yZ71YSp3fVWMK7ugERfLM+Cj5/+MmUucNGLXwL2Dw7NfdrNslnAUX jobBFfTNIn+Pt4nJlZCM1lw60Kdy9ese9oeC5kizPv+W9a8/+3ujX2N7FrMkMg2549/M fX8qHvi7SGWuOAu0vOx+3zmJujTo4DLmZ98L3lAsjJmQ5ev4Y9mA80P7YPgKV3BRVCrM 0skg==
X-Gm-Message-State: AD7BkJJ+j6sw+WQsC+pRoRVqaPV/roSrkzsOq98hp0g+/P1+yW2SfD2On2wFbHzsXBBeXQ==
X-Received: by 10.140.251.70 with SMTP id w67mr3159180qhc.99.1456504800623; Fri, 26 Feb 2016 08:40:00 -0800 (PST)
Received: from proz.wireless.yale.internal (nat-130-132-173-12.central.yale.edu. [130.132.173.12]) by smtp.gmail.com with ESMTPSA id n48sm5599439qgd.38.2016.02.26.08.39.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Feb 2016 08:39:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8273D9C9-3E2D-46AA-A9C7-440833B80D4E"; 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: <na6foq$s6m$1@ger.gmane.org>
Date: Fri, 26 Feb 2016 11:39:57 -0500
Message-Id: <B3F3C60C-8294-48D8-A572-59164DC5DD71@gmail.com>
References: <8F1E4FEC-1FED-491B-BC6A-B00C27864414@gmail.com> <alpine.BSO.2.20.1512031055120.12629@natsu.mindrot.org> <21946846-1BFB-4170-8E8E-EC6A00BF3AED@gmail.com> <na6foq$s6m$1@ger.gmane.org>
To: Alex Elsayed <eternaleye@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/DYC83EQUUJzJavnqNrbofTYgXiY>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] Discuss/standardize Preview extension to AEAD abstraction?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Fri, 26 Feb 2016 16:40:04 -0000

Hi Alex,

On Feb 19, 2016, at 2:20 AM, Alex Elsayed <eternaleye@gmail.com> wrote:
> On Fri, 04 Dec 2015 11:53:02 +0100, Bryan Ford wrote:
> 
> <major snip>
> 
> Apologies for the (very!) late reply, but was off-list for quite a while.
> 
>> Is there anything seriously
>> problematic or unsound from a crypto perspective about such an APEAD
>> interface extension or feature, aside from the well-known risks
>> associated with any use of (“previewed”) data before it’s been
>> integrity-checked?
> 
> One particular problem is that APEAD is hard-incompatible with MRAE - in 
> order for an AEAD to satisfy MRAE, every bit of the ciphertext must 
> depend on every input bit from (nonce, ad, pt). As a result, "previewing" 
> some prefix is infeasible for the exact same reason as MRAE and "online" 
> AEAD being disjoint (Hoang, Reyhanitabar, Rogaway, and Vizar have a 
> fascinating paper on this - https://eprint.iacr.org/2015/189).

That concern occurred to me as well.  But in subsequent discussion with Philipp (co-author of one of the recent misuse-resistant schemes - https://eprint.iacr.org/2015/999), we realized that it *is* possible to create an APEAD scheme that’s also misuse-resistant.  

But we also realized that for some of the purposes motivating the APEAD property - particularly hiding sequence numbers in out-of-order transports such as DTLS or IPSEC - just using a misuse-resistant scheme and transmitting the sequence number inside the encrypted payload presents a reasonable and perhaps conceptually simpler and cleaner alternative to the APEAD approach.

> However, this does leave some options regarding length-hiding on the 
> table.
> 
> For one, given an AEAD based on the encode-then-encipher paradigm with 
> variable \tau, one can increase the length of the verifier arbitrarily. 
> This permits essentially padding each message to any extended length and 
> gaining that length as additional integrity protection.

I’m not sure I follow the details of this suggestion - but definitely agree that in general that there are several reasonable approaches to length-hiding, with or without the APEAD property.

Cheers
Bryan

> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

v2.23.0 | Report a Bug | By Email