# 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: 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 current page URL with the `ask` query parameter:

```
GET https://www.kryptor.co.uk/roadmap.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.