Roadmap
Last updated
Last updated
If you'd like to suggest a new feature, feel free to open a feature request on . However, please read the section first.
Fix the macOS binaries not embedding the libsodium library. This is an with either the libsodium NuGet package or the .NET SDK.
Create a package.
Improve the .
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 . 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.
Reconsider random nonces (e.g. for private key encryption).
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.
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.
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.
Switch to 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 using BLAKE2b (not widely used).
Use Ed25519ph for prehashing in v2 of the signature format. It wasn't available in the libsodium binding.
Reconsider .
Could switch to libsodium's API for file encryption. This wasn't available in the libsodium binding. One be coming for AEGIS. Or just write a library, which I should do anyway.
Will need to eventually switch to post-quantum asymmetric primitives - KEM and signing. This requires waiting for and (likely years). The UX will be terrible.
Investigate .
Investigate support.
Add support for generating public keys?