[Cfrg] New versions of ECDH Threshold modes
Phillip Hallam-Baker <phill@hallambaker.com> Mon, 09 March 2020 22: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 E53CC3A07D8
for <cfrg@ietfa.amsl.com>; Mon, 9 Mar 2020 15:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iMyjwingbJAW for <cfrg@ietfa.amsl.com>;
Mon, 9 Mar 2020 15:09:55 -0700 (PDT)
Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com
[209.85.210.45])
(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 8EAED3A0795
for <cfrg@irtf.org>; Mon, 9 Mar 2020 15:09:55 -0700 (PDT)
Received: by mail-ot1-f45.google.com with SMTP id g15so5136357otr.0
for <cfrg@irtf.org>; Mon, 09 Mar 2020 15:09:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=HYo3zicDsRuq7TlCx5K149ILGzoTJc3ecpNAfCRS7tE=;
b=Oaqqlq0X3Hz/NOCqrOJ9IuE5+Kf6qDjrJlJqVCEAB7PoUyjWNrTMxbq6KRUScodJ6E
grYIAIUofoDwlMcu7Br5uc6rUALU/ZF27qEnPoeZbNjWKJMPjXKTWuyfVCf0WhIcukX0
+3ba98Okf6fGFWI/sNnSW76/1hVlNOxJt1/LJ8w6J4ggtE35qxRxU8AsnLUJeETJvTKA
lHlIncG6cTUsDtptcxNNo7yZTOJJ9K6l2dwjYO3ZQoixRLq6CZoGkcy+CwRE9rao5AIo
Y0IAG31PTgow09QGV82kBJIckokn5VKyaymEjhaLobV6R3QvH5FBbSKPiFltPhGZOIS5
5Gtw==
X-Gm-Message-State: ANhLgQ1m5CBUwW5JsO/kdPpXCt+CnuQ7rsgvwRX7pIJI8poJZlK+9aNZ
+LOrUnWYjzCMGCq+QGarmhBcZytryufgPjOT9gaaMqdYwyI=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtV3BJRzfe61cOlO0NkTpv495PFD/rj+RXhnhtv?=
=?utf-8?q?3Ndu6G9XDoMk+C5VLZAPx7KJb5x5L90YaIM5Am4Te2ibuvw=3D?=
X-Received: by 2002:a05:6830:20c9:: with SMTP id
z9mr3486487otq.44.1583791794550;
Mon, 09 Mar 2020 15:09:54 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 9 Mar 2020 18:09:43 -0400
Message-ID:
<CAMm+LwgWvPjf6LC1S-S1537Rqzy4HHqKg+NVDO8yC5vS5wcRSA@mail.gmail.com>
To: IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000004ffd5a05a07343b3"
Archived-At:
<https://mailarchive.ietf.org/arch/msg/cfrg/7o64KJ9gZ1FepITTjZFgFBuRIJM>
Subject: [Cfrg] New versions of ECDH Threshold modes
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: Mon, 09 Mar 2020 22:10:04 -0000
All, Two updated drafts describing threshold modes for the CFRG ECDH curves have been submitted. These are on the agenda for Vancouver with a proposal to adopt as working group items: https://www.ietf.org/id/draft-hallambaker-threshold-02.html https://www.ietf.org/id/draft-hallambaker-threshold-sigs-02.html Note that since the documents were written to the HTML format it is VERY STRONGLY recommended you read these. They make use of math superscripts etc. I have been in contact with the authors of FROST at Waterloo but we have not been able to merge our proposals yet. But we expect to be able to do this if the work item is adopted. The main change from previous versions of the draft are to reorganize the material so that the Shamir Secret Sharing modes are described in the base document to allow their use for n>t decryption as well as for signature. The VSS scheme from FROST should go there as well. One major change to the signature scheme is that it allows 'stateless' generation of the final threshold share. This addresses what was the major concern for me in the earlier schemes which was that the requirement to keep track of the values r_i/R_i to avoid reuse was inevitably a drain on resources. The new approach does not solve the general problem but does address the concern of implementation at signature services, HSMs and the like. The only drawback to the new approach is that the party performing final signature generation step has to derive the value k. Which means that it has to support the specific signature scheme used. This is not a major concern for traditional HSMs which are only rated for specific algorithms anyway. It could be a concern for on CPU crypto co-processors. PHB
- [Cfrg] New versions of ECDH Threshold modes Phillip Hallam-Baker