[CFRG] How to construct a hybrid signature combiner?

Simon Josefsson <simon@josefsson.org> Fri, 22 March 2024 21:56 UTC

Return-Path: <simon@josefsson.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 B1850C14F6AC for <cfrg@ietfa.amsl.com>; Fri, 22 Mar 2024 14:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b="ahrtiIsb"; dkim=pass (2736-bit key) header.d=josefsson.org header.b="oY4oOw4P"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6xBBLU28Nrg for <cfrg@ietfa.amsl.com>; Fri, 22 Mar 2024 14:55:58 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B96C14F682 for <cfrg@irtf.org>; Fri, 22 Mar 2024 14:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2303; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description; bh=yUfFYUiux9S+xSG3DcvH3I74YSFj4yISPXy/TX0ExBU=; t=1711144551; x=1712354151; b=ahrtiIsb3iuUVaJUYkYWhX8PLowul2DbZZdx8JF73Ozh45i KXuj7I2iHHbfgslD5NqQe967tb39nOYOHR3HLCw==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2303; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description; bh=yUfFYUiux9S+xSG3DcvH3I74YSFj4yISPXy/TX0ExBU=; t=1711144551; x=1712354151; b=oY4oOw4PAXmSpNL1I19UrMsPTuZ3TfvA7S/c7VSGtbUYYnZ x/EaJSN5haHyq7kTaHWFIHFlOG+znUSSA3hYzxTGQVpiQmVQ36hU1aKLvYmO/bdrb9+QVEEzuSg/o lrMNWksx43YP0xvioTMnkq9yGnxdPxHbsPdRGWWMMkcSqxX2sGRkHFsPGgE7XEYE7NwHmwFF43Zms ObzmiOpJeOp7GL99TgmTbcRCeeMTr3ajKY3ym/e6qiYd0KYHFD3LjfuwXAzvHHb7QNoX+JToB8Quj gUnOFANzvHRmFgngCfo9YXNYtXfL+RqAt7DIVsfDZbuJ/nlnXr6k5FTmDsH2O1WL5YfipwIw1HfFy 1chrETEvCpt9KTS7H5vgkQy+X1M7Rqn83tuanjs82+LI9LIfanmCWO1EJ4+A6f737kzYBvgy/zXqD U4UL6SfDyR517HxnHm5o0OMI;
Received: from [2001:9b1:41ac:ff00:823f:5dff:fe09:16ac] (port=60806 helo=kaka) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <simon@josefsson.org>) id 1rnmrd-000U51-FV for cfrg@irtf.org; Fri, 22 Mar 2024 21:55:49 +0000
X-Hashcash: 1:23:240322:cfrg@irtf.org::l+vvM6Vhhkrxjp8j:2hmC
From: Simon Josefsson <simon@josefsson.org>
To: cfrg@irtf.org
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
Date: Fri, 22 Mar 2024 22:55:38 +0100
Message-ID: <87o7b6szhh.fsf@kaka.sjd.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/nNWzMkc5fImTbWYhtKHfu26w6KM>
Subject: [CFRG] How to construct a hybrid signature combiner?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.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://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 21:56:04 -0000

All,

Prompted by discussions in the OpenPGP WG etc, it would help to
establish one hybrid signature construct that combine one traditional
signature scheme (e.g., EdDSA) and one post-quantum signature scheme
(e.g., robust SPHINCS+) into one instantiated hybrid signature scheme.
It should be a single identified algorithm that could be dropped into
any place we use, e.g., Ed25519 today.

Some people dislike hybrid signature schemes, dismissing them as
unnecessary, but without any concrete hybrid signature scheme to compare
with, it feels like comparing apples with imaginary oranges and
dismissing the latter because we already have apples.

For hybrid KEM, we know how to create optimized hybrids (X-Wing) and how
to safely create generic instances using Chempat --
https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-00 --
however understanding the requirements took some time.

What to recommend for hybrid signature schemes?

Let's start with an example: OpenPGP consider a composite signature
scheme using ML-DSA + EdDSA like this:

  6.2.3. Signature Generation

  To sign a message M with ML-DSA + EdDSA the following sequence of
  operations has to be performed:

  1. Generate dataDigest according to [I-D.ietf-openpgp-crypto-refresh]
  Section 5.2.4

  2. Create the EdDSA signature over dataDigest with EdDSA.Sign() from
  Section 6.1.1

  3. Create the ML-DSA signature over dataDigest with ML-DSA.Sign() from
  Section 6.1.3

  4. Encode the EdDSA and ML-DSA signatures according to the packet
  structure given in Section 6.3.1.

  6.2.4. Signature Verification

  To verify a ML-DSA + EdDSA signature the following sequence of
  operations has to be performed:

  1. Verify the EdDSA signature with EdDSA.Verify() from Section 6.1.1

  2. Verify the ML-DSA signature with ML-DSA.Verify() from Section 6.1.3

  As specified in Section 4.3 an implementation MUST validate both
  signatures, i.e. EdDSA/ECDSA and ML-DSA, successfully to state that a
  composite ML-DSA + ECC signature is valid.

https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc#name-signature-generation

This is a naive approach.  I'm not saying it is bad, but it opens up for
questions.  Should verification fail early if one signature fails, or
should both signatures be verified and the return be A AND B?  There are
interesting oracles in here.

You could equally well consider a scheme like this:

s1 := EdDSA(m)
s2 := ML-DSA(s1||m)
return s1 || s2

However this doesn't bind public keys.  Do we need to bind public keys
to avoid some attacks?

Some properties of hybrid signature schemes are discussed here:

https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-02#name-properties

The Simultaneous Verification property seems nice and strong, but is it
sufficient to generally offer good composability of two arbitrary
algorithms?

Finally:

What properties should a good generic hybrid signature combiner have?

Can we describe one example?

Can we give some examples of bad hybrid signature schemes, to better
understand the failure modes of signature combiners?

/Simon