[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
- [CFRG] How to construct a hybrid signature combin… Simon Josefsson
- Re: [CFRG] [EXTERNAL] How to construct a hybrid s… Mike Ounsworth
- Re: [CFRG] How to construct a hybrid signature co… D. J. Bernstein
- Re: [CFRG] How to construct a hybrid signature co… Ilari Liusvaara
- Re: [CFRG] How to construct a hybrid signature co… D. J. Bernstein
- Re: [CFRG] How to construct a hybrid signature co… Simon Josefsson
- Re: [CFRG] How to construct a hybrid signature co… Ilari Liusvaara
- Re: [CFRG] How to construct a hybrid signature co… D. J. Bernstein
- Re: [CFRG] How to construct a hybrid signature co… Loganaden Velvindron