Skip to main content
The KeyManager is Spacedrive’s unified cryptographic secret storage system. It provides encrypted storage for all sensitive data including device keys, library encryption keys, paired device session keys, and cloud credentials.

Architecture

Storage Backend

KeyManager uses redb, an embedded key-value database, for encrypted secret storage:
  • Database: <data_dir>/secrets.redb
  • Encryption: XChaCha20-Poly1305 AEAD cipher
  • Root Key: Device key stored in OS keychain (or plaintext file fallback for development and testing only)
All secrets are encrypted at rest using the device key. The database provides ACID guarantees and transactional operations.

Device Key Hierarchy

Key Storage Locations

Device Key:
  1. Primary: OS Keychain
    • macOS: Keychain Access (Spacedrive service)
    • Linux: Secret Service API (GNOME Keyring, KWallet)
    • Windows: Windows Credential Manager
  2. Fallback: <data_dir>/device_key (development and testing only)
Encrypted Secrets:
  • All platforms: <data_dir>/secrets.redb

What’s Stored

1. Library Encryption Keys

Each library has a unique encryption key used for encrypting library-specific secrets:
Key format: library_{uuid} Used for:
  • Cloud credential encryption
  • Library-specific secret storage
  • Future: Library database encryption

2. Paired Device Data

Device pairing information and session keys for P2P communication:
Key format: paired_device_{uuid} Includes:
  • Device identity (name, slug, type, OS)
  • Session keys for encrypted communication
  • Trust level (Trusted, Unreliable, Blocked)
  • Connection metadata

3. Cloud Credentials

OAuth tokens and API keys for cloud storage integrations:
Note: Cloud credentials are stored in the library database, but encrypted using library keys from KeyManager.

4. Arbitrary Secrets

General-purpose encrypted storage for application or extension needs:

Security Model

Encryption

Algorithm: XChaCha20-Poly1305
  • Cipher: XChaCha20 (extended-nonce ChaCha20)
  • Authentication: Poly1305 MAC
  • Nonce: 24 bytes (randomly generated per encryption)
  • Key size: 256 bits
Process:
  1. Generate random 24-byte nonce
  2. Encrypt plaintext with device key and nonce
  3. Compute authentication tag
  4. Prepend nonce to ciphertext: [nonce(24) | ciphertext | tag(16)]

Device Key Protection

The device key never exists in plaintext on disk (except in development with file fallback): Production:
Development and Testing Only:

Key Rotation

Device key rotation is not currently supported. Rotating the device key would require re-encrypting all secrets in the database.
Library keys are automatically generated and do not require manual rotation.

API Usage

Initialization

The KeyManager is initialized once at application startup and shared via Arc:

Basic Operations

Integration Examples

Device Manager (network identity):
Device Pairing (session keys):
Cloud Credentials:

Error Handling

Performance Considerations

Caching

The device key is cached in memory after first retrieval to avoid repeated OS keychain access:

Concurrent Access

KeyManager uses async locking for safe concurrent access:

Database Size

The redb database grows with the number of secrets stored. Typical sizes:
  • Fresh install: ~4KB (empty database)
  • With 10 paired devices: ~20KB
  • With 100 secrets: ~50KB
The database is compacted automatically by redb.

Migration from Legacy Storage

Prior to the unified KeyManager, Spacedrive stored secrets in multiple locations:
  • Device key: <data_dir>/master_key file
  • Paired devices: <data_dir>/networking/paired_devices.json (AES-256-GCM encrypted)
  • Cloud credentials: OS keychain (unreliable)
These systems have been consolidated into KeyManager for better security and reliability.

Troubleshooting

”Failed to access keychain” Error

If KeyManager can’t access the OS keychain:
  1. macOS: Grant Keychain Access permission in System Preferences
  2. Linux: Install gnome-keyring or kwallet
  3. Fallback: KeyManager will use file fallback at <data_dir>/device_key

Corrupted Database

If secrets.redb becomes corrupted:
Deleting secrets.redb will unpair all devices and remove cloud credentials. You’ll need to re-pair devices and re-authenticate cloud services.

Inspecting Secrets (Development)

Security Best Practices

Production Deployments

  • Always use OS keychain in production (never file fallback)
  • Restrict file permissions on secrets.redb (chmod 600)
  • Enable disk encryption (FileVault, LUKS, BitLocker)
  • Backup device key from keychain before system migration

File Permissions

Ensure strict permissions on sensitive files:

Backup Strategy

The device key is critical for accessing all secrets: