[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