Re: [Cfrg] Recommendations Regarding Deterministic Signatures

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 20 December 2019 18:09 UTC

Return-Path: <hallam@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 A3BD712084D for <cfrg@ietfa.amsl.com>; Fri, 20 Dec 2019 10:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 uZqSDle8w1jO for <cfrg@ietfa.amsl.com>; Fri, 20 Dec 2019 10:09:16 -0800 (PST)
Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 8E51F120856 for <cfrg@irtf.org>; Fri, 20 Dec 2019 10:09:16 -0800 (PST)
Received: by mail-oi1-f181.google.com with SMTP id n16so1027065oie.12 for <cfrg@irtf.org>; Fri, 20 Dec 2019 10:09:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=31TcMeZ77YxuxkmTovzh42BsEoRQOh+lV+z5lLCvNSw=; b=dwDTwe+S0flvDl4RCJK9CXR9/ROBIfnMgvLR5h0Er79DmknlqggwNuaOqf2EqMvI3P jaUCgAsCp8rlCLhKCd1M9cb7lpyciFK1pCwM1TVBjnH7BrBHYGBq6IzItsbqpO6Bb9W7 UEbQUNIgi5+hKWZOXWbyIB35eUs6Kqr6TPBfUOUjzqtjy0r3pByOdzkjFqD481gbW+tx ZzfsgHw77thmkN6YQeeozeZwGoSFcD3rw4bxBARVcMzc2aCTF7gfH2IyYcmq9/V/Os0i jtckjMVKXdewomlQocJ4NKVz/LQfH/QwHAQRR4JRUAcuklIjzRB3f7LfMMQicW0s/Zy5 LvgQ==
X-Gm-Message-State: APjAAAU6Urh9soa0J4h9DQtV49t+OySxNnin1AxwjsVBzjjlm5lZMZlg QTUN8Vi6OpfT78x55on5X80CQQV49sON0zUrp+pNVKKj6RY=
X-Google-Smtp-Source: APXvYqw0Qa//IK5Fw3KkuGWEQFhhQSnvhDtHC4k79Y2ybtyNJ2tiBAxxAFqFDWdG21Nfqh0NEGbcWzNdjVQ5Kge5lq4=
X-Received: by 2002:aca:cdd6:: with SMTP id d205mr4319310oig.90.1576865355675; Fri, 20 Dec 2019 10:09:15 -0800 (PST)
MIME-Version: 1.0
References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
In-Reply-To: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 20 Dec 2019 13:09:04 -0500
Message-ID: <CAMm+LwhzejJSWqHUpisLuyuoqhQbum5qN-P09xeWdSN3A_-o_A@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000623f9f059a2693c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/1toVL-Y9q0cIaDX5kXJsuIW7QaA>
Subject: Re: [Cfrg] Recommendations Regarding Deterministic Signatures
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: Fri, 20 Dec 2019 18:09:18 -0000

The objections to the deterministic signature approach raised in that NIST
paper could be avoided by applying the Kocher blinding approach whose
patent has recently expired as I point out in another message.

However, there is also NIST interest in threshold cryptography and while
{Ed/X}{25519/448} support threshold key generation and threshold decryption
and threshold key agreement, RFC8032 does not appear to be viable as a good
threshold signature scheme. (It is possible to do multi-signatures of
course and I have a defective threshold scheme that might make sense in a
TPM environment)

I will be submitting an Internet Draft describing threshold key generation
and threshold decryption by the end of the year (the code runs) and I
should have a threshold key agreement draft shortly after. It would be
really nice if we had a threshold signature scheme to complete the set (get
that 20% matched set armor rating).

In particular, I believe that we need a threshold signature scheme that is
non-interactive. This is because I need to be able to explain the scheme to
a layperson who does not understand the signature scheme. For example: The
Alice+Bob aggregate signature is secure because it is constructed a
signature contribution from Alice and a signature contribution from Bob,
both of which are secure signatures in their own right and both of which
have the same exact construction with respect to Alice and Bob's public key
as the aggregate signature does to the aggregate key.