169-pq-crypto.rst

Post-Quantum Crypto Protocols

Contents

• Overview
• Goals
• Non-Goals
• Threat Model
• Design
  • Key Exchange
  • Signatures
  • Legal Combinations
  • New Crypto Required
  • Alternatives
• Specification
  • Common Structures
    • PublicKey
    • PrivateKey
    • SigningPublicKey
    • SigningPrivateKey
    • Signature
    • Key Certificates
    • Destination sizes
    • RouterIdent sizes
  • Handshake Patterns
  • Noise Handshake KDF
    • Defined ML-KEM Operations
    • Alice KDF for Message 1
    • Bob KDF for Message 1
    • Bob KDF for Message 2
    • Alice KDF for Message 2
    • Alice/Bob KDF for split()
  • Ratchet
    • 1b) New session format (with binding)
    • 1g) New Session Reply format
    • KDF for Payload Section Encrypted Contents
  • NTCP2
    • 1) SessionRequest
    • 2) SessionCreated
    • 3) SessionConfirmed
    • Key Derivation Function (KDF) (for data phase)
  • SSU2
    • Long Header
    • SessionRequest (Type 0)
    • SessionCreated (Type 1)
    • SessionConfirmed (Type 2)
    • KDF for data phase
    • Relay and Peer Test
    • Issues
  • Streaming
  • SU3 Files
  • Other Specs
• Overhead Analysis
  • Key Exchange
  • Signatures
• Security Analysis
  • Handshakes
  • Signatures
• Type Preferences
• Implementation Notes
  • Library Support
  • Reliability
  • Structure Sizes
  • NetDB
  • Ratchet
  • NTCP2
  • SSU2
• Router Compatibility
  • Transport Names
  • Router Enc. Types
    • Type 5/6/7 Routers
    • Type 4 Routers
    • NTCP2 Alternatives
    • SSU2 Alternatives
    • Recommendations
  • Router Sig. Types
  • LS Enc. Types
  • Dest. Sig. Types
• Priorities and Rollout
• Migration
• Issues
• References

Overview

While research and competition for suitable post-quantum (PQ) cryptography have been proceeding for a decade, the choices have not become clear until recently.

We started looking at the implications of PQ crypto in 2022 [FORUM].

TLS standards added hybrid encryption support in the last two years and it now is used for a significant portion of encrypted traffic on the internet due to support in Chrome and Firefox [CLOUDFLARE].

NIST recently finalized and published the recommended algorithms for post-quantum cryptography [NIST-PQ]. Several common cryptography libraries now support the NIST standards or will be releasing support in the near future.

Both [CLOUDFLARE] and [NIST-PQ] recommend that migration start immediately. See also the 2022 NSA PQ FAQ [NSA-PQ]. I2P should be a leader in security and cryptography. Now is the time to implement the recommended algorithms. Using our flexible crypto type and signature type system, we will add types for hybrid crypto, and for PQ and hybrid signatures.

Goals

• Select PQ-resistant algorithms
• Add PQ-only and hybrid algorithms to I2P protocols where appropriate
• Select best variants after implementation, testing, analysis, and research
• Add support incrementally and with backward compatibility

Non-Goals

• Don't change one-way (Noise N) encryption protocols

Threat Model

• Routers at the OBEP or IBGW, possibly colluding, storing garlic messages for later decryption (forward secrecy)
• Network observers storing transport messages for later decryption (forward secrecy)
• Network participants forging signatures for RI, LS, streaming, datagrams, or other structures

Design

We will support the NIST FIPS 203 and 204 standards [FIPS203] [FIPS204] which are based on, but NOT compatible with, CRYSTALS-Kyber and CRYSTALS-Dilithium (versions 3.1, 3, and older).

Key Exchange

We will support key exchange in the following protocols:

Proto	Noise Type	Support PQ?	Support Hybrid?
NTCP2	XK	no	yes
SSU2	XK	no	yes
Ratchet	IK	no	yes
TBM	N	no	no
NetDB	N	no	no

PQ KEM provides ephemeral keys only, and does not directly support static-key handshakes such as Noise XK and IK. While there is some recent research [PQ-WIREGUARD] on adapting Wireguard (IK) for pure PQ crypto, there are several open questions, and this approach is unproven.

Noise N does not use a two-way key exchange and so it is not suitable for hybrid encryption.

So we will support hybrid encryption only, for NTCP2, SSU2, and Ratchet. We will define the three ML-KEM variants as in [FIPS203], for 3 new encryption types total. Hybrid types will only be defined in combination with X25519.

The new encryption types are:

Type	Code
MLKEM512_X25519	5
MLKEM768_X25519	6
MLKEM1024_X25519	7

Overhead will be substantial. Typical message 1 and 2 sizes (for XK and IK) are currently around 100 bytes (before any additional payload). This will increase by 8x to 15x depending on algorithm.

Signatures

We will support PQ and hybrid signatures in the following structures:

Type	Support PQ?	Support Hybrid?
RouterInfo	yes	yes
LeaseSet	yes	yes
Streaming SYN/SYNACK/Close	yes	yes
Repliable Datagrams	yes	yes
Datagram2 (prop. 163)	yes	yes
I2CP create session msg	yes	yes
SU3 files	yes	yes
X.509 certificates	yes	yes
Java keystores	yes	yes

So we will support both PQ-only and hybrid signatures. We will define the three ML-DSA variants as in [FIPS204], for 6 new signature types total. Hybrid types will only be defined in combination with Ed25519. We will use the standard ML-DSA, NOT the pre-hash variants (HashML-DSA).

The new signature types are:

X.509 certificates and other DER encodings will use the composite structures and OIDs defined in [COMPOSITE-SIGS].

Overhead will be substantial. Typical Ed25519 destination and router identity sizes are 391 bytes. These will increase by 3.5x to 6.8x depending on algorithm. Ed25519 signatures are 64 bytes. These will increase by 38x to 76x depending on algorithm. Typical signed RouterInfo, LeaseSet, repliable datagrams, and signed streaming messages are about 1KB. These will increase by 3x to 8x depending on algorithm.

As the new destination and router identity types will not contain padding, they will not be compressible. Sizes of destinations and router identities that are gzipped in-transit will increase by 12x - 38x depending on algorithm.