> For the complete documentation index, see [llms.txt](https://www.kryptor.co.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.kryptor.co.uk/roadmap.md). # Roadmap ## Suggesting a new feature If you'd like to suggest a new feature, feel free to open a feature request on [GitHub](https://github.com/samuel-lucas6/Kryptor/issues/new/choose). However, please read the [Goals](/master.md#goals) section first. ## v4.1.2 * Fix the macOS binaries not embedding the libsodium library. This is an [upstream issue](https://github.com/dotnet/sdk/issues/45903) with either the libsodium NuGet package or the .NET SDK. * Create a [WinGet](https://github.com/microsoft/winget-cli) package. * Improve the [Chocolatey package](https://github.com/samuel-lucas6/Kryptor-Chocolatey). ## 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](https://docs.yubico.com/yesdk/). 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](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aegis-aead) 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](https://github.com/samuel-lucas6/NIST-KBKDFs) using BLAKE2b (not widely used). * Use Ed25519ph for prehashing in v2 of the signature format. It wasn't available in the [previous](https://github.com/ektrah/libsodium-core) libsodium binding. * Reconsider [hedged signatures](https://soatok.blog/2020/05/03/hedged-signatures-with-libsodium-using-dhole/). * Reconsider random nonces (e.g. for private key encryption). * Could switch to libsodium's [secretstream](https://www.geralt.xyz/authenticated-encryption/stream-and-file-encryption) API for file encryption. This wasn't available in the [previous](https://github.com/ektrah/libsodium-core) libsodium binding. One [may](https://doc.libsodium.org/roadmap) be coming for AEGIS. Or just write a [STREAM](https://eprint.iacr.org/2015/189) 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](https://csrc.nist.gov/Projects/post-quantum-cryptography/round-4-submissions) and [library support](https://github.com/jedisct1/libsodium/discussions/1275) (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](https://github.com/samuel-lucas6/Kryptor/discussions/45). * Investigate [stdin](https://clig.dev/) 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~~](https://github.com/warner/wireguard-vanity-address) ~~public keys?~~ --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://www.kryptor.co.uk/roadmap.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.