Show HN: rtty-soda – CLI frontend to NaCl (PyNaCl) for encrypting small files

[nett_ef]

I tried to make the best CLI for interfacing with PyNaCl primitives, especially with KDF.

I don’t expect your trust; I focused on making the code readable for review. I haven’t reviewed the underlying libraries.

I included some silly examples in the README — I hope you enjoy them and have as much fun using it as I did while building it.

It’s focused on small files: not for large blobs, but great for keys, configs, and other secrets.

Thanks for your time. Please note that I’m not a security expert, and this is my first project in this space.

I actively use it myself and plan to maintain it long-term.

[Privavault]

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]

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.