← Projects
Airgapper

Airgapper

Consensus-based encrypted backup system using Shamir's Secret Sharing for distributed key management.

GoReactTypeScriptgRPCSQLite

Consensus-based encrypted backup system using Shamir's Secret Sharing for distributed key management.

GoReactTypeScriptgRPCSQLite
GitHub ↗
Airgapper Logo

Airgapper

A backup system where neither the data owner nor the backup host can decrypt data alone. both must agree via a cryptographic consensus flow.

The Problem

Traditional backup solutions have a trust problem: whoever holds the encryption key controls the data. If you back up to a cloud service, you’re trusting them with your key. If you self-host, you’re a single point of failure. Lose the key, lose everything. Get compromised, lose everything.

There’s no middle ground in most backup tools. it’s all-or-nothing trust.

The Solution

Airgapper uses Shamir’s Secret Sharing (SSS) to split backup encryption keys between multiple parties. Restoring data requires a threshold of keyholders to approve. creating a consensus-based system where no single party has complete control.

Think of it like a safety deposit box that requires multiple keyholders to open. Except the box is your data, the keys are cryptographic shares, and the bank can’t peek inside.

Architecture

graph TB
    subgraph Client["Client (React + TypeScript)"]
        UI[Web Interface]
        CLI[CLI Tool]
    end

    subgraph API["API Layer (gRPC)"]
        GW[gRPC Gateway]
        AUTH[Auth Middleware]
    end

    subgraph Core["Core Engine (Go)"]
        VM[Vault Manager]
        SSS[Shamir's Secret Sharing]
        KM[Key Manager]
        BM[Backup Manager]
    end

    subgraph Storage["Storage Layer"]
        DB[(SQLite)]
        RS[Restic Repository]
        KS[Key Share Store]
    end

    subgraph Keyholders["Keyholders (m-of-n)"]
        KH1[Keyholder 1]
        KH2[Keyholder 2]
        KH3[Keyholder n...]
    end

    UI --> GW
    CLI --> GW
    GW --> AUTH
    AUTH --> VM
    VM --> SSS
    VM --> KM
    VM --> BM
    SSS --> KS
    KM --> DB
    BM --> RS
    KH1 --> GW
    KH2 --> GW
    KH3 --> GW

How It Works

Backup flow:

  1. Client encrypts data using a generated encryption key
  2. The key is split into n shares using Shamir’s Secret Sharing
  3. Each share is distributed to a designated keyholder
  4. The encrypted data is stored in a restic repository
  5. No single party. including the data owner. holds the complete key

Restore flow:

  1. Data owner initiates a restore request
  2. Keyholders receive approval requests
  3. Once m of n keyholders approve, their shares are combined
  4. The encryption key is reconstructed and data is decrypted
  5. Key is immediately discarded after use

Key Features

  • Consensus-based restoration. Configurable m-of-n approval requirements. Need 3 of 5 keyholders to agree? 2 of 3? Your call.
  • Built on restic. Battle-tested deduplication, encryption, and backup verification. No need to reinvent the wheel.
  • gRPC API. Strongly typed interfaces with code generation. The protobuf definitions are the single source of truth.
  • Integrity verification. Merkle tree-based audit trails ensure backup integrity is verifiable at any point.
  • Emergency recovery. Dead man’s switch and override protocols for when keyholders become unavailable.
  • Self-contained vaults. Each vault is a standalone unit with its own SQLite database. No shared state, no coordination overhead.

What I Learned

Building Airgapper surfaced some interesting challenges:

  • Key lifecycle management is harder than the cryptography itself. When do you generate keys? When do you rotate shares? What happens when a keyholder loses their device?
  • Consensus UX is tricky. Making it easy for non-technical keyholders to approve requests without compromising security required several iterations.
  • Testing cryptographic systems requires thinking about adversarial scenarios, not just happy paths.