You asked about security - Breaking down the zero-knowledge encryption model
Thanks for all the security questions on my CLI history sync tool.
You're absolutely right to scrutinize this - command history contains sensitive data.
Let me break down the E2E encryption approach:
How it works:
you create a local account using a username and a password
a secure key (64bytes long) is derived from your credentials using Argon2id
all your captured commands are encrypted with XChaCha20-Poly1305 using the first half of the derived key (0:31> bytes)
if sync is enabled, your local user will register/authenticate with the server using the second half of the derived key (32:63) so that you will NEVER, EVER give the sync server the pre-requisites for decrypting your data
once you log with a new device ( and sync is enabled ) a PerfectSync operation will be ran, this will match the local commands with the one remotely stored and upload/download what's missing
To recap:
The server only sees encrypted blobs - it literally cannot decrypt your history
Zero-knowledge architecture: even if someone compromises the server, they get encrypted gibberish
Technical details:
Argon2id key derivation from your credentials
All your commands are encrypted at rest and only decrypted during search
Metadata (timestamps, machine names) also encrypted
Server acts as a dumb encrypted blob store
The principle is simple: if I can't read your data, neither can anyone who compromises the server.
Questions I'd love feedback on:
Any specific security auditing tools you'd recommend?
Other CLI tools that handle this well I should study?
Building this in public and your scrutiny makes it better.
Replies