[CFRG] misuse-resistant AEAD and HPKE

Dan Harkins <dharkins@lounge.org> Mon, 02 November 2020 20:49 UTC

Return-Path: <dharkins@lounge.org>
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 857CC3A0E31 for <cfrg@ietfa.amsl.com>; Mon, 2 Nov 2020 12:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fKjf6hiuFEZJ for <cfrg@ietfa.amsl.com>; Mon, 2 Nov 2020 12:49:14 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27383A0E5E for <cfrg@irtf.org>; Mon, 2 Nov 2020 12:49:14 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QJ60SZBLSI2U1@wwwlocal.goatley.com> for cfrg@irtf.org; Mon, 02 Nov 2020 14:49:14 -0600 (CST)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QJ600OBNSHD3T@trixy.bergandi.net> for cfrg@irtf.org; Mon, 02 Nov 2020 12:48:50 -0800 (PST)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 02 Nov 2020 12:48:50 -0800
Date: Mon, 02 Nov 2020 12:49:12 -0800
From: Dan Harkins <dharkins@lounge.org>
To: cfrg@irtf.org
Message-id: <d2dabd93-0eae-665d-9294-4b81a44670fc@lounge.org>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_z1leVLqKpRfM1uKJZa1nlg)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
X-PMAS-Software: PreciseMail V3.3 [201026a] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iyPQLX7tEiKZeqqrBHdIzKaHb1U>
Subject: [CFRG] misuse-resistant AEAD and HPKE
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, 02 Nov 2020 20:49:17 -0000

   Hello,

   For some use cases it would be good to avoid the stateful requirements
of the the Seal() and Open() constructs in HPKE. This would seem especially
important if (skX, pkX) are derived deterministically which could result
in reuse of a particular nonce-secret for distinct invocations of Seal()
or Open().

   Rogaway and Shrimpton formalized the notion of a misuse-resistant AEAD
scheme in [1]. The mode they defined, AES-SIV, has the following properties:

    - the nonce can be arbitrary;
    - the nonce can repeat without loss of authenticity of the message,
      with privacy lost to the extent that one could know that the same
      message was sent (if, in fact, it was);
    - the nonce is not even required-- truly deterministic AEAD.

While that last property is pretty cool, it would probably be too
hard to pry into HPKE at this point. But the other properties could
be supported quite straightforwardly I think.

   AES-SIV has been defined in RFC 5297. I would be happy to provide
some suggested text to add support for AES-SIV if there is consensus
that it's a good idea.

   regards,

   Dan.

[1] "Deterministic Authenticated Encryption, A Provable-Security Treatment
     of the Key-Wrap Problem"-- EUROCRYPT '06, St. Petersburg, Russia, 2006.


-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius