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

Neil Madden <neil.e.madden@gmail.com> Thu, 30 April 2020 09:17 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 544203A0C5B for <cfrg@ietfa.amsl.com>; Thu, 30 Apr 2020 02:17:43 -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 nzKNQieMMoDO for <cfrg@ietfa.amsl.com>; Thu, 30 Apr 2020 02:17:41 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 C4A9A3A0C59 for <cfrg@irtf.org>; Thu, 30 Apr 2020 02:17:40 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id v8so6964370wma.0 for <cfrg@irtf.org>; Thu, 30 Apr 2020 02:17:40 -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=oO2B04z2tCFsKLGP9BPIdHnld+V1NS+vvVkvVobocpg=; b=GewnbIbQF0S3FqjN9boTJf6IJUF1/VGoQcKZYf7kmh1Xn0RiInUnoBFUBJwG0erqkr +lZFHvmrv79rzIHmLsh8EokhdXdrr6azDIBGLoLValzHsfd0IvGsrWOQ5Lee3nmwFTzk Aw2avtDRW0VU/gi3SWwEwy7sdhBy2QeAQGovzqrKs/SCG0XiMqoWRz35Yx7QWUq760C2 iLaNXMj3m0S+sdZv8QH+bYj4YR0CZDY2io9C4qwCnbwjoieMSbxCJiIhlUONnWLCltkG mqPYk04VL1BGo2fW6LZOW8hQ1olros3O7PHTBIRGwjFlc7qHhdtVa4cDp9XsMki/0tNM fFEQ==
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=oO2B04z2tCFsKLGP9BPIdHnld+V1NS+vvVkvVobocpg=; b=RDpWMqheRk6JeWA5N1NSmejtU5SmbeNqDufs24SEHA0AOBdki6zl9T/ZjHoM2tx4UF QBAm0JsTb8DHDzTRgg28NQo5ire7wfpEo9ZReV29s0IrdoNa0FAemUGcaQssveCdBfWX dnQVSsS6mOZ6gOeE+BkIVFj9SPlAdhZbbb1C67foEQXVqXBJKIovqzmyxqMDUEr3dLDq 17D//KChyRZ6pwkoUWXLMAog6EYO7V8siTcDdXCRKLlMkda5zCtshP4GOGixfnpJPrQO crSIaCCCWYcx7hBqa+jUs4z/505e3TgkuENMGgdBwzPRcVmU0qOnZ6KN6g8Ki9gHxi9t 9Jig==
X-Gm-Message-State: AGi0PubnabHB6HwlzmtW7f42dcoS5K7UM2iN2sDpqIYfsLfYWr/66J2Y 3f9Waxm319/VJMrCeiMp/3XcIaMtgoU=
X-Google-Smtp-Source: APiQypLVOM/i/bUDytwZNNBFG82coyLrE8E8t3ZHZMUR2xNzxprLQVk4SVvCW1MOUyn1yTgpGuRrzg==
X-Received: by 2002:a1c:3281:: with SMTP id y123mr1937742wmy.30.1588238259174; Thu, 30 Apr 2020 02:17:39 -0700 (PDT)
Received: from [172.25.1.197] ([89.206.213.162]) by smtp.gmail.com with ESMTPSA id o129sm11952395wme.16.2020.04.30.02.17.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 02:17:38 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
Message-Id: <20C567C5-07E8-4F97-A2F2-C95D7DAE9426@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_88677307-0568-4107-9AD4-FF32D8C651D4"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 30 Apr 2020 10:17:37 +0100
In-Reply-To: <1588236309761.34848@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> <0863E134-5344-4EA0-838F-8C4C2E53BEF3@gmail.com> <1588236309761.34848@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7JVn4YfriKXfp93q-Nn1Nh7msgo>
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 09:17:44 -0000

On 30 Apr 2020, at 09:45, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> Neil Madden <neil.e.madden@gmail.com> writes:
> 
>> 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?
> 
> Just because someone wrote about it somewhere in the past doesn't make it non-
> exotic.  In particular I don't know which specific "one-pass unified model
> from SP 800-56A" you're referring to since SP 800-56A is just a long shopping
> list of everything anyone at NIST could come up with, but all of them are
> pretty exotic and AFAICT unsupported in major crypto libraries.

Err… https://www.google.com/search?hl=en&q=800%2D56a%20site%3Aietf.org <https://www.google.com/search?hl=en&q=800-56a%20site:ietf.org>

> 
>> 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
> 
> My question was really trying to find out whether this was an attempt to fix a
> real problem or just an excuse to play around with a fancy crypto scheme, and
> if what you're referring to is "6.1.1.2  (Cofactor) Full Unified Model, C(2e,
> 2s, ECC CDH) Scheme", an extraordinarily awkward and painful one to boot.  It
> looks like it's the latter.

No, it’s 6.2.1.2 (Cofactor) One-Pass Unified Model. For reference, Bouncy Castle implements the “extraordinarily awkward and painful” full unified model here:

https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/ECDHCUnifiedAgreement.java <https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/ECDHCUnifiedAgreement.java>

I’m struggling to understand why you’d think this is complicated. The one-pass unified is almost identical except the second DH would use the recipient’s static public key instead. It’s incredibly straightforward.

— Neil