IETF Logo Mail Archive

Re: [Cfrg] What are the goals of the AEAD bakeoff?

Paul Grubbs <pag225@cornell.edu> Mon, 22 June 2020 16:03 UTC

Return-Path: <pag225@cornell.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B41A3A0E91 for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 09:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cornell.edu
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 dU5pDei2fnXW for <cfrg@ietfa.amsl.com>; Mon, 22 Jun 2020 09:03:00 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 F20BB3A0E69 for <cfrg@irtf.org>; Mon, 22 Jun 2020 09:02:59 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id h23so5895388qtr.0 for <cfrg@irtf.org>; Mon, 22 Jun 2020 09:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=amXA4u93Xj7c2p92xFCA7qqvZ7vaBIMEfHprdI4N6Ps=; b=FY4InP09wmmn8tY+0yAo9iGX8W8mJJClm2nDdniqu9d9KOciwAxH96x+Jy6wOKqzbs hU4Taq0QpFXX62+SDqq7WP+AzWmnFv/fJfo/VCr1MdvGCyu1rGQfWSN947rMA84JzJF8 lwx6hK9s5CZD2B0klWd+I5VWkOe00On29nzgZDzc1JRu+lHCBSmrBzP6M9qMkW+lvr1+ Zr69KmdnmqaKOpKVUy4Fmk1eIaq37PS+U72/0YksZ99LbkFBqen9TA6IQJmFwA6xBhtR 7tpr4F/gvKXicARyPAKt99QgynZPy7HnnJSWoppnWM1dUc09Jz1dg67cBlupHZWG5x4X +PSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=amXA4u93Xj7c2p92xFCA7qqvZ7vaBIMEfHprdI4N6Ps=; b=qZg5aEMIN5i6bQTq8ZRa1yl+CQdVpwdRlDuEJP5o7yKHiCsFVn8HTl+i+MFhxyRNE9 WSvusuSRoq/2WhslOGO671kbmhkfKKUjL16OBdAFymv5+xbN9RH2Fjc18MddHcNTHEh0 EM9e+WMcDjBDQmxvEToshfbbkXo7nDP2OffTdTAk1KwAMV/xHH29f7Fg37SRvEBIWeUl bqxyOBjX78yYoUp3CetqYfz12zn6zXlZGC4wnoIeQu1atYp4eWWasYU4vx6iy2DGrsq5 uMTBncm4LU5inq7WKIN1GZws9zfMT8TgqA/+Nwh5+NymbQ+zPMoWHJFww7+9ttxQxNDo cdfw==
X-Gm-Message-State: AOAM533HVaXP5E4FMDUQ8Ib0jnU3Yzayr4ZE8CvO5KSv0edntBZ61Ebc k0aYKPFGaNTdlXbFAT/6PBJjOKGp61e8QhAeO/7NXQ==
X-Google-Smtp-Source: ABdhPJxAOZjJ5/qvceUZVNq4V8SlTNhzWM+kam+dxYtHv4BwnGcbutCIUb4ppOegE6xUFaA8C80e19MAdspS8s+XjGo=
X-Received: by 2002:ac8:fec:: with SMTP id f41mr13682704qtk.212.1592841778594; Mon, 22 Jun 2020 09:02:58 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0c=_fPUdoZ5x40AqZPMBN9rt=4ua9oDK8Di5znrUQQFAtQ@mail.gmail.com> <B557E263-8DD2-4BDC-B54D-FFF839D8E025@ll.mit.edu>
In-Reply-To: <B557E263-8DD2-4BDC-B54D-FFF839D8E025@ll.mit.edu>
From: Paul Grubbs <pag225@cornell.edu>
Date: Mon, 22 Jun 2020 12:02:47 -0400
Message-ID: <CAKDPBw8abCw022Fk4Thj2Cozt243ffTCJV58=SR68aq=sg8RnA@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: Watson Ladd <watsonbladd@gmail.com>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000065942405a8ae6076"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/MviK8m88090CTuZSwsPGU1TBYZo>
Subject: Re: [Cfrg] What are the goals of the AEAD bakeoff?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jun 2020 16:03:02 -0000

I agree that there are a lot of potentially important goals, and that more
clarity is needed before choosing design targets. This seems like a good
use case for a multi-round competition: in the first round, people can
propose design goals, then the CFRG can select a few goals for which people
propose concrete schemes in subsequent rounds.

On Sun, Jun 21, 2020 at 4:31 PM Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> I concur with Watson. Different use cases need different "winners".
>
>
> On 6/21/20, 15:01, "Cfrg on behalf of Watson Ladd" <cfrg-bounces@irtf.org
> on behalf of watsonbladd@gmail.com> wrote:
>
>     Unlike PAKE, where a multitude of designs all claimed to have achieved
>     the same security and usability goals, the goals of this competition
>     seem multifaceted and in tension. On the one side is a desire for
>     larger encrypted data volumes, either via big blocks or beyond
>     birthday techniques. Evaluating a big-block construction is likely to
>     involve substantial symmetric cryptanalysis knowledge.
>
>     On the other is a demand for key-committing schemes and nonce hiding
>     schemes. Both of these are likely to have efficiency costs compared to
>     potentially one-pass big block (or tweaked) schemes.
>
>     I don't think it makes sense to have a competition. I think it makes
>     sense to articulate the problems and present them to get people
>     interested in proposing designs/understanding the tradeoffs, and then
>     maybe have a competition once that is clearer.
>
>     Sincerely,
>     Watson
>
>     _______________________________________________
>     Cfrg mailing list
>     Cfrg@irtf.org
>     https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

v2.23.0 | Report a Bug | By Email