Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock (
) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
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:
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 support 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 | TF succinct & verifiable-deterministic signatures | Sign |
| TF-QR signatures | Sign | |
| C2.2: PKE | TF-QR public-key encryption (PKE) | Decrypt; encrypt (a secret value) |
| C2.3: KA | Low-round multi-party key-agreement (KA) | Single-party primitives |
| C2.4: Symmetric | TF blockcipher/PRP | Encipher/decipher |
| TF key-derivation / key confirmation | PRF and hash function | |
| C2.5: Keygen | Any of the above | Keygen |
| C2.6: Advanced | TF fully-homomorphic encryption (FHE) | Decryption; keygens |
| TF identity-based encryption (IBE), attribute-based encryption (ABE) | Decryption; keygens | |
| C2.7: ZKPoK | ZKPoK of private key | ZKPoK.Generate |
| C2.8: Gadgets | Garbled circuit (GC) | GC.generate; GC.evaluate |
TF-QR is a desired combination for any type of scheme; some examples show just TF to convey that it is welcome even if not QR.
Legend: 2KE = pair-wise key-establishment; 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.
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.
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.
To access detailed material about the NIST-organized workshops, check the "Events" page.
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.
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.
The MPTC project has received useful community feedback about the multi-party threshold setting.
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.
The NIST reports on threshold schemes have benefited from public comments, as described in:
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.
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).
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
Security and Privacy: digital signatures, encryption, key management, message authentication, post-quantum cryptography, random number generation, secure hashing
Activities and Products: standards development