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)
Device Key Hierarchy
Key Storage Locations
Device Key:- Primary: OS Keychain
- macOS: Keychain Access (
Spacedriveservice) - Linux: Secret Service API (GNOME Keyring, KWallet)
- Windows: Windows Credential Manager
- macOS: Keychain Access (
- Fallback:
<data_dir>/device_key(development and testing only)
- 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: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: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: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
- Generate random 24-byte nonce
- Encrypt plaintext with device key and nonce
- Compute authentication tag
- 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:Key Rotation
Library keys are automatically generated and do not require manual rotation.API Usage
Initialization
The KeyManager is initialized once at application startup and shared viaArc:
Basic Operations
Integration Examples
Device Manager (network identity):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
Migration from Legacy Storage
Prior to the unified KeyManager, Spacedrive stored secrets in multiple locations:
- Device key:
<data_dir>/master_keyfile - Paired devices:
<data_dir>/networking/paired_devices.json(AES-256-GCM encrypted) - Cloud credentials: OS keychain (unreliable)
Troubleshooting
”Failed to access keychain” Error
If KeyManager can’t access the OS keychain:- macOS: Grant Keychain Access permission in System Preferences
- Linux: Install
gnome-keyringorkwallet - Fallback: KeyManager will use file fallback at
<data_dir>/device_key
Corrupted Database
Ifsecrets.redb becomes corrupted:
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:Related Documentation
- Devices - Device identity and pairing
- Networking - P2P communication using session keys
- Cloud Integration - Cloud credential storage
- Security - Overall security architecture
