U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Multi-Party Threshold Cryptography MPTC

Overview

The multi-party paradigm of threshold cryptography enables threshold schemes, for a secure distribution of trust in the operation of cryptographic primitives.


NISTIR 8214C ipd — NIST First Call for multi-party threshold schemes (initial public draft) — was published on 2023-Jan-25. This is the draft of a call that motivates the community of expert stakeholders to submit proposals of threshold schemes (including technical specification, security analysis, open-source reference implementation, performance evaluation) for primitives in two categories:

  • Cat1: selected NIST-specified primitives (see Table 1).
  • Cat2: other primitives not specified by NIST (see Table 2).

Public comments about the draft call should be sent by email, as detailed in the publication page. There is a proposed template file for comments. Once the final call is published and concrete threshold schemes are submitted, the collected reference material will be analyzed and the conclusions will the future development of recommendations and guidelines.

Table 1. Subcategories of interest in Cat1

Subcategory: Type Families of specifications Section (in the call)
C1.1: Signing EdDSA sign, ECDSA sign, RSADSA sign A.1
C1.2: PKE RSA encryption, RSA decryption A.2
C1.3: 2KA ECC-CDH, ECC-MQV A.3
C1.4: Symmetric AES encipher/decipher, KDM/KC (to support 2KE) A.4
C1.5: Keygen ECC keygen, RSA keygen, bitstring keygen A.5

Legend: 2KA = pair-wise key-agreement; 2KE = pair-wise key-establishment; AES = Advanced Encryption Standard; CDH = Cofactor Diffie-Hellman; ECC = Elliptic-curve cryptography; ECDSA = Elliptic-curve Digital Signature Algorithm; EdDSA = Edwards-Curve Digital Signature Algorithm; KC = Key confirmation; KDM = Key derivation mechanism; Keygen = Key-generation; MQV = Menezes-Qu-Vanstone; PKE = Public-key encryption; RSA = Rivest-Shamir-Adleman; RSADSA = RSA digital signature algorithm.

Table 2. Subcategories and examples of primitives in Cat2

Subcategory: Type Example scheme Example primitive
C2.1: Signing Succinct & verifiable-deterministic signatures Signing
C2.2: PKE TF-QR public-key encryption (PKE) Decryption/encryption
C2.3: KA Low-round multi-party key-agreement (KA) Single-party primitives
C2.4: Symmetric TF-QR blockcipher/PRP; TF-QR KC/KD Encipher/decipher; PRF and hash function
C2.5: Keygen Any of the above Keygen
C2.6: Advanced QR FHE; IBE; ABE Decryption; Keygens
C2.7: ZKPoK ZKPoK of private key ZKPoK.Generate
C2.8: Gadgets Garbled circuit (GC) GC.generate; GC.evaluate

Legend:  2KE = pair-wise key-establishment; KC = Key confirmation; KD = Key derivation; Keygen = key-generation; PKE = Public-key encryption; PRF = pseudorandom function (family); PRP = pseudorandom permutation (family); QR = quantum resistant; TF = threshold friendly; ZKPoK = Zero-knowledge proof of knowledge.

Documents:

Presentations:

Note: The old "single-device track" about masked circuits for block-ciphers has become a separate project.

The multi-party threshold paradigm

Using a “secret sharing” mechanism, the secret key is split across multiple "parties". Then, if some (up to a threshold f out of n) of these parties are corrupted, the key secrecy remains uncompromised. The cryptographic operation that depends on the key is then performed via a threshold scheme, using secure multi-party computation (MPC), so that the key does not have to be reconstructed (i.e., the secret-sharing remains in place even during the computation). This threshold approach can be used to distribute trust across various operators, and is also useful to avoid various single-points of failure in the implementation.

Which cryptographic primitives can be thresholdized?

Threshold schemes can be applied to any cryptographic primitive, such as key generation, signing, encryption and decryption. The MPTC project will consider devising recommendations and guidelines pertinent to threshold schemes that are interchangeable (in the sense of NISTIR 8214A, Section 2.4) with selected primitives of interest. For example, a threshold-produced signature should be verifiable by the verification algorithm that is used for signatures produced by the conventional (non-threshold) algorithm.

Progress and milestones 

To access detailed material about the NIST-organized workshops, check the "Events" page.

  • November 46, 2020: The NIST Workshop on Multi-Party Threshold Schemes (MPTS) 2020, organized by the NIST Threshold Cryptography project, obtained feedback toward criteria for multi-party threshold schemes. Here is the preliminary announcement: PDF. The workshop, held virtually, included 17 invited talks and 11 accepted briefs.
  • March 1112, 2019: The NIST Threshold Cryptography Workshop (NTCW) 2019 took place at NIST, in Gaithersburg Maryland, USA, with experts from industry, academia, and government. The submission deadline was December 17, 2018.

NIST Internal Reports (NISTIR):

So far, the main publications in the project are in the form of NIST Internal Reports (NISTIR), elaborated internally at NIST and made publicly available for comments and consultation.

  • NIST IR 8214C ipd: NIST First Call for Multi-Party Threshold Schemes
    • Final version: 2023
    • Public comments: due by 2023-Apr-10
    • Initial public draft: Published on 2023-Jan-25. DOI:10.6028/NIST.IR.8214C.ipd
  • NISTIR 8214B ipd: Notes on Threshold EdDSA/Schnorr Signatures
    • Final version: expected in the first half of 2023
    • Public comments: are being considered during the elaboration of the final version of the report.
    • Initial public draft: Published on 2022-Aug-12. DOI:10.6028/NIST.IR.8214B.ipd
  • NISTIR 8214A: NIST Roadmap Toward Criteria for Threshold Schemes for Cryptographic Primitives.
    • Final version: Published on 2020-Jul-07. DOI:10.6028/NIST.IR.8214A
    • Note: Initiated a discussion about the pertinence of considering the standardization of threshold schemes for cryptographic primitives.
    • Diff and public comments: The draft was open for public comments until 2020-Feb-10. The available "diff" highlights the changes between the draft and the final version and includes a table with the received comments.
    • Draft version: Published in the CSRC on 2019-Nov-08. DOI:10.6028/NIST.IR.8214A-draft
    • Note: The title in the draft was "Towards NIST Standards for Threshold Schemes for Cryptographic Primitives: A Preliminary Roadmap", which changed in the final version.
  • NISTIR 8214: Threshold Schemes for Cryptographic Primitives: Challenges and Opportunities in Standardization and Validation of Threshold Cryptography.
    • Final version: Published in the CSRC on 2019-Mar-01.
    • Note: presents a structured approach for exploring the space of threshold schemes for potential standardization, across two tracks: multi-party and single-device.
    • Diff and public comments: The draft was open for public comments until 2018-Oct-22. The available "diff" highlights the changes between the draft and the final version and includes a table with the received comments.
    • Draft version: Published in the CSRC on 2019-Jul-26.

Collaboration

The project will drive an open and transparent standardization process based on established NIST principles. The process involves engaging with and incorporating feedback from the community of stakeholders, including researchers and practitioners in academia, industry and government. To receive announcements pertinent to collaboration with the Threshold Cryptography project, consider subscribing to the MPTC-forum.

Specific collaboration is expected in the form of high-quality submissions to the upcoming NIST First Call for Multi-Party Threshold Schemes, and the subsequent public analysis of the set of submitted schemes.

Public feedback

The MPTC project has received useful community feedback about the multi-party threshold setting.

Call 2021a for Feedback on Criteria for Threshold Schemes:

An earlier related call for focused feedback on criteria for threshold schemes (Call 2021a) solicited anticipated comments on the following topics: scope of proposals; security idealization; security vs. adversary types; system model; threshold profiles; building blocks.

Feedback about NISTIR’s

The NIST reports on threshold schemes have benefited from public comments, as described in:

Feedback in NIST workshops

Topics of various presentation at NTCW 2019 and MPTS 2020:

  • Standardization setting: I1.2 (TC readiness), 2a1 (MPC settings), 2a2 (composability).

  • Threshold RSA keygen: 1a3 (honest majority threshold schemes).

  • Threshold ECDSA: [in 2019] I4.2, I.5.1 (a, b, c); [in 2021] 3a2, 3a3, 3c1, 3c2.

  • Threshold Schnorr/EdDSA: [in 2019] II4.; [in 2021] 1b2 (MPC-based EdDSA), 1b3 (prob. Schnorr), 1c1.

  • Threshold AES: 2b3.

  • Threshold RSA keygen: 3b1, 3b2.

  • Building blocks: garbled circuits (2b2, 2c1), OT (2b1), PCG (2a3), PVSS (1a2).

  • Platforms/frameworks/endeavors: I1.3, II4.3, 2c2, 2c3, 2c4, 2c5.

  • Implementation frameworks and attacks: 3a1 (attacks), 3b3 (frameworks).

  • Threshold post-quantum: I3.1, 1c2, 1c3.

  • Others applications/comments: II4.4, 1b1, 1c4.

  • Variants: II3.2, II4.2.

Legend of indices: For NTCW 2019, indices are Xyz, with X in {I, II} (day), y in {1,…,5} (session in the day), z in {1,2,3}. For MPTS 2020, indices are xyz, with x in {1,2,3} (day), y in {a,b,c} (session in the day), z in {1,…,5}.

Introductory presentations about the TC project can be found here: I1.1, 1a1

Created July 26, 2018, Updated February 03, 2023