Privavault
12 days ago
Nice work on this! CLI tools for encryption are underrated—I find people are more likely to actually encrypt things when the friction is low.
One thing I learned building PrivaVault (an encrypted document management app, just launched) is that the key management piece becomes the real UX challenge. We ended up implementing a zero-knowledge architecture where keys never touch our servers, but the tradeoff is users need to understand they're responsible for their master password.
I'm curious about your approach to key derivation and storage for the RTTY-SODA system. Are you using libsodium's password hashing (Argon2) or handling that separately?
nett_ef
12 days ago
Thanks!
I’m using Argon2id-Blake2b. There’s a flowchart here: https://github.com/theosaveliev/rtty-soda?tab=readme-ov-file...
And the relevant code is here: https://github.com/theosaveliev/rtty-soda/blob/main/src/rtty...
I made a couple of explicit assumptions to reduce UX friction, and I try to document and test them rather than hide them:
1. I’m aware that using size=PrivateKey.SIZE is not ideal, since that constant is shared between public and secret schemes. I rely on the fact that the sizes match in libsodium, and I enforce that assumption with tests so it fails loudly if that ever changes: https://github.com/theosaveliev/rtty-soda/blob/main/tests/te...
2. For the salt, I intentionally avoid asking the user for an additional input. Instead, I hash a fixed long quote from Henry Fielding together with the user password. The assumption is that combining a short password with a long, fixed string still provides sufficient entropy for the KDF input and forces an attacker to recompute rainbow tables with the quote included, rather than reuse generic ones.
These tradeoffs are deliberate. I’m open to critique, especially if there’s a way to improve this without increasing UX complexity.