Skip to content

Cryptographic Design

Detailed rationale for cryptographic choices in Secure LSL.

Design Goals

  1. Confidentiality: Biosignal data readable only by authorized endpoints
  2. Integrity: Detection of any data modification in transit
  3. Authenticity: Verification that data comes from claimed source
  4. Forward Secrecy: Past sessions protected if keys compromised later
  5. Performance: Minimal overhead for real-time streaming
  6. Simplicity: Easy deployment without cryptographic expertise

Algorithm Selection

Identity: Ed25519

Choice: Ed25519 (EdDSA on Curve25519)

Property Value
Key size 32-byte private, 32-byte public
Signature size 64 bytes
Security level ~128-bit
Performance ~70,000 signatures/sec on modern CPU

Why Ed25519?

  1. Compact keys: 32 bytes fits in UDP discovery packets
  2. Fast verification: Critical for real-time connection establishment
  3. Deterministic: Same message always produces same signature (debugging friendly)
  4. Side-channel resistant: Constant-time implementation in libsodium
  5. Wide deployment: OpenSSH, Signal, WireGuard, GnuPG

Alternatives considered:

Algorithm Why Not
RSA-3072 384-byte keys, slower verification
ECDSA P-256 Malleable signatures, harder constant-time
Ed448 Larger keys/signatures, minimal security gain

Key Exchange: X25519

Choice: X25519 (ECDH on Curve25519)

Property Value
Public key size 32 bytes
Shared secret size 32 bytes
Security level ~128-bit
Performance ~25,000 operations/sec

Why X25519?

  1. Ephemeral-ephemeral: Enables forward secrecy
  2. Compatible with Ed25519: Same curve, key conversion possible
  3. Simple API: No complex parameter negotiation
  4. Proven security: Analyzed extensively, used in TLS 1.3

Key derivation:

Ed25519 private key → X25519 private key (via crypto_sign_ed25519_sk_to_curve25519)
Ed25519 public key → X25519 public key (via crypto_sign_ed25519_pk_to_curve25519)

Key Derivation: HKDF-SHA256

Choice: HKDF (HMAC-based Key Derivation Function) with SHA-256

Property Value
Hash function SHA-256
Output Variable length
Security Information-theoretic extraction

Why HKDF?

  1. Standardized: RFC 5869
  2. Two-stage design: Extract randomness, then expand
  3. Domain separation: Different outputs for different purposes
  4. libsodium support: crypto_kdf_hkdf_sha256

Parameters used:

IKM: 32-byte X25519 shared secret
Salt: None (zero-length)
Info: "lsl-session-v1"
L: 32 bytes

Encryption: ChaCha20-Poly1305

Choice: ChaCha20-Poly1305 (IETF variant, RFC 8439)

Property Value
Key size 256 bits
Nonce size 96 bits (we use 64-bit counter)
Tag size 128 bits
Block size 64 bytes

Why ChaCha20-Poly1305?

  1. No hardware dependency: Fast on ARM, embedded devices
  2. Authenticated: Encryption + integrity in single operation
  3. Misuse resistant: Nonce reuse reveals nothing about plaintext
  4. Constant-time: No timing side channels
  5. IETF standardized: Interoperable, well-analyzed

Comparison with AES-GCM:

Factor ChaCha20-Poly1305 AES-GCM
Software speed Faster Slower
Hardware speed (AES-NI) N/A Faster
Raspberry Pi 3x faster Baseline
Intel with AES-NI Comparable Baseline
Nonce misuse Safe (beyond 2^32) Catastrophic
Side channels Resistant Requires care

Decision: ChaCha20-Poly1305 chosen for consistent performance across all LSL deployment targets, including embedded devices.

Security Constructions

Session Key Establishment

┌─────────────────────────────────────────────────────┐
│ 1. Both parties have Ed25519 keypairs               │
│    - outlet_ed_sk, outlet_ed_pk                     │
│    - inlet_ed_sk, inlet_ed_pk                       │
├─────────────────────────────────────────────────────┤
│ 2. Convert to X25519 for key exchange               │
│    - outlet_x_sk = ed25519_sk_to_x25519(outlet_ed_sk)│
│    - outlet_x_pk = ed25519_pk_to_x25519(outlet_ed_pk)│
│    - inlet_x_sk = ed25519_sk_to_x25519(inlet_ed_sk) │
│    - inlet_x_pk = ed25519_pk_to_x25519(inlet_ed_pk) │
├─────────────────────────────────────────────────────┤
│ 3. X25519 key agreement                             │
│    - Outlet: ss = X25519(outlet_x_sk, inlet_x_pk)   │
│    - Inlet: ss = X25519(inlet_x_sk, outlet_x_pk)    │
│    - Both derive identical shared secret            │
├─────────────────────────────────────────────────────┤
│ 4. HKDF key derivation                              │
│    - session_key = HKDF(ss, info="lsl-session-v1")  │
└─────────────────────────────────────────────────────┘

Authenticated Encryption

For each packet:

┌─────────────────────────────────────────────────────┐
│ Input:                                              │
│   - key: 32-byte session key                        │
│   - nonce: 8-byte counter (padded to 12 for IETF)   │
│   - plaintext: serialized sample data               │
├─────────────────────────────────────────────────────┤
│ Encryption:                                         │
│   nonce_12 = [0x00, 0x00, 0x00, 0x00] || nonce_8    │
│   (ciphertext, tag) = ChaCha20Poly1305(             │
│       key, nonce_12, plaintext, aad=empty           │
│   )                                                 │
├─────────────────────────────────────────────────────┤
│ Output:                                             │
│   - nonce (8 bytes)                                 │
│   - ciphertext (len(plaintext) bytes)               │
│   - tag (16 bytes)                                  │
└─────────────────────────────────────────────────────┘

Nonce Management

Design: 64-bit monotonic counter

nonce_0 = 0
nonce_1 = 1
nonce_2 = 2
...
nonce_n = n

Properties:

  • Never repeats: Counter always increases
  • Huge space: 2^64 = 18 quintillion packets
  • At 1000 Hz: 584 million years before exhaustion
  • No coordination needed: Each connection has independent counter

Replay window:

WINDOW_SIZE = 64

If received_nonce > highest_nonce:
    highest_nonce = received_nonce
    Add to seen_set
    ACCEPT

If received_nonce > highest_nonce - WINDOW_SIZE:
    If received_nonce NOT in seen_set:
        Add to seen_set
        ACCEPT
    Else:
        REJECT (replay)

Else:
    REJECT (too old)

Security Proofs

Confidentiality

Claim: An attacker who observes network traffic cannot learn plaintext.

Proof sketch: 1. ChaCha20 is a secure stream cipher (proven reduction to ChaCha permutation security) 2. Without the session key, ciphertext is indistinguishable from random 3. Session key requires knowledge of at least one private key (X25519 CDH assumption) 4. Private keys are never transmitted

Integrity

Claim: An attacker cannot modify ciphertext without detection.

Proof sketch: 1. Poly1305 is a secure MAC (information-theoretic security given random key) 2. Tag verification fails if any bit of (nonce || ciphertext) is modified 3. Forgery probability: 2^-128 per attempt

Forward Secrecy

Claim: Compromise of long-term keys does not reveal past session keys.

Proof sketch: 1. Session keys derived from X25519 shared secrets 2. Shared secrets computed from ephemeral-ephemeral exchange 3. Each connection uses fresh ephemeral keys 4. Past ephemeral private keys are erased after use 5. Attacker cannot recompute past shared secrets

Implementation Details

libsodium Functions Used

Purpose Function
Key generation crypto_sign_keypair()
Ed→X25519 conversion crypto_sign_ed25519_sk_to_curve25519()
Key exchange crypto_scalarmult()
Key derivation crypto_kdf_hkdf_sha256_extract/expand()
Encryption crypto_aead_chacha20poly1305_ietf_encrypt()
Decryption crypto_aead_chacha20poly1305_ietf_decrypt()
Secure memory sodium_memzero(), sodium_mlock()

Memory Protection

// Session keys are locked in memory (no swap)
sodium_mlock(session_key, sizeof(session_key));

// Keys are zeroed when connection closes
sodium_memzero(session_key, sizeof(session_key));
sodium_munlock(session_key, sizeof(session_key));

Constant-Time Operations

All cryptographic operations are constant-time to prevent timing side channels:

// Comparison uses constant-time memcmp
if (sodium_memcmp(computed_tag, received_tag, 16) != 0) {
    return AUTHENTICATION_FAILED;
}

Performance Analysis

Overhead Breakdown

For 64-channel float32 sample at 1000 Hz:

Operation Time % of Sample Period
Serialization ~5 µs 0.5%
ChaCha20 encryption ~2 µs 0.2%
Poly1305 MAC ~1 µs 0.1%
Network overhead ~20 bytes -
Total ~8 µs 0.8%

Platform Benchmarks

Platform Encryption Throughput Latency Added
Intel i7-10700 2.5 GB/s 0.3 ms
Intel i5-8250U 1.8 GB/s 0.5 ms
Apple M1 3.2 GB/s 0.2 ms
Raspberry Pi 4 180 MB/s 0.9 ms

All measurements well within real-time constraints.

Future Considerations

Post-Quantum Security

Current algorithms are vulnerable to quantum computers:

Algorithm Quantum Threat
Ed25519 Broken by Shor's algorithm
X25519 Broken by Shor's algorithm
ChaCha20 Weakened (Grover), still 128-bit

Migration path: 1. NIST post-quantum standards (ML-KEM, ML-DSA) finalized 2024 2. libsodium expected to add support 3. Protocol supports version negotiation for algorithm upgrade 4. Key encapsulation can run alongside X25519 (hybrid mode)

Algorithm Agility

The protocol includes version negotiation:

Security-Version: 1

Future versions can introduce new algorithms while maintaining backward compatibility.

References

Next Steps