2 posts tagged with "forward secrecy"

⚠️ WARNING: This document is not finished. The details in this document are subject to change.

End-to-end encrypted messaging for two people is a solved problem—Signal Protocol has set the gold standard. But what happens when you want to scale that security to group chats with dozens or hundreds of participants? Traditional pairwise encryption becomes a nightmare: N participants require N(N-1)/2 encrypted channels, each with its own key management overhead.

Enter MLS (Message Layer Security), the IETF's RFC 9420 standard designed specifically for scalable group messaging. MLS provides the same strong security guarantees as Signal Protocol—forward secrecy, post-compromise security, authentication—but does so efficiently for groups of any size.

In this article, we'll explore how MLS works, why it's a game-changer for group messaging, and walk through a complete browser-based implementation using the ts-mls library. We'll cover everything from the TreeKEM algorithm to practical P2P integration with WebRTC.

⚠️ NOTE: This is an experimental implementation for testing purposes. Post-quantum cryptography is an active area of research. While ML-KEM is a NIST standard, this JavaScript implementation has not undergone formal security audits. Use responsibly.

We're excited to announce that our P2P messaging application now supports quantum-resistant encryption using ML-KEM (CRYSTALS-Kyber), a NIST-standardized post-quantum key encapsulation mechanism. This addition brings quantum-resistant security to our cascading cipher system, providing protection against future quantum computing attacks.

What is Post-Quantum Cryptography?​

Quantum computers pose a significant threat to current public-key cryptography. While quantum computers are still in early stages, they could eventually break widely used algorithms like RSA, ECC (Elliptic Curve Cryptography), and Diffie-Hellman using Shor's algorithm. Quantum-resistant cryptography uses mathematical problems that quantum computers struggle to solve.

Current Vulnerabilities​

🔴 Vulnerable to Quantum Attacks:

• RSA (Shor's algorithm)
• Elliptic Curve Cryptography (Shor's algorithm)
• Diffie-Hellman key exchange (Shor's algorithm)

🟢 Quantum-Resistant:

• AES-256 (Grover's algorithm only reduces to AES-128 equivalent)
• SHA-256/SHA-3 (quantum advantage limited)
• ML-KEM (CRYSTALS-Kyber) - Lattice-based KEM
• ML-DSA (CRYSTALS-Dilithium) - Lattice-based signatures

The ML-KEM (CRYSTALS-Kyber) Standard​

ML-KEM (Modular Lattice-based Key Encapsulation Mechanism) is one of the first post-quantum algorithms standardized by NIST in 2024. It's designed as a key encapsulation mechanism (KEM) rather than direct encryption, making it ideal for establishing shared secrets between parties.

📚 Learn More:

• Crash Course: ML-KEM Beginner Tutorial - Quick introduction to ML-KEM concepts
• In-Depth Tutorial: ML-KEM Research Tutorial - Comprehensive technical deep dive

Key Properties:

• ⚡ Fast: ~30-50ms for key encapsulation/decapsulation
• 📦 Compact: 1184-byte public keys, 1088-byte encapsulated keys
• 🔒 Security: Based on Learning With Errors (LWE) problem
• 🎯 Standard: NIST FIPS 203 compliant
• 🌐 Pure JavaScript: No native dependencies

Integration with Cascading Cipher​

The ML-KEM implementation is integrated as a cipher layer in our cascading cipher architecture:

import {
  CascadingCipherManager,
  MLSCipherLayer,
  SignalCipherLayer,
  AESCipherLayer,
  MLKEMCipherLayer,  // New post-quantum layer
} from 'cryptography/CascadingCipher';

How It Works​

ML-KEM functions as a key exchange layer in the encryption cascade:

Encryption Flow:

1. ML-KEM Layer: Receiver's public key → encapsulated shared key
2. Signal Layer: Double Ratchet adds forward secrecy
3. MLS Group Layer: Group messaging support
4. AES Layer: Fast symmetric encryption

Why This Approach?​

Defense in Depth:

• ML-KEM protects against quantum attacks
• Signal Protocol provides forward secrecy
• MLS enables group messaging
• AES adds fast symmetric encryption

Each layer provides independent protection. If ML-KEM is broken, other layers still protect data.

Implementation Details​

ML-KEM Cipher Layer Architecture​

The MLKEMCipherLayer class implements the standard CipherLayer interface:

class MLKEMCipherLayer implements CipherLayer {
  readonly name = "ML-KEM-768";
  readonly version = "1.0.0";

  async encrypt(data: Uint8Array, keys: MLKEMKeys): Promise<EncryptedPayload>;
  async decrypt(payload: EncryptedPayload, keys: MLKEMKeys): Promise<Uint8Array>;
}

Key Properties​

• Public Key Size: 1184 bytes (for KEM-768 parameter set)
• Private Key Size: 64 bytes
• Encapsulated Key: 1088 bytes
• Shared Secret: 32-64 bytes (used as AES key material)

Security Features​

✅ Zeroization:

• All sensitive buffers are cleared after use
• Shared secrets, private keys, IVs are zeroized

✅ Timing Attack Protection:

• Constant-time key validation
• No early returns in validation logic

✅ IV Reuse Protection:

• Tracks used IVs per public key
• Random IV generation with collision detection

✅ Input Validation:

• Maximum plaintext size: 10MB (prevents DoS)
• Strict parameter size checks

Example Usage​

import { MlKem768 } from '@hpke/ml-kem';
import { MLKEMCipherLayer } from 'cryptography/CascadingCipher';

// Generate ML-KEM key pair
const kem = new MlKem768();
const keyPair = await kem.generateKeyPair();

// Create cipher layer
const layer = new MLKEMCipherLayer();

// Encrypt plaintext
const plaintext = new TextEncoder().encode('Quantum-secure message!');
const encrypted = await layer.encrypt(plaintext, {
  publicKey: keyPair.publicKey
});

// Decrypt
const decrypted = await layer.decrypt(encrypted, {
  privateKey: keyPair.privateKey
});

console.log(new TextDecoder().decode(decrypted)); // "Quantum-secure message!"

Module Federation Integration​

The cryptography module is exposed via module federation for import in the P2P application:

// cryptography/webpack.config.js
module.exports = {
  // Module federation config
  name: 'cryptography',
  exposes: {
    './CascadingCipher': './src/crypto/CascadingCipher/index.ts',
    './MLKEMUtils': './src/crypto/MLKEMUtils.ts',
    // ... other exports
  }
};

The P2P app imports via remote:

// p2p/webpack.config.js
module.exports = {
  remotes: {
    cryptography: 'cryptography@http://localhost:8083/remoteEntry.js'
  }
};

Storybook Examples​

Interactive Storybook stories demonstrate ML-KEM functionality:

• MLKEMBeginnerTutorial.stories.js - Step-by-step ML-KEM basics
• MLKEMDemo.stories.js - Real encryption/decryption examples
• MLKEMTimingTests.stories.js - Performance benchmarks

Try the Live Demo:

• ML-KEM Standalone Demo - Interactive encryption/decryption playground

Examples available at:

• ML-KEM Demo Story: https://cryptography.positive-intentions.com/?path=/story/cascading-cipher-ml-kem-demo--mlkem-standalone
• P2P Messaging Demo: https://p2p.positive-intentions.com/iframe.html?globals=&id=demo-p2p-messaging--p-2-p-messaging&viewMode=story

Performance Characteristics​

Encryption Benchmarks:

• Key Generation: ~10-15ms
• Encapsulation: ~15-25ms
• Decapsulation: ~15-25ms
• Total Operation: ~30-50ms

Overhead Analysis:

• Message Size: Adds ~1100 bytes (encapsulated key + IV + salt)
• Processing Time: +30-50ms compared to classical-only encryption
• Memory: Minimal (key material cached)

Comparison: Classical vs Post-Quantum​

Security Considerations​

Current Status​

✅ Implemented:

• ML-KEM-768 key pair generation
• Key encapsulation/decapsulation
• Integration with cascading cipher
• Security hardening (zeroization, timing protection)

⚠️ Limitations:

• JavaScript implementation (not FIPS 140-2 validated)
• No formal security audit
• Experimental/educational use only
• Performance overhead vs classical algorithms

Recommendations​

✅ Suitable For:

• Long-term confidential data storage
• Future-proofing sensitive communications
• Experimental/educational projects
• Low-volume secure messaging

❌ Not Recommended For:

• Production without formal security review
• High-performance applications
• Regulatory compliance without validation

Future Roadmap​

Planned Enhancements:

1. ML-DSA Integration - Post-quantum digital signatures
2. Hybrid Key Exchange - Combine classical + post-quantum
3. FIPS 140-2 Validation - Formal certification
4. WASM Optimization - Improve performance
5. Multiple Parameter Sets - Support KEM-512/1024 variants
6. Self-Certified Public Keys - Simplified identity verification

Conclusion​

The addition of ML-KEM post-quantum cryptography brings quantum-resistant security to our P2P messaging platform. By integrating it within the cascading cipher architecture, we provide defense-in-depth protection against both classical and quantum attacks.

While this implementation is still experimental, it demonstrates that building quantum-resistant applications in JavaScript is feasible. As quantum computing capabilities evolve, having quantum-resistant layers in place positions the project for long-term security.

Resources​

• 🚀 Live Demo: ML-KEM Standalone Demo
• 📚 Crash Course: ML-KEM Beginner Tutorial
• 🔬 In-Depth Tutorial: ML-KEM Research Tutorial
• 💻 Code Examples: See the ML-KEM Storybook Demo and P2P Messaging Demo