From nobody Sat Feb 13 03:10:44 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 6F7AB3A0EEE for ; Sat, 13 Feb 2021 03:10:43 -0800 (PST) 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, FREEMAIL_FROM=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=gmail.com 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 d-nfi6vhaO-T for ; Sat, 13 Feb 2021 03:10:41 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 8DF333A0EED for ; Sat, 13 Feb 2021 03:10:41 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id b3so2589215wrj.5 for ; Sat, 13 Feb 2021 03:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lpJ09GULdUwa4iClD88cjthXtOA03Nja7Ho0/66ZG4M=; b=j0jwQN8HHE7xaOl4lsNDUcOtxs+6YZ4I2ZtQkf+zFdFY5+DASXxUgSww5ZSC8u9ReR aWDd4xAjEmWbvu5DFjibGiNm+oVR/pZLRvRrc1vQdXNO0Bg2Ar9pI3eNBnAn2RRsS/76 Dez3LXD0UUuZ+Qth6/Zi0ep+vNPCgerttCoTcfyCfwx/dU0yH6vtS4olUlt1up/hd9kl B+YZ4NRMDe4Nhj8t+pIhY2J7HmkHIbmKWgCIgo8q7YYwtUePlLFCdkzYWoFkgPlOX8Jz YapyBc1Skpjljn00xkjRjtQzo28wXqbreEc0pACkc5/tMinIs2KEGOunGYJQc7D1sFiH +ubA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lpJ09GULdUwa4iClD88cjthXtOA03Nja7Ho0/66ZG4M=; b=I8C2JOZjG7gC1YesVjRajmX4UknRM1NPp9hThqOJM8636oystL28ZnSc+BYx5tpLDS /wBzyOKaMbrddXAAYotpXgtuphxVeJjucHrygMCa3mCsntgW+AsKddni2dIqH7r2EJgn HtJO71oLlrMSFmvJhbDXvh3EyEf1K/FPYj/Q2EiWZEacyKYmfCbJyzRJEYHpWlOc0svW UZmowErRzAkFiMyNRZN2wZg+57b8V7EF9bBEySlMu57r9vDUiv5uSkclmGfrdtOhwINv LJ2xBrgEHx32l8rAQqw9zBWoydFPTpEwXJvO7Bf9JdL4YonsritaDYG1A1ux54WYS9Qz GMmQ== X-Gm-Message-State: AOAM5323jS1lIpvFQdr1f4EO+IyaPBdVsLmz3sS39HSlaDXlet1eLr5A 3NbOCi7qk6ezJh490HY4Xtw= X-Google-Smtp-Source: ABdhPJxrvC/C5yg8lDog8Yb5rQ2NB7VUKRgxjVXmU8jtRwvcTvTBkvqO04BWcYkE38lrw7pRb0r+IA== X-Received: by 2002:a5d:698b:: with SMTP id g11mr8288782wru.211.1613214639803; Sat, 13 Feb 2021 03:10:39 -0800 (PST) Received: from [192.168.0.33] (89-156-101-160.rev.numericable.fr. [89.156.101.160]) by smtp.gmail.com with ESMTPSA id q19sm19449134wmj.23.2021.02.13.03.10.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Feb 2021 03:10:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 13 Feb 2021 12:10:38 +0100 Cc: "cfrg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4FCD508B-0ECB-4F7B-B252-B92CDFBC5B8B@gmail.com> References: To: Dan Harkins X-Mailer: Apple Mail (2.3654.40.0.2.32) 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: Sat, 13 Feb 2021 11:10:44 -0000 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 = ciphersuite.) Furthermore, it guarantees that the stream of plaintext messages = received by the decryptor is a prefix of the stream of plaintext = messages sent by the encryptor. 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 = decrypt in the right order. The application usually has to do something like this anyway to put the = 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 = HPKE receiver would not be able to authenticate the correct order. Am I missing something? -Karthik > On 13 Feb 2021, at 00:29, Dan Harkins wrote: >=20 >=20 > Hello again, >=20 > The HPKE spec defines a single shot API for doing things like = key-wrapping. > You pass in the recipient's public key and some plaintext and get back = a > ciphertext. And that's it. One and done. >=20 > There is also (what I'll call for lack of a better word) a = multi-shot API. > The idea here is that there's a single asymmetric crypto operation = involving > the recipient's pubic key to derive some state that resides in an = opaque HPKE > context and then multiple calls to encrypt distinct plaintexts. The = state > created includes a base nonce and a sequence number (initialized to = zero). > Each call to another encryption (decryption) increments the sequence = number > which is xor'd with the base nonce and passed to the AEAD algorithm. = The HPKE > APIs take a plaintext, and AAD, and produce a ciphertext, and vice = versa. >=20 > This multi-shot API is fine if your world is Guaranteed In Order = Delivery > of Packets but that's not the world we all live in. As such, it'll = only > be a matter of time before the sender and receiver are out of sync. = The > HPKE draft alludes to this problem this way: >=20 >=20 >=20 > Well that's a pain! One of the nice things about HPKE is that one = doesn't > need to worry about the nitty gritty of crypto state management = anymore, > it's all hidden. The API is nice and clean-- pass in a plaintext and = get a > ciphertext, pass in a ciphertext and get a plaintext. >=20 > If there was an AEAD mode that did not require a nonce it could be = used > in HPKE's multi-shot API without need for the application to manage = state > and guarantee the parties stay in sync. Thankfully there is such an = AEAD > mode: AES-SIV (RFC 5297). >=20 > When I brought this up earlier (and also on github) in the context = of > misuse resistance the response was, there's an export-only API that = will > give you a secret and you can go do any AEAD mode you feel like, = including > AES-SIV, issue closed. >=20 > While that is technically true, it applies equally to the AEAD = functions > that HPKE already defines-- you can export a secret and do AES-GCM-256 > outside of HPKE while managing the necessary state yourself. Yet HPKE > defines AEAD functions whose state resides in an opaque context so = there > is obviously value in having that functionality. I just want to get = that > value-- a clean, multi-shot API where I don't need to worry about = managing > state or guaranteeing people remain in sync-- for people who don't = live > in the world of Guaranteed In Order Delivery of Packets. >=20 > So I'd like to ask the group whether they see value in having a = nonce-less > AEAD mode in HPKE. If so I'll be happy to resurrect the text changes I > proposed and will be happy to contribute test vectors from my HPKE > implementation which already does AES-SIV. >=20 > One issue is that there are different security properties for a > deterministic authenticated encryption scheme than for a probabilistic > scheme. This is discussed in [1] and the security considerations would > have to mention this. But I don't see that as a formidable problem. >=20 > regards, >=20 > Dan. >=20 > [1] Rogaway and Shrimpton, "Deterministic Authenticated Encryption", > EUROCRYPT, 2006 >=20 > --=20 > "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 >=20 > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg