Last updated 2026-01-18

RabbitLock Technical Whitepaper (Public Summary)

A high-level overview of the RabbitLock architecture and security model.

Abstract

RabbitLock is a zero-trust encryption system that derives keys from a hardware-backed authenticator at the moment of use, avoiding server-held secrets. This public summary outlines the system architecture, hardware-bound key derivation, serverless recovery, and a quantum-ready hybrid encryption approach for protecting structured configuration data. The goal is to provide a high-level overview without implementation specifics.

Executive Summary

RabbitLock is a zero-trust encryption system designed to eliminate the "Secret-Zero" vulnerability in modern DevOps and personal security workflows. It leverages a hardware-backed authenticator to derive encryption keys at the moment of use, without any server-side key custody.

Unlike traditional vaults that store user keys on a server, RabbitLock derives keys entirely client-side and remains serverless for recovery. In representative deployments, the platform is designed so that decryption-capable key material is not retained and centralized user account custody is not required.

  • Hardware-backed identity as the root of encryption.
  • Serverless recovery using user-controlled artifacts.
  • Structured configuration files with selective encryption of secret values.
  • Hybrid key encapsulation to preserve confidentiality against classical and post-quantum threats.

Zero-Knowledge Identity Model

Hardware-Bound Key Derivation

RabbitLock uses a hardware-backed pseudo-random function (PRF) to derive a stable, device-bound seed for key derivation. Key material is designed to exist only transiently in client memory and within the hardware device.

Serverless Recovery

Because the identity is hardware-bound, recovery is enabled through user-controlled artifacts stored offline or in blind storage. Recovery methods include threshold recovery entries that reconstruct a root secret when a minimum number of entries are available, and multi-recipient recovery artifacts that allow designated guardians to restore access without a centralized recovery service.

Recovery is designed to avoid master passwords or server-side shards. Loss of both hardware and recovery artifacts can be unrecoverable by design.

Quantum-Ready Hybrid Encryption

RabbitLock employs a hybrid key encapsulation mechanism (KEM) to protect the data-encryption key (DEK). A classical public-key component provides near-term security, while a post-quantum component provides resilience against future quantum attacks. Both components must be successfully decapsulated to recover the DEK.

This design provides defense in depth against both classical and post-quantum threats while maintaining compatibility with modern client platforms.

Structured Configuration Encryption

RabbitLock encrypts secret values within structured configuration documents while preserving the document structure.

  • Leaf-node values are encrypted.
  • Keys, paths, and schema remain in plaintext to support version-control workflows.
  • Integrity metadata is included to detect tampering.
  • Multiple wrapped keys can coexist to enable multi-recipient access.

This enables secrets to remain usable in configuration-as-code workflows without exposing plaintext values.

Implementation Architecture

Cryptographic operations are executed in a memory-safe client module that is isolated from the UI layer. Hardware authentication and PRF evaluation use standard platform APIs available in secure contexts.

The system is designed to be auditable, portable, and compatible with secure browser execution environments.

Security Guarantees and Limitations

Guarantees

  • No required server-side key custody or decryption capability in the core model.
  • Non-extractable hardware-backed identity roots.
  • Hybrid encryption to mitigate long-term cryptographic risk.
  • Designed to remain secure as quantum capabilities mature.

Limitations

  • Client must run in a secure execution context.
  • Hardware authenticator support varies by platform.
  • Recovery artifacts must be stored securely by the user.

Public Release Scope

This public summary intentionally omits algorithm-specific parameters and implementation details. No algorithm parameterization, implementation code, or security proofs are included.