Skip to content

Symmetric Keys

The case for symmetric keys

Symmetric encryption — where both sender and receiver use the same key — has long been considered the most secure form of encryption. But historically, symmetric key systems were difficult to scale: keys had to be delivered manually, rotated infrequently, and managed in ways that didn’t fit dynamic, cloud-native, or globally distributed environments.

Crux solves that problem by pairing symmetric encryption with a scalable, secure, and quantum-resilient key distribution model — courtesy of Arqit' SKA-Platform™ (SKA-P).

Why not just use public-key cryptography?

Most traditional VPNs and secure channels rely on public-key infrastructure (PKI) to handle authentication and key exchange. But this comes with serious long-term risks:

  • Public keys are quantum vulnerable — future quantum computers could reverse-engineer them.
  • Certificate management at scale is brittle, error-prone, and increasingly difficult to secure.
  • Compromised private keys often remain valid for months, with revocation rarely effective in time.

Even so-called “post-quantum algorithms” (PQAs) aren’t ready for prime time when it comes to protecting real-time data in transit. Their complexity, latency, and uncertain long-term security make them a risky bet for ongoing communications.

Crux and Arqit take a different approach — one that’s quantum-aware, crypto-agile, and provably secure today.

How Crux uses SKA-P

At initial registration, Crux devices perform a one-time authentication with the SKA-P. This process bootstraps a quantum-safe root-of-trust using a hybrid approach:

  1. Three post-quantum key encapsulation mechanisms (KEMs) are used to generate a temporary shared secret. These KEMs are drawn from NIST’s post-quantum finalists (e.g., Kyber, McEliece).
  2. These secrets are combined and used to deliver a symmetric root-of-trust key, encrypted over TLS.
  3. This symmetric key becomes the basis for all further cryptographic operations — including identity authentication, session key rotation, and secure data exchange.
sequenceDiagram
    participant Crux
    participant SKA as SKA-Platform™

    Crux->>+SKA: Initiate device registration
    activate SKA
    Note right of SKA: Generate public-private key pairs for each KEM: <br/>- Classic McEliece <br/>- FrodoKEM<br/>- CRYSTALS-Kyber
    SKA->>-SKA: 
    activate SKA
    SKA->>-SKA: 
    activate SKA
    SKA->>-SKA: 
    SKA-->>+Crux: Sends public keys (for each KEM)
    Note left of Crux: Generate random secret and encapsulate with public keys
    Crux->>-Crux: 
    Crux-->>SKA: Send encapsulated secrets
    activate SKA
    Note right of SKA: Decapsulate secrets using private keys
    SKA->>-SKA: 
    activate Crux
    Note left of Crux: Combine secrets using hash function
    Crux->>-Crux: 
    activate SKA
    Note right of SKA: Combine secrets using hash function
    SKA->>-SKA: 
    activate SKA
    Note right of SKA: Create symmetric root-of-trust key 
    SKA->>-SKA: 
    SKA-->>Crux: Encrypt root key with combined secret and send
    activate Crux
    Note left of Crux: Decrypt root-of-trust key
    Crux->>-Crux:

Once this root key is in place, Crux enters a ratcheted trust relationship. Each authentication cycle derives a fresh key from the last — a non-reversible chain that reduces key lifetime and simplifies revocation.

Think of it like a one-way escalator: even if someone compromises a key, they can’t go backward or forward in the chain.

Security, by Design

This model has several powerful security properties:

  • Short-lived authentication keys (minutes or hours) drastically limit the impact of credential theft.
  • No reliance on long-term private keys removes a major attack surface.
  • Quantum-safe key exchanges secure the bootstrap, and everything after is encrypted using symmetric AES-256 or equivalent.
  • Defense in depth: Arqit’s use of multiple KEMs increases resilience, should one be weakened in the future.

And because the SKA-P handles symmetric key generation, Crux never needs to “agree” a session key with another peer using vulnerable public-key methods. Instead, both endpoints are provisioned independently with synchronized symmetric keys from the platform — authenticated, verified, and ready for post-quantum secure communication.