Encryption & team access

Local encryption, zero-knowledge storage, controlled sharing.

Private chunks are encrypted on your machine with a key only you control. RDK Central stores the ciphertext and cannot read it. Team members you invite can decrypt your private chunks locally.

What's encrypted

• PRIVATE chunks: encrypted with AES-256-GCM before leaving your machine
• PUBLIC chunks: not encrypted (intentionally — they're meant to be read by any node)
• LOCAL vault files: not encrypted by RDK (these are your own files; use FileVault, LUKS, or similar disk-level encryption if you need it)

How keys work

When you run rdk init, a 256-bit AES-256-GCM key is generated and stored encrypted at ~/.rdk/config.json. This key:

• Encrypts your private chunks before they leave your machine
• Never gets sent to RetroDeck or RDK Central
• Can be shared with team members via invite

Granting team access shares the key — not the files. Your team members can decrypt your private chunks on the network, but they cannot read your local vault files unless they have access to your machine through some other channel.

Inviting team members

rdk team:invite teammate@example.com

This generates a one-time invite code. Share the code with your team member privately (encrypted email, Signal, in person).

Your team member runs:

rdk team:accept <inviteId>

They paste the invite code when prompted. Their node can now query your private chunks and decrypt results locally.

Revoking access

rdk team:revoke teammate@example.com

This revokes their permission in RDK Central. To fully invalidate their copy of the key, rotate it:

rdk vault:rotate-key

This generates a new key, re-encrypts all your private chunks, and invalidates all existing team invites. Re-invite team members after rotation.