Re: [Cfrg] Multi-recipient public key authenticated encryption

Neil Madden <neil.e.madden@gmail.com> Thu, 30 April 2020 06:38 UTC

Return-Path: <neil.e.madden@gmail.com>
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 69A4C3A090D for <cfrg@ietfa.amsl.com>; Wed, 29 Apr 2020 23:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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=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 3JXLxhzCEaEo for <cfrg@ietfa.amsl.com>; Wed, 29 Apr 2020 23:38:09 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 646DE3A090C for <cfrg@irtf.org>; Wed, 29 Apr 2020 23:38:09 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id o27so75895wra.12 for <cfrg@irtf.org>; Wed, 29 Apr 2020 23:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o+ceybWKS2tDu1kP/imO9LstI4WMsiXXP3w0IkD4hdY=; b=i901H5EYBPPvCSUtaejmJOygUpyp/t12RRR/Tq03xMoHzNgDleVEyyuE4IH3y2wnW7 hEbig7Nq6UaBp38bZShXsy3TaZrVl9o324T+pYHzeQZ649nyHf5Qs8NfeX4NcCQ6eMJI dST08e7dPJfbBX40WveKCgwwwbcBn0EgvvA4LeGM+gZtP3dmqIZrg0KgIKID/oBvRW95 TbGeS1rWH6swAPWLHqr9FyueAqJypq1+KujqbC9H53Kq86dW0oDtXXdoIyaNxLG7q71/ MawDJSTwNnR/uBxxTkBSgJ7tHfrSCQ3jkddMP5p33YCgA8CjNsFqvv+nY/55w2CtZlBX E1ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o+ceybWKS2tDu1kP/imO9LstI4WMsiXXP3w0IkD4hdY=; b=TjknRttNqSz56hLc/ZzxihxZRvTY9tt/Jahu6qRp/QCG3zV3SxFn4HcuKApcUT0j0b 6ycPUM4aREEaRL0Ccz1h21ePmitgULtFfsifAlx0eP11AL59VMeWOpEf7i7SFwiruTcs z6U6B2wCbsxjIjGZT2Wz7KayCrnfqucn4YZNPf+Ak3cUv+62cNISDM2ds2yV0Si+UCc3 gWq+KQg4Aa44suLQ1opodR4sKF3PsqWg1VFYualurDk0WAW2qkesJh+dtxiG5PLTgXKW kSY+IeywJijLhFiMLwi7hbEMXN42OESeQ5mGekAGg0CKZKfxIj8pgUtGENN7bUwnJ20R e7Vg==
X-Gm-Message-State: AGi0PuYsAmBQ7e8vNbEKenMXRwgpQzMACYEQWucZaEyPq+ZrCC7cJdD2 LaGWmej8VDjpqknsSy8eRWKYY+jZZRY=
X-Google-Smtp-Source: APiQypJ4W/DqQvYxy4HOafvo0p98USPcIwLfgKXxXZX9VOMOQX0OQp//yh321f1n1YQIUtZxpUFmxA==
X-Received: by 2002:adf:8162:: with SMTP id 89mr1927471wrm.387.1588228687748; Wed, 29 Apr 2020 23:38:07 -0700 (PDT)
Received: from [10.0.0.2] (193.207.159.143.dyn.plus.net. [143.159.207.193]) by smtp.gmail.com with ESMTPSA id n6sm10593515wmc.28.2020.04.29.23.38.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 23:38:06 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
Message-Id: <0863E134-5344-4EA0-838F-8C4C2E53BEF3@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A15B78D6-2E1F-4CE2-863E-71C44B6CE17A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 30 Apr 2020 07:38:04 +0100
In-Reply-To: <1588215384594.8845@cs.auckland.ac.nz>
Cc: CFRG <cfrg@irtf.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <AD42E3BB-8AF2-4FC9-9407-9A8D8D5130B4@gmail.com> <1588215384594.8845@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/pWaVbTl0IY8djXVqOPwtiAoIrJ8>
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption
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: Thu, 30 Apr 2020 06:38:13 -0000

On 30 Apr 2020, at 03:56, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> Neil Madden <neil.e.madden@gmail.com> writes:
> 
>> Given that many uses of this sign-then-encrypt pattern do not require the
>> strong security properties of signatures, I have proposed [1] a public key
>> authenticated encryption mode based on NIST’s one-pass unified model from SP
>> 800-56A. This avoids the nested structure and means that you don’t need
>> multiple cryptographic primitives. The proposed algorithm uses two ECDH key
>> agreements: one between the sender’s ephemeral private key and the
>> recipient’s long-term public key; and a second between the two parties’ long
>> term keys. The two shared secrets are concatenated and passed through a KDF
>> along with some context arguments. For a single recipient this achieves
>> sender authentication (subject to replay), and the single recipient case is
>> what I am primarily concerned about.
> 
> Maybe I'm missing something about JOSE here, but rather than introducing
> complex and exotic new encryption modes, couldn't you just define a signed +
> encrypted message format like PGP and S/MIME have been using for thirty years
> now?

Firstly, is an encryption scheme that has been standardized by NIST for 14 years really exotic? Or do you mean hashing the ciphertext for integrity is exotic?

When you say to instead use a signed + encrypted message format, do you mean a proper signcryption mode or do you just mean a generic composition of signatures and encryption? The latter is what JOSE already supports, and I could just have defined a way to remove the extra base64-encoding. But such a naive composition has its own problems such as [1] (known back in 2001) and [2] showed that there are surprisingly subtle conditions to consider. Part of the rationale for the new algorithm was that I have seen developers repeatedly make exactly these mistakes when combining signing and encryption in JOSE.

In the single recipient setting, it seems to me that the DH solution is significantly simpler. Indeed, I was able to implement it on top of our existing support for ECDH-ES encryption in a few dozen lines of code (mostly just refactoring the API to supply the additional key). Given that JOSE is mostly used for JWTs and JWTs only support single-recipient encryption I’d prefer to stick to this algorithm and see if I can add a simple tweak to remove a sharp edge in the multi-recipient setting.

[1]: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
[2]: https://eprint.iacr.org/2001/079 <https://eprint.iacr.org/2001/079> 

— Neil