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

Andy Lutomirski <luto@amacapital.net> Fri, 30 October 2015 18:48 UTC

Return-Path: <luto@amacapital.net>
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 C9EDD1B30D2 for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2015 11:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 Cl9TIlAXMGIG for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2015 11:48:06 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003: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 7EBAB1B30D1 for <openpgp@ietf.org>; Fri, 30 Oct 2015 11:48:02 -0700 (PDT)
Received: by oiad129 with SMTP id d129so64593055oia.0 for <openpgp@ietf.org>; Fri, 30 Oct 2015 11:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zkqh4v+uLnsUeESbRQFeyvoFdD8c++44GkfyRRKsoaI=; b=tCl/8XT5VE9A9gKteLMw78VHY3NshbhuglO/8tOC1m2vwS6cJcoxUbttI/fK3T638v 2yYKbr5MtJOGq9tXZ0KSLMVvQsFrFRfDYES94EEQSgGM0BQziW7ojRvhnPzaBpR4xPl9 qKzLSO3F6su5YXtl/LEAWh7z8USw0xf27Ys9WWYjxEbHhyxHP5/lUaRni09z+U55SQBY 0gIVP37WxFZX17sVQ1GQ0RZbiD4owtrHjMVwP2lUrGfTbPAI4h9XUXD+Wx5g+CPmulDJ +s50++n/RwujlVq7KsnezkcFivehV2fmTpZ0EpQTTvK1vIacN/wDe+MpkYTIUocvcPRc 0XmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zkqh4v+uLnsUeESbRQFeyvoFdD8c++44GkfyRRKsoaI=; b=IKCELtSz6PZpO+/oIdQoxAdxeEU8iy9r2e6kebVyR4bkXt1vVtlZJojvagb1Ff7TpC KECaH7PA/S/1am/MuuzZYavryOxEV6RLbUMYqFfxlfcVBtRM6YsyOsGdTU7X3kVGM5zz OSUEUoPGEJWvGRKRbjMNK8Edde3qhdi3r+tPARMdJk0jsToitWZtY6xv9flvm1Q3GKjn VmjLp0xf7bYbXjwLGQgZBroJg2y3HArVptmVCXFzRNjPbz7kOVWDF5rJnpwO0C4gq0rl 2kdAO5J0PA+uNMF2I0Gtd4HyUShTH+WGEG8Q0jNqhxTPoMWOUJJMv+1iJVwngHnjDo1v vAdA==
X-Gm-Message-State: ALoCoQkrnswS9v0R5xqvbqpSyxPfDv1GeBV/3YWK1GMk7a5w5i5yAof+bMaf7zYVnucKqKqoDUkS
X-Received: by 10.202.53.136 with SMTP id c130mr6651942oia.116.1446230881711; Fri, 30 Oct 2015 11:48:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.205.216 with HTTP; Fri, 30 Oct 2015 11:47:42 -0700 (PDT)
In-Reply-To: <20151030183223.35630603F0@jupiter.mumble.net>
References: <87twp91d8r.fsf@alice.fifthhorseman.net> <20151030183223.35630603F0@jupiter.mumble.net>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 30 Oct 2015 11:47:42 -0700
Message-ID: <CALCETrULywQ-14gjnEgcbtO3zJoK5PhbiE953eZXO+r108eFHg@mail.gmail.com>
To: Taylor R Campbell <campbell+cfrg@mumble.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/oVjBgQo-rVHfz1iuckA75shslNw>
X-Mailman-Approved-At: Sun, 01 Nov 2015 07:51:57 -0800
Cc: openpgp@ietf.org, "cfrg@irtf.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 18:48:08 -0000

On Fri, Oct 30, 2015 at 11:32 AM, Taylor R Campbell
<campbell+cfrg@mumble.net>; wrote:
> This requires only O(log n) working memory to compute the Merkle tree
> -- it takes a single pass over the whole input.
>
...which reminds me:

As far as I know, everyone thinks they know how to do a Merkle tree
for things like this, but there doesn't seem to be a credible
standard, and there are at least two modern examples of doing it
wrong: Amazon's Glacier hash and (unless it changed) Bittorrent's new
Merkle tree.

Should CFRG consider standardizing a transport format for hash tree
verifiers (or proofs or whatever they're called) and for a large blob
that can be used to efficiently generate the proofs (essentially some
kind of serialized tree)?  The Sakura construction could be a good
starting point.  If I were designing such a standard, I would be
extremely hesitant to start with SHA256 or similar because of the lack
of personalization, whereas Sakura (and maybe BLAKE2) doesn't have
this problem.

Sadly, Sakura doesn't seem to be officially blessed yet.

--Andy