From nobody Sat Feb 13 17:53:50 2021 Return-Path: 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 B6D4E3A12A7 for ; Sat, 13 Feb 2021 17:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 RDKzNw-86g76 for ; Sat, 13 Feb 2021 17:53:45 -0800 (PST) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (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 571293A12A5 for ; Sat, 13 Feb 2021 17:53:44 -0800 (PST) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 11E1re83022232; Sat, 13 Feb 2021 20:53:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=Sse3RLyhSuQY6zR/qzjFcVQq6yMDKgfSJgBq5Rj5GQZ6+Z2BhvJ39CIAC8zXcbhdhw59so9ZK1ADa3r/Ei/4lSS3PkZDsKsdOH7PUlhIr7pZIKdmK99NRulpDCkbpKUhKuUIrIzs5ZXpSb44cVNab2z950bRiGax145wuRHujuNp0f5Pn/VhC5S4ASVeUk4tbrJx5ULOl8zrjDP0/jx8EMVUCeqW5tZ/V7e97b4ks1HybzFhjiZ5fTBRHLmQSlLLvj4vI6zJB18Nmte49n9Xd6oj0mVtTLBogk8beLQYD65IS0LUHJLpv6O4n5b0WohepFddoWI5rjDjKM6n7TszMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TrVexq1bRmK8EWLnK1kI38LzyptYMlcXOxCE7Z/l3y0=; b=HmufGWgptD8t9POaMgCaNURBGBQPebPmY+pHMq/R8HP7t2JR+exixGbHpFKwPp3b/F+tNwn8P0K8XPfF6dJ7XqrtmSjjIYvOdHreLHz4i6Q/+veOnh32vP/r3kVbxosCUjI6Agb72Kyq0bbhC5tz5sdg+IVTSKDiwEW64C4Er8p4Ql8aC66ZwvtmZfN+D2d4u8lFuvfTBq0mdZQGNPQhGXTYpXWbyQkxXWFzCvlynUMKob718FOwMond+F8iBa+rlSs970LuOCQnCY/cULAolYP2HqpRGzo7gGlrV55oyl95R6XJg0ogR7HZQm+95XRzVaf9NFe/EZbTLj9+b37mIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Dan Harkins , Karthikeyan Bhargavan CC: "cfrg@irtf.org" Thread-Topic: [CFRG] Fixing the multi-shot API of HPKE Thread-Index: AQHXAZcMrnaBhuTgpUC9Z0BiBgaMoKpV7okAgAAVyoCAAI0RgA== Date: Sun, 14 Feb 2021 01:53:37 +0000 Message-ID: <0E497EBB-0D08-45D7-B75F-691EAEBB1925@ll.mit.edu> References: <4FCD508B-0ECB-4F7B-B252-B92CDFBC5B8B@gmail.com> <1ded9ec0-4da1-981d-fedc-709ca301c166@lounge.org> In-Reply-To: <1ded9ec0-4da1-981d-fedc-709ca301c166@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: lounge.org; dkim=none (message not signed) header.d=none;lounge.org; dmarc=none action=none header.from=ll.mit.edu; x-originating-ip: [129.55.200.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: daf4b6ea-7480-4f37-f1ca-08d8d08b587c x-ms-traffictypediagnostic: DM3P110MB0556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2UGSDs2wbeHvNo+ti7KfUgcp6odCBx3+AtZoFdtuoYmT0s3BtvBa9lSsrGmMwolUnd6A9GO4ogsfZTQv0fx1tCE+tCS8n5yn2y32yZkKVRTI6PXAKj4Jw6D1DzbmT0bkpmyX6j1VRf3TkP+fJ2pVp9G8bZ8s1+zdBV0/4mcPnUl5E5KfiIjv4CKzU4lMMw/jpkQOFRNZxhv+lHge8X+acP3BQgN0EBzbCFb82DIIqOK1UfaXDdMOFSAXm0Ux4ZhUzjlVubGHzekBPz8+CvZIkUXB+avH7ihIWDw1TLZZnXWd8XO+QlOKZr2iqoZzl/++lnT/R3WGicBSsxIVVjTcdGHshyNl50woIssh3RnElLvP5hJAMl78ecLxCiNyU4/htijCWhOsFgwLceN7bZQ92jo0NTwSHfJohZLm4qVEPFi54l7+u9i5JoZfAvwgVU4rcmtlaRRg1UpdtStAQBZJX3HIBMs0W5fiJ10xYZ0IQC941FC8SAtcnA38wVd2XMSlDapzfxVDin42xlWu/v9WODtAQ3NcXtXmt8haV2pUqIx+zJYav1w4IMKYf1zOJMcYgwo4beAnMBeG4Ddwgxu72Cm/P0NP6WFPbvd4x72qmmd6ZOR05fJu1FvIx1kwvZTm65+I5OkbkNNhO9zMzhdEoG9tjWxPOBdE742jngYdz4U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM3P110MB0234.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(110136005)(33656002)(26005)(66556008)(99936003)(75432002)(186003)(8676002)(8936002)(64756008)(2906002)(5660300002)(66446008)(966005)(83380400001)(53546011)(4326008)(6506007)(6512007)(71200400001)(498600001)(66616009)(66476007)(76116006)(6486002)(66946007)(86362001)(2616005)(956004)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: LuuK4xAaTgPwI7Sb++zWdnf/A12mYiGtIscZLPAlQlWCncZUj/OMlECpIt+HTzTwydG7wOge6oVze20SxP3FTRyNO/zB6rlWOmq2vHGnQCrkMyu9Pt/tY/v9WqnIxCU4nfMJSjWRtabedfT34oS2BnWLRkIU44Z5UG3ew24E2A2KCyb8/b8gVEfcfstICBw/LAZizXZXeAhfYzrvWMOO+dB0/kSS9fcKNTstnRC+mUalhobZAJq/Wsjzd67e5MN8iW9/T2du1Q8nshsi3MBi69Zn00kvIJ+9E5vFJTiGT6nwlqpk8X9c90Y3EGRadF1QngYr4dGODVzwSWaGbzQWQI9DSwCYsA/AqET5cO81j2i+0nkIZbCqlTHcWEiLDKDSzpltKqE8chmST6LMsqVeo5g3rH8s8v3DJQOfZbP+RD58o4pQVlxlopx7jXcVCk3ryg2Jdnz76Lj29MGHlSaWfm4lsFL+D+1ds/BGXEUHN2YifroPzJbZl4Abmjur1tQjgvGgAq6RUas3bFjl8M6CVHwEPNh5MKltmkVCOQprDi4/EGigL93iKQW3YouNS9516DCjSc5ZdvssIL1dLQ8VFmfbye6h4n4NRys52VkUDhrqWPouZnkosDWl+qf3Fjx6AQeZDwkZKhcJKsV6mPnq/1YyEt5LTOI6rkhwq1rWtNiiyJ0YYazfSERcgCQB/MJWXivBr+IIhUL2Xl1s2elNOQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3696094412_2008526837" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM3P110MB0234.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: daf4b6ea-7480-4f37-f1ca-08d8d08b587c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2021 01:53:37.5120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AMbE15fX+8iEPbdOwAfi2W1uUogbxfk3tE3n18ocrTedRTcV1PgTyhBGTryppeFH X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3P110MB0556 X-OriginatorOrg: ll.mit.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-13_02:2021-02-12, 2021-02-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2102140010 Archived-At: Subject: Re: [CFRG] Fixing the multi-shot API of HPKE X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 01:53:48 -0000 --B_3696094412_2008526837 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Strictly speaking, AES-GCM-SIV does *not* need a nonce, given that the boun= ds (how many messages of what size are secured with the same key) are observ= ed. I found that a very useful property. Not everybody needs that, and not alwa= ys - but it's like "you don't need it, until you *really* need it". -- Regards, Uri =20 There are two ways to design a system. One is to make is so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 =EF=BB=BFOn 2/13/21, 07:29, "CFRG on behalf of Dan Harkins" wrote: Hi Karthik, On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote: > Hi Dan, > > I don=E2=80=99t fully understand the problem you are alluding to. > >> "It is up to the application to ensure that encryptions and >> decryptions are done in the proper sequence, so that encryption >> and decryption nonces align.=E2=80=9D > The HPKE stateful API guarantees that nonces cannot be misused, even = if you use AES-GCM or Chacha-Poly. (Of course, you could also add a SIV ciph= ersuite.) > Furthermore, it guarantees that the stream of plaintext messages rece= ived by the decryptor is a prefix of the stream of plaintext messages sent b= y the encryptor. It's not an issue of misuse, it's an issue of the sender and receiver contexts getting out of sync through entirely normal network behavior and becoming unusable. > In the current design, if two ciphertexts are decrypted out-of-order,= both decryptions will fail. > So the problem alluded to in the text above is one of functionality; = the application has to ensure (using some meta-data) that it is calling decr= ypt in the right order. > The application usually has to do something like this anyway to put t= he plaintext stream together. > > I do not see how using AES-GCM-SIV is going to solve the above issue;= yes, it would allow you to decrypt the plaintext in any order, but the HPK= E receiver would not be able to authenticate the correct order. > Am I missing something? AES-GCM-SIV requires a nonce (although reuse is not tragic in the way it is for GCM) so there still needs to be some guarantee that the nonce plugged into the receiver is the same as the one plugged into the sender when the ciphertext was created. This is a proposal for AES-SIV (defined by Rogaway and Shrimpton) which can do deterministic AEAD (it can also be passed a nonce to be more like a traditional AEAD mode, albeit slower, but that's not what I'm proposing here). No nonce so nothing to worry about getting out of order. Regarding the correct order, for a streaming application yes that's true. The correct order would still be needed and whatever technique you use to ensure that decrypted packets get ordered correctly could probably be used to ensure that packets are decrypted in order. But there are other interesting applications of HPKE that are not streaming and each message can be thought of as self-contained. Imagine a sensor obtaining some environmental data and then sending it off to a server for correlation and processing every