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.

v4.1.2

  • 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.

v4.2.0

  • 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.

Long run

Breaking

  • 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.

Non-breaking

  • 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