Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt

Phillip Hallam-Baker <> Wed, 11 March 2020 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC2FD3A0D4E for <>; Wed, 11 Mar 2020 09:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LlwbkYc38qcy for <>; Wed, 11 Mar 2020 09:41:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DCE83A0D58 for <>; Wed, 11 Mar 2020 09:40:57 -0700 (PDT)
Received: by with SMTP id a6so2656897otb.10 for <>; Wed, 11 Mar 2020 09:40:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zi6lNY9oukGZowD31yPH3tsaKA6JSpJuZViV7bU+fw8=; b=CL7vHg91gX22NGQ+bAOlW6L218cI4/draUgMOaxaMX4uuTvmuAj60Jq1fha7IMr5gq ukzHPRMzBqsNzeGA/XZ0v3OuQcM7SABexxj7rIiH+HyqrUk4nAwCKejrLfyvgqfhPomF IqDftZw2OcpKFOQlnEgQa9X5FO+q2O3DfgR7g9dqJaGJvAv2UgoBXkK7dAP1Xl7pZS6D qm9iBleTIyCZmoXVCbnOluOwqLhsVeZadeAvJiMcrcBEl151Wn2KW4VCOM50d0vp8Qq3 FrpOwAIySwXXr8VZBXex8511E2Oc2Nktl4EHSf4daUuUj5BjiD/04nZt65jQl1qfmnFY /KjQ==
X-Gm-Message-State: ANhLgQ36BAJpH2th68CtryZf5Fkf5avjo4WbXet8q8AIVibrGQbOaD+x y1C91gwVxLIK7J0zQ3bxhtWf1tsgQ63P41lVbeA=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vu5sdWpwEBEdTC1apKau67nQbuBX7oLkJwSzkKD?= =?utf-8?q?9/X2zzoaWRrulZCD3WBjNECiMh3n8imb6tarMqey52pK7Wg=3D?=
X-Received: by 2002:a9d:6c99:: with SMTP id c25mr2906944otr.124.1583944856652; Wed, 11 Mar 2020 09:40:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> =?utf-8?q?=3CCH2PR09MB422045123171EBCAD949FDFEF3E40=40CH2PR09MB4220=2Enampr?= =?utf-8?q?d09=2Eprod=2Eoutlook=2Ecom=3E?= <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Wed, 11 Mar 2020 12:40:45 -0400
Message-ID: <>
To: John Mattsson <>
Cc: "Blumenthal, Uri - 0553 - MITLL" <>, "Dang, Quynh H. (Fed)" <>, Tony Arcieri <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000864e6305a096e652"
Archived-At: <>
Subject: Re: [Cfrg] FW: New Version Notification for draft-mattsson-cfrg-det-sigs-with-noise-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Mar 2020 16:41:05 -0000

On Wed, Mar 11, 2020 at 11:15 AM John Mattsson <>

> Hi Philip,
> I think the current discussions (NISTIR 8214A and your drafts) to
> standardize different threshold schemes are very interesting and I think
> they will be practical in a lot situations.
> However, I don't think draft-hallambaker-threshold-sigs-02.html and
> draft-mattsson-cfrg-det-sigs-with-noise-02 should or need to be aligned. I
> think they are quite independent. The mechanisms in
> draft-hallambaker-threshold-sigs-02.html do not seem suitable to deploy
> today in constrained IoT devices as:
> - The schemes are relatively heavy (for constrained IoT) as they increase
> the number of Elliptic curve point multiplications.

If you are doing threshold, the use of Kocher blinding is free because the
blinding can be distributed across the implementations.

> - The schemes require significant modifications to the implementation.

My scheme requires a non-deterministic signature. I can make use of your
scheme to do that. So I cam make my draft dependent on yours. It is
obviously not desirable to do the reverse.

> - The schemes are not for ECDSA

The math works for ECDSA as well. The reason I didn't include it in my
draft is that is a NIST spec, and NIST has announced work in this area. So
I am anticipating they will provide their own spec in due course. If not,
we can do a draft here if there is demand. But for the time being, best to
focus on the CFRG signatures.

The other reason for not doing ECDSA is that nobody is paying me to do this
stuff right now. It is clear that in the short term threshold ECDSA is of
great interest so we can secure code signing. If someone wants to support
my work, I will be more than happy to work out how to apply the schemes to
that algorithm and how to make use of it. My company does not require
ECDSA, we only use the CFRG curves and as Barzini put it, "we are not

> - The protection against fault attacks (active side-channel attacks) is to
> my understanding not well studied while the construction suggested in
> draft-mattsson-cfrg-det-sigs-with-noise-02 is analyzed and recommended in a
> lot of recent papers.

Which looks like an argument to reference your draft in mine.

> - The work to standardize threshold signatures will probably take some
> time.

Very much so.

> Today, we have a situation where a lot of IoT devices have are or planning
> to implement deterministic ECC signatures. Most IoT deployments today use
> ECDSA, but EdDSA is getting some footprint in new deployments. IoT devices
> are often vulnerable to side-channel and fault injection attacks and my
> current view is that such IoT devices should not use purely deterministic
> ECC signatures. For this reasons, there is a strong need to as soon as
> possible standardize a very lightweight solution for both ECDSA and EdDSA
> that does not require substantial changes to the implementation.

One issue that we both need to address is whether we cut new signature IDs
for the non deterministic variants. I would like us to do that as soon as
possible for the CFRG curves.

There is an application that depends on Sig(A, k) == Sig (A, k) for all
messages A and k. In particular, BitCoin assumes the uniqueness of
signatures to avoid double spending. That is (allegedly) what caused the
collapse of MtGox

We don't need to decide how we do non deterministic to roll out identifiers
for the non deterministic sig values. And threshold sigs can share those