Roadmap

Suggesting a new feature

If you'd like to suggest a new feature, feel free to open a feature request on GitHub. However, please read the Goals section first.

Fix the macOS binaries not embedding the libsodium library. This is an upstream issue with either the libsodium NuGet package or the .NET SDK.
Create a WinGet package.
Improve the Chocolatey package.

Try to implement some automated testing.
Investigate guarded heap allocations for byte array secrets.
Investigate better erasure of secrets (e.g. pinning and wiping strings/char arrays).
Support YubiKeys via the .NET YubiKey SDK. A decision needs to be made whether to use PIV, which requires the 5.7 firmware for X25519/Ed25519, or challenge-response, which is symmetric, allows backups, and works with older YubiKeys. Using PIV requires waiting for updates to the SDK and me buying a new YubiKey. Supporting both is probably an overcomplicated UX.
Address build warnings.
Investigate support for win-arm64.

Address Unicode normalization.
Add multi-recipient sender authentication if possible.
Switch to AEGIS-256 for encryption. Much faster, well analysed, and fully committing (assuming the associated data is empty or hashed).
Change the KDF to either HKDF (needlessly inefficient and won't be using BLAKE2), BLAKE3 (another dependency), or one of NIST's KDFs using BLAKE2b (not widely used).
Use Ed25519ph for prehashing in v2 of the signature format. It wasn't available in the previous libsodium binding.
Reconsider hedged signatures.
Reconsider random nonces (e.g. for private key encryption).
Could switch to libsodium's secretstream API for file encryption. This wasn't available in the previous libsodium binding. One may be coming for AEGIS. Or just write a STREAM library, which I should do anyway.
Support more recipients/change the key wrap header approach.
Remove free space from the file metadata header.
Consider ASCII armour/Minisign style detached signature files.
Will need to eventually switch to post-quantum asymmetric primitives - KEM and signing. This requires waiting for further analysis and library support (likely years). The UX will be terrible.
~~Consider supporting unencrypted private keys for non-interactive use cases.~~

Support non-detached signatures?
Confirm y/n before -o|--overwrite?
Do a progress bar like Docker?
Add a -b|--batch option for automated use cases that rejects interactive input and terminates the program when an error/exception occurs?
Consider -q|--quiet to hide output.
Investigate globbing.
Investigate stdin support.
Display -h|--help with no user input if possible.
Have a trusted folder for public keys, with separate files or folders for encryption/signing? No idea what the UX would be.
~~Add support for generating~~ ~~vanity address~~ ~~public keys?~~

Last updated 1 year ago