Application-Layer Encryption

Transport Security (Always On)

All P2P communication in the YoorQuezt mesh uses QUIC with TLS 1.3. This provides:

  • Authenticated encryption of all data in transit
  • Perfect forward secrecy
  • 0-RTT connection establishment
  • Certificate-based peer authentication

This layer cannot be disabled.

Application-Layer Encryption (Optional)

On top of QUIC+TLS, an optional AES-256-GCM encryption layer can be enabled on message payloads. This provides defense-in-depth:

  • Protection against compromised TLS termination points
  • Additional encryption boundary for sensitive orderflow data
  • Shared-key encryption ensuring only authorized mesh nodes can read payloads

Configuration

# node-config.yaml
app_layer_encryption: true    # enable (default, backward compatible)
app_layer_encryption: false   # disable for performance

When omitted or set to null, defaults to true for backward compatibility.

Performance Impact

ConfigurationLatency OverheadCPU OverheadUse Case
QUIC+TLS onlyBaselineBaselinePerformance-critical deployments, trusted network
QUIC+TLS + AES-256-GCM~0.1-0.3ms per message~2-5%Maximum security, untrusted infrastructure

For most deployments, the overhead is negligible. Disabling is recommended only for latency-sensitive configurations where the infrastructure is fully trusted (e.g., same data center, private network).

How It Works

Enabled (default)

Message Payload
      │
      ▼
┌─────────────────┐
│ zstd Compress   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ AES-256-GCM     │
│ Encrypt         │
│ (shared key)    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ ECDSA P-256     │
│ Sign            │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ QUIC + TLS 1.3  │
│ Send            │
└─────────────────┘
  1. Message payload is compressed with zstd.
  2. Compressed payload is encrypted with AES-256-GCM using the shared key.
  3. Encrypted payload is signed with ECDSA P-256.
  4. Signed message is sent over QUIC+TLS.

Disabled

Message Payload
      │
      ▼
┌─────────────────┐
│ zstd Compress   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ ECDSA P-256     │
│ Sign            │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ QUIC + TLS 1.3  │
│ Send            │
└─────────────────┘
  1. Message payload is compressed with zstd.
  2. Compressed payload is signed with ECDSA P-256.
  3. Signed message is sent over QUIC+TLS.

Runtime Toggle

The encryption toggle uses an atomic flag (sync/atomic), so it can be changed at runtime without restarting the node. This is useful for:

  • Toggling encryption during performance benchmarking
  • Emergency disable if encryption causes interop issues
  • Gradual rollout across a mesh deployment

Messages from nodes with encryption enabled are still readable by nodes with it disabled (and vice versa), as long as all nodes share the same key. The receiver detects whether a message is encrypted by inspecting the message header.

Shared Key

The AES-256-GCM shared key is configured via the YOORQUEZT_SHARED_KEY environment variable:

  • Format: hex-encoded 32-byte key (64 hex characters)
  • Requirement: all mesh nodes in a deployment must use the same key
  • Generation: use a cryptographically secure random source
# Generate a shared key
openssl rand -hex 32
# Example: a1b2c3d4e5f6...64 hex chars

Docker Compose Example

services:
  mesh-node-1:
    image: yoorquezt-mesh
    environment:
      - YOORQUEZT_SHARED_KEY=a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890
    volumes:
      - ./node1-config.yaml:/app/config.yaml

  mesh-node-2:
    image: yoorquezt-mesh
    environment:
      - YOORQUEZT_SHARED_KEY=a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890
    volumes:
      - ./node2-config.yaml:/app/config.yaml

Node Config Example

# node1-config.yaml
listen_addr: :4242
bootstrap_addr: bootstrap:4243
app_layer_encryption: true

# node2-config.yaml
listen_addr: :4244
bootstrap_addr: bootstrap:4243
app_layer_encryption: true

Security Considerations

  • Key rotation: currently manual. Rotate by updating YOORQUEZT_SHARED_KEY on all nodes and restarting. Automated rotation is planned.
  • Key exposure: if the shared key is compromised, an attacker with access to the TLS-encrypted wire can decrypt payloads. Rotate immediately.
  • Mixed mode: a deployment can run with some nodes encrypted and some not. However, this reduces the security benefit -- prefer uniform configuration.
  • Performance: AES-256-GCM is hardware-accelerated on modern CPUs (AES-NI). The overhead is primarily from the additional memory copy, not the cryptographic operation.
Edit this page