9 min read
On this page

Cryptographic Protocols

Key Exchange

Noise Framework

A framework for building cryptographic protocols based on Diffie-Hellman key exchange and symmetric cryptography.

Core concept: A Noise protocol is defined by a handshake pattern that specifies the sequence of DH operations and message flows. The pattern determines the security properties achieved.

Components:

  • CipherState: Symmetric encryption state (key k, nonce n). Encrypts/decrypts with AEAD.
  • SymmetricState: Maintains chaining key ck and handshake hash h. MixKey() processes DH outputs through HKDF. MixHash() absorbs transcript data.
  • HandshakeState: Manages ephemeral and static DH keys, executes the handshake pattern.

Message tokens: e (send ephemeral public key), s (send static public key, possibly encrypted), ee/es/se/ss (perform DH between specified key pairs and mix result into symmetric state).

Common patterns:

  • NN: No authentication. -> e, <- e, ee. Minimal, forward-secret after one round trip.
  • NK: Client authenticates server (knows server's static key). <- s, -> e, es, <- e, ee.
  • XX: Mutual authentication with identity hiding. -> e, <- e, ee, s, es, -> s, se.
  • IK: Like XX but client reveals identity in first message (one fewer round trip). Used by Signal as the basis for X3DH + initial message.
  • KK: Both parties know each other's static keys. -> e, es, ss, <- e, ee, se. Full mutual authentication from first message.

Security properties per pattern: Each token provides specific guarantees (forward secrecy, identity hiding, resistance to key compromise impersonation). The Noise Explorer tool formally analyzes these properties.

Applications: WireGuard VPN uses Noise IKpsk2 (IK pattern with pre-shared symmetric key). Lightning Network uses Noise XK.

Signal Protocol: X3DH

Extended Triple Diffie-Hellman, the Signal Protocol's key agreement for asynchronous messaging.

Keys:

  • Identity key (IK): Long-term Curve25519 key pair
  • Signed prekey (SPK): Medium-term key, signed by IK, rotated periodically
  • One-time prekey (OPK): Single-use keys uploaded to server in batches

Protocol (Alice initiates with Bob):

  1. Alice fetches Bob's key bundle from server: {IK_B, SPK_B, Sig(IK_B, SPK_B), OPK_B}
  2. Alice verifies SPK_B signature
  3. Alice generates ephemeral key EK_A
  4. Computes four DH values:
    • DH1 = DH(IK_A, SPK_B) -- mutual authentication
    • DH2 = DH(EK_A, IK_B) -- forward secrecy from ephemeral
    • DH3 = DH(EK_A, SPK_B) -- forward secrecy
    • DH4 = DH(EK_A, OPK_B) -- replay protection (optional, if OPK available)
  5. SK = KDF(DH1 || DH2 || DH3 || DH4) -- shared secret initializes the Double Ratchet

Properties: Forward secrecy (compromised long-term keys don't decrypt past messages), asynchronous (Bob need not be online), cryptographic deniability (no third-party-verifiable proof of communication).

Signal Protocol: Double Ratchet

Provides continuous forward secrecy and break-in recovery for ongoing conversations.

Three ratchets combined:

  1. DH ratchet: Each message exchange includes new ephemeral DH keys. A new DH output ratchets the root key, deriving a fresh chain key. This provides post-compromise security (break-in recovery).
  2. Symmetric-key ratchet (sending/receiving chain): Each chain key derives the next chain key and a message key via KDF. Chain keys are deleted after use, providing forward secrecy within a DH ratchet epoch.
  3. Root chain: KDF chain connecting DH ratchet steps, ensuring all key material flows from the initial shared secret and subsequent DH outputs.

Message flow:

  • Alice sends: derives message key from her sending chain, encrypts message, includes her current DH ratchet public key
  • Bob receives: if new DH public key from Alice, performs DH ratchet step (new root key, new receiving chain), then derives message key from receiving chain, decrypts

Out-of-order messages: Bob stores skipped message keys (bounded) to handle reordering. Each message includes a counter for its position in the chain.

Header encryption: Optional extension encrypts the DH public key and counters in message headers, hiding metadata.

PAKE: Password-Authenticated Key Exchange

Establish a shared session key from a (possibly low-entropy) password, resistant to offline dictionary attacks.

OPAQUE

An asymmetric PAKE (aPAKE) where the server never learns the password, even during registration.

Components:

  • OPRF (Oblivious Pseudorandom Function): Client sends blinded password to server, receives PRF evaluation without server learning the password. Based on (EC)DH: client sends H(pwd)^r, server returns (H(pwd)^r)^k, client unblinds to H(pwd)^k.
  • Envelope: Encrypted client credentials stored on server. Encrypted under a key derived from the OPRF output. Contains the client's private key and server's public key.

Registration:

  1. Client computes OPRF with server to derive rwd = PRF(k, pwd)
  2. Client generates key pair, creates envelope encrypted under rwd
  3. Server stores {OPRF key k, envelope, client public key}

Login:

  1. Client initiates OPRF, derives rwd, decrypts envelope to recover keys
  2. Client and server execute authenticated key exchange (e.g., SIGMA or TripleDH) using recovered keys
  3. Server never sees or stores the password (only the OPRF key)

Security: Resists offline dictionary attacks (server compromise yields encrypted envelope, not password hashes). Pre-computation attacks require the OPRF key. Stronger than SRP or traditional password hashing.

IETF standardization: draft-irtf-cfrg-opaque, being actively developed. OPAQUE is the recommended aPAKE for new deployments.

TLS 1.3 Internals

Major redesign from TLS 1.2, removing legacy cryptography and reducing round trips.

Handshake

Full handshake (1-RTT):

  1. ClientHello: Supported cipher suites, key_share (DH public values for predicted groups), supported_groups, signature_algorithms, pre_shared_key (if resuming)
  2. ServerHello: Selected cipher suite, key_share (server's DH public value). Immediately followed by EncryptedExtensions, CertificateRequest (optional), Certificate, CertificateVerify, Finished -- all encrypted under handshake keys
  3. Client: Certificate (if requested), CertificateVerify, Finished -- encrypted under handshake keys
  4. Application data flows under application traffic keys

0-RTT (Early Data): Client sends encrypted application data in the first flight using a pre-shared key from a previous session. Enables zero round-trip latency but sacrifices replay protection (server must implement replay defenses at the application layer).

Key Schedule

Derived via HKDF (HMAC-based Key Derivation Function):

PSK (or 0) -> Early Secret -> [early traffic keys]
     |
     v (+ ECDHE shared secret)
Handshake Secret -> [handshake traffic keys]
     |
     v
Master Secret -> [application traffic keys, resumption secrets]

Each derivation uses HKDF-Extract (combine secrets) and HKDF-Expand-Label (derive specific keys with context-binding labels and transcript hashes).

Cipher Suites

TLS 1.3 supports only AEAD cipher suites:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

Key exchange separated from cipher suite: ECDHE with x25519 or P-256 (mandatory), P-384, P-521, or post-quantum hybrids (x25519kyber768).

Removed from TLS 1.2: RSA key transport, static DH, CBC mode, RC4, MD5, SHA-1, export ciphers, compression, renegotiation.

Secure Group Messaging: MLS (Messaging Layer Security)

IETF standard (RFC 9420) for scalable end-to-end encrypted group communication.

Problem: Signal's Double Ratchet is pairwise -- group messages require O(n) encryptions (sender-keys optimization helps but limits forward secrecy). MLS provides O(log n) overhead per group operation.

Core data structure: Ratchet tree (binary tree where leaves represent group members). Each node stores a DH key pair. The root key encrypts group messages.

Operations:

  • Add: New member added as leaf. Updating the path from the new leaf to the root costs O(log n) DH operations.
  • Update: Member refreshes their leaf key and updates the path to root. Provides post-compromise security.
  • Remove: Blank the removed member's leaf. Path updated.
  • Commit: A member proposes changes, computes new group state, broadcasts commit message with encrypted path secrets.

TreeKEM protocol: The key schedule for ratchet tree updates. Each internal node's key is derived from its children. Updating a path involves encrypting new node secrets to the co-path nodes (siblings along the path to root).

Properties: Forward secrecy (past messages secure after update), post-compromise security (future messages secure after update), sender authentication, group membership agreement.

Electronic Voting

Cryptographic voting requires: ballot secrecy (no one learns individual votes), verifiability (voters can check their vote was counted), integrity (only eligible voters, no double voting), and coercion resistance (voters cannot prove how they voted to a coercer).

End-to-end verifiable voting (E2E-V):

  • Cast-as-intended: Voter verifies their encrypted ballot encodes their actual choice. Achieved via cut-and-choose (Benaloh challenge): voter can audit any ballot before casting (audited ballots are spoiled, not cast).
  • Recorded-as-cast: Voter checks that their encrypted ballot appears on the public bulletin board.
  • Tallied-as-recorded: Anyone can verify the tally is correct with respect to posted encrypted ballots. Achieved via homomorphic tallying or verifiable shuffle (mix-net).

Homomorphic tallying: Using Paillier or ElGamal, multiply all encrypted votes to obtain encrypted tally. Decrypt only the aggregate. Works for simple elections (yes/no, choose-k).

Mix-nets (Chaum): Sequence of servers that shuffle and re-encrypt ballots. Each server proves (in ZK) that its output is a permutation of its input. Final decryption reveals individual votes in random order. Supports complex ballot types.

Coercion resistance: Receipt-freeness (voter cannot produce proof of vote to a coercer). Achieved by JCJ/Civitas protocol: voters can generate fake credentials; only real credentials contribute to the tally.

Anonymous Credentials

Enable users to prove possession of credentials (attributes) without revealing their identity or allowing linkability across presentations.

Camenisch-Lysyanskaya (CL) credentials: Based on CL signatures (special RSA-based or pairing-based signatures on committed values).

  • Issuance: User commits to attributes, obtains a blind signature from the issuer
  • Presentation: User proves in ZK that they possess a valid signature on attributes satisfying a policy, without revealing the signature or unnecessary attributes
  • Selective disclosure: Reveal only required attributes (e.g., prove age >= 18 without revealing birthdate)
  • Unlinkability: Different presentations of the same credential are computationally unlinkable

BBS+ signatures: Modern alternative using pairing-based signatures. Efficient selective disclosure and zero-knowledge proofs. Shorter signatures and proofs than CL.

Applications: Digital identity (EU eIDAS, mDL mobile driver's licenses), access control, privacy-preserving authentication, decentralized identity (W3C Verifiable Credentials).

DAA (Direct Anonymous Attestation): TPM-based anonymous credentials for platform attestation. Proves a device has a valid TPM without identifying which device. Uses group signatures or CL-signature variants.

Oblivious RAM (ORAM)

Not a protocol per se, but a cryptographic primitive enabling memory access pattern hiding. Included here for its role in protocol construction.

Problem: Even with encrypted storage, access patterns reveal information. ORAM hides which addresses are accessed, whether reads or writes, and whether the same address is accessed twice.

Path ORAM (Stefanov et al.): Store data in a binary tree of encrypted buckets. Each block mapped to a random leaf (position map). Access: read entire path from root to leaf, find the block, re-encrypt and write back to a new random path. Stash holds overflow blocks. Amortized O(log^2 N) bandwidth overhead.

Applications: Oblivious computation (hiding data access in MPC), private database queries, secure processor design (protecting against memory bus snooping).