**Session Date/Time:** 25 Jul 2022 14:00

# cfrg

## Summary

The cfrg session covered updates on several in-flight documents and presented new work for potential adoption. Key discussions included the BBS signature scheme, the FROST threshold signature, updates on Key Binding and Blind RSA drafts, and the CPACE PAKE. A significant portion of the session was dedicated to an update on the NIST Post-Quantum Cryptography (PQC) standardization process, highlighting selected algorithms for key exchange and signatures, associated challenges (IPR, implementation complexity), and a proposal for a CFRG draft for Kyber.

## Key Discussion Points

*   **Chair Updates (00:30:03)**
    *   The **ASH-to-Curve** document is proceeding to IESG review.
    *   **Madsen/CFRG Deterministic Signature with Noise**: Discussed IPR concerns (even with expired IPR). Chairs are consulting the IRTF chair on the path forward, noting interest in the topic but conditional participation from many.
    *   **Aegis**: Adoption call is extended due to recent support. Comments are encouraged on the mailing list.

*   **BBS Signature Scheme (00:32:06)**
    *   **Presenter**: Tobias.
    *   **Description**: A digital signature scheme supporting selective disclosure (multi-message signing), proof of possession, and unlinkable proofs via a Zero-Knowledge Proof (ZKP) protocol.
    *   **Technical Details**:
        *   Pairing-based, using Type 3 pairings (e.g., BLS12-381 curve). Curve-agnostic but current spec uses BLS12-381.
        *   Three parties: Signer, Prover, Verifier.
        *   Concepts: A "header" (always revealed) and "messages" (selectively disclosable).
        *   **Properties**: Signature is constant size (112 bytes for BLS12-381), O(N) efficiency for signing/verification (or constant time if no selective disclosure). Proof size is linear to the number of hidden messages.
        *   **Security**: Proofs provide integrity/authenticity of revealed messages/header, prove possession of the signature, and are unlinkable (generated under non-interactive ZKP). Unlinkability refers to the issuer's public key representing a group, providing anonymity within that group.
    *   **Benchmarks**: Sub-half millisecond for header-only signing/verification, linear scaling with messages.
    *   **Use Cases**: Privacy-preserving anonymous credentials, Proof-of-Possession (PoP) enabled security access tokens (e.g., for OAuth2), non-correlating security token proofs.
    *   **CFRG Fit**: Aligns with existing work on pairing-friendly curves, BLS signatures, and hash-to-curve.
    *   **IETF Relevance**: Potential for JSON Web Proofs (JWP) and Privacy Pass.
    *   **Request**: Called for adoption of the draft. Future work includes broader review, cipher suite definition refinement, and clarifying extensibility points.

*   **FROST (Flexible Round-Optimized Schnorr Threshold) (00:48:00)**
    *   **Presenter**: Deirdre.
    *   **Description**: A two-round threshold Schnorr signature scheme allowing *t*-of-*n* signers, producing a signature indistinguishable from a single-signer Schnorr signature.
    *   **Protocol Overview**: Requires prior key generation. Round 1: participants generate nonces and publish commitments. Round 2: participants use commitments and key shares to generate signature shares, which a coordinator aggregates into the final signature.
    *   **Cipher Suites**: Fully specified for Ristretto prime order group, P-256, Ed25519, and Ed448. API is compatible with Ed25519 and Ed448 verification. Multiple interoperable implementations exist.
    *   **Latest Updates (v7)**:
        *   A proposed order T scalar optimization was reverted due to concerns about inter-round malleability (difficulty in proving the same set of signers participated in both rounds).
        *   Clarified per-cipher-suite verification, particularly for Ed25519/Ed448 to emphasize the necessity of co-factor checks for security. Provided a general verification procedure for prime-order groups.
    *   **Request**: Seeking Crypto Panel review and wider CFRG review for clarity, ambiguity, technical correctness, and suitability for application protocols.
    *   **Discussion**: Concerns raised about RFC 8032's "looseness" regarding Ed25519 verification (co-factor check). Presenter strongly advocated for updating RFC 8032, noting that robust implementations already include the co-factor check.

*   **Key Binding for Signature Schemes (00:58:24)**
    *   **Presenter**: Chris Wood.
    *   **Description**: An adopted draft providing an extension to digital signature schemes for "key blinding," allowing unlinkability where the verifier does not learn which specific public key was used to generate a signature. This is critical for applications like Tor and Privacy Pass.
    *   **Mechanism**: Adds three new functions (`BlindKeyGen`, `BlindPublicKey`, `SignWithBlindedKey`) to a classical scheme, with an optional `UnblindPublicKey`.
    *   **Update**: Introduced a "context" string to `BlindPublicKey` for application-defined optionality. This allows applications (e.g., Privacy Pass) to enable unblinding by using an empty context, while others (e.g., Tor) can prevent it by including unique identifiers in the context.
    *   **Status**: Implemented for EdDSA and ECDSA, with security analysis under peer review. Considered feature complete.

*   **Blind RSA Signatures (01:07:56)**
    *   **Presenter**: Chris Wood.
    *   **Update**: A recent security review highlighted concerns with the draft when the signer's public key is *maliciously generated* affecting the blindness property. This is particularly problematic for *deterministic variants* (e.g., full domain hash, PSS with zero salt) and *low entropy inputs* (e.g., voting applications). It is *not* an issue for high entropy inputs (e.g., Privacy Pass with a fresh 32-byte nonce).
    *   **Proposed Resolution**:
        *   Remove all deterministic variants from the draft.
        *   Require PSS with a salt length matching the underlying hash digest.
        *   Add guidance for applications with low entropy inputs to add local entropy (which has API implications as the verifier needs to consume this randomness).
        *   Leaning towards an external API approach for handling local randomness.

*   **CPACE (Password-Authenticated Key Exchange) (01:14:05)**
    *   **Presenter**: Thorsten.
    *   **Update (v6)**: The draft's introduction was completely rewritten to focus on application architects, implementers, and testers, following the completion of its security analysis. No changes were made to the core technical content of the scheme itself.
    *   **Request**: Seeking broader review, including from native English speakers, and eventual Crypto Review Panel review.

*   **NIST Post-Quantum Cryptography (PQC) Process Update (01:17:02)**
    *   **Presenters**: Sofia and Tom Biggs.
    *   **Key Encapsulation Mechanisms (KEMs)**:
        *   **Kyber** was chosen for standardization. It is fast, efficient, and lattice-based.
        *   **Note**: KEMs are interactive and not a direct replacement for non-interactive Diffie-Hellman in protocols like Signal.
        *   Other KEMs (McEliece, BIKE, HQC, SIKE) are still in the running but require more research/maturity. SIKE offers very small ciphertexts but is slow and new.
        *   No non-interactive post-quantum key exchange solution with high confidence currently exists.
    *   **Digital Signature Algorithms**: Three were chosen for standardization.
        *   **Dilithium**: General-purpose, main recommendation. Larger public key/signature sizes than classical, but faster computation. Lattice-based.
        *   **Falcon**: Better sizes than Dilithium. Requires floating-point arithmetic and is *very* difficult to implement correctly (NIST recommends only if correctly implemented). Lattice-based.
        *   **SPHINCS+**: Stateless hash-based signature. Nice public key size, but larger signatures and computationally slower. Chosen to provide *different security assumptions* (not lattice-based) for diversification.
        *   **Note**: Existing IETF hash-based signatures (XMSS, LMS) are stateful; SPHINCS+ offers statelessness (important for key backups).
    *   **NIST Next Steps**: Process not ended. NIST is advancing certain algorithms to a fourth round and calling for new signature proposals, especially for schemes with smaller sizes suitable for network protocols. NIST standards are not expected before 2030.
    *   **Libraries**: `liboqs` (safety checks, bindings), `pqclean`, `pqm4` (embedded) are available.
    *   **IPR Concerns for Kyber**: Kyber faces plausible patent concerns. NIST has agreements with patent holders, but these are not public. NIST has stated that if patent issues are not resolved by the end of 2022, they will advance NTRU instead of Kyber.
    *   **Non-Lattice Based Signatures**: UOV/Rainbow (very large public keys, small signatures) is a strong candidate for future signature calls.

*   **Kyber Standardization Draft Proposal (01:35:46)**
    *   **Presenter**: Bass Westerman.
    *   **Proposal**: To create an IETF RFC draft for Kyber *now*, ahead of NIST's final standardization (expected 2024).
    *   **Rationale**:
        *   Provide a reference for early adopters to prevent fragmentation.
        *   Include machine-readable specifications (e.g., Python) that NIST typically does not.
        *   Facilitate IETF engagement, as the Kyber team is eager to assist.
        *   Enable early usage in protocols like TLS (code points are cheap).
    *   **Discussion**:
        *   Interest was expressed for its utility in establishing PQC-hardened shared secrets and routes of trust, even if the final specification diverges slightly from NIST.
        *   The importance of eventually matching NIST specifications to avoid fragmentation was highlighted.
        *   TLS chairs did not have immediate comments.

## Decisions and Action Items

*   **Chairs**:
    *   Consult with the IRTF chair regarding IPR concerns for the Madsen/CFRG deterministic signature document.
    *   Extend the adoption call for the Aegis draft.
    *   Discuss the BBS signature scheme adoption call and bring it to the mailing list.
*   **BBS Signature Scheme**: The draft author is seeking adoption.
*   **FROST**: The draft authors are seeking Crypto Panel review and wider CFRG review.
*   **Key Binding for Signature Schemes**: The authors will merge the PR introducing the context string and then solicit Crypto Review Panel review.
*   **Blind RSA Signatures**: The authors will seek confirmation on the mailing list regarding any concrete applications requiring deterministic signing. They will then submit a Pull Request to implement the proposed resolution (removing deterministic variants, requiring PSS with matching salt length, and adding text for low-entropy inputs).
*   **CPACE**: The authors are requesting broader review, including from native English speakers, and eventual Crypto Review Panel review.
*   **NIST PQC Follow-up**: Scott Fluhrer indicated intent to submit a CFRG draft for NTRU as a potential alternative to Kyber, especially given IPR uncertainties.
*   **Kyber CFRG Draft**: Bass Westerman proposed creating a CFRG draft for Kyber; this will likely proceed given the expressed interest, though no formal adoption call was made.

## Next Steps

*   **CFRG Chairs**: Continue consultation on IPR, monitor Aegis adoption call, and initiate BBS adoption call on the mailing list.
*   **Draft Authors**: Proceed with the specified next steps for their respective drafts (merging PRs, soliciting reviews).
*   **Community**: Review and comment on the Aegis adoption call, the Blind RSA proposed resolution, CPACE updates, and engage in discussions around the proposed Kyber CFRG draft.
*   **Scott Fluhrer**: Proceed with drafting and submitting an NTRU draft to CFRG.