| |
|
| |
| | KangarooTwelve and TurboSHAKE |
| |
|
This document defines four eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128 and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. |
| | Additional Parameter sets for HSS/LMS Hash-Based Signatures |
| |
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | CPace,a balanced composable PAKE |
| |
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. |
| | Usage Limits on AEAD Algorithms |
| |
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. |
| | The OPAQUE Augmented PAKE Protocol |
| |
| | draft-irtf-cfrg-opaque-18.txt |
| | Date: |
21/11/2024 |
| | Authors: |
Daniel Bourdrez, Hugo Krawczyk, Kevin Lewi, Christopher Wood |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-14.txt |
| | Date: |
10/01/2025 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). |
| | Key Blinding for Signature Schemes |
| |
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. |
| | The AEGIS Family of Authenticated Encryption Algorithms |
| |
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. |
| | Hedged ECDSA and EdDSA Signatures |
| |
|
Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators. |
| | The BBS Signature Scheme |
| |
|
This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs-of-knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages. |
| | Deterministic Nonce-less Hybrid Public Key Encryption |
| |
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. |
| | Properties of AEAD Algorithms |
| |
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group. |
| | Implementation Guidance for the PKCS #1 RSA Cryptography Specification |
| |
|
This document specifies additions and amendments to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side-channel attacks. It also deprecates the RSAES- PKCS-v1_5 encryption scheme, but provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. |
| | Partially Blind RSA Signatures |
| |
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. |
| | Hybrid PQ/T Key Encapsulation Mechanisms |
| |
|
This document defines generic techniques to achive hybrid post- quantum/traditional (PQ/T) key encapsulation mechanisms (KEMs) from post-quantum and traditional component algorithms that meet specified security properties. It then uses those generic techniques to construct several concrete instances of hybrid KEMs. |
| | Blind BBS Signatures |
| |
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/BasileiosKal/blind-bbs-signatures. |
| | BBS per Verifier Linkability |
| |
|
The BBS Signatures scheme defined in [I-D.irtf-cfrg-bbs-signatures], describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, monetization etc.. This document presents the use of pseudonyms with BBS proofs. A pseudonym, is a value that will remain constant each time a Prover presents a BBS proof to the same Verifier, but will be different (and unlinkable), when the Prover interacts with a different Verifier. This provides a way for a recipient (Verifier) to track the presentations intended for them, while also hindering them from tracking the Prover's interactions with other Verifiers. |