If you would like to suggest a new feature, then feel free to open a feature request on GitHub. However, please read the Goals section first to ensure that your feature is not out of scope.
Note that I will probably not implement your feature if it is unnecessary/satisfies a rare use case or significantly increases code or user input complexity. For example, very few people currently own YubiKeys and adding support for SSH keys would add a fair bit of complexity since it would require supporting multiple different cryptographic algorithms.
The main aim of this release is to improve on design decisions from v3 that I am not happy with. As you can see below, there are quite a few things to work on, some changes require me to write a custom libsodium binding, and I am going to be very busy academically this year, meaning it will take a long time for this release to happen.
Bold text means a breaking change that will result in incompatibility with previous versions of Kryptor. Strikethrough text means the change will likely not happen.
Modify the ChaCha20-BLAKE2b implementation to reuse the same encryption key for each chunk. (DONE)
Switch from libsodium-core to Geralt once I manage to rewrite and finish the library. This will allow for much better naming, performance improvements, the correct implementation of certain functions, less clutter in terms of algorithm support, and publicly accessible constants that can be referenced.
Use ChaCha20-BLAKE2b with a counter nonce starting at 0. There is no need for a random nonce for file encryption or private key encryption. File encryption needs a counter nonce, and private key encryption can use a fixed nonce or SIV because each key is unique. This will save me from storing nonces, simplifying the file formats.
Store the original file name in an encrypted file header rather than appending it to the end of the input file. Pad it to a fixed length (255 bytes) to avoid giving away the length.
Store the amount of padding in the final chunk as a header rather than the last chunk length.
Do not use the previous authentication tag as additional data. This is unnecessary when a counter nonce is used and just worsens performance.
Consider using Base64URL for asymmetric keys.
Use some context information for domain separation when prehashing before Ed25519 signing.
Enforce a minimum password length of 8, 10, or 12 characters. This was done back when Kryptor had a GUI.
Consider compressing directories and encrypting the ZIP file. This would probably require an encrypted header indicating whether the file needs to be extracted after decryption. This would make directory encryption indistinguishable from file encryption, but it would prevent people from decrypting individual files.
Switch to a custom BLAKE2b KDF that allows for a longer salt and more context information.
Consider supporting a preshared key via the -k|--keyfile option to provide post-quantum security for file sharing.
Consider not chunking files less than 16 KiB. This would reduce storage overhead but reveal the size of small files unless some other padding was implemented.
Do not use Argon2id when only using a keyfile. This is unnecessary when the keyfile has enough entropy. Instead, use the hash of the keyfile as input keying material for salted BLAKE2b-512, with a random salt per file.
Enforce a minimum amount of entropy for non-random keyfiles.
Consider concatenating the long-term shared secret and ephemeral shared secret the other way around to comply with the Noise Protocol Framework specification.
Consider always prehashing for file signatures, as done by the latest version of Minisign. This makes sense from an efficiency, simplicity, fault attack countermeasure, and consistency perspective. However, Kryptor signs the Ed25519 variant, meaning it is not susceptible to this issue that affected previous versions of Minisign.
Investigate an indistinguishable from random encrypted file format. This would require more sophisticated padding, Elligator2 usage, and the magic bytes and version number would have to be removed.
Investigate specifying multiple recipients for hybrid file encryption. This is a lot easier said than done, especially to do it properly. This may never get implemented.
Consider allowing multiple signatures to be verified at once using -v|--verify.
Consider allowing multiple signature files to be specified via -t|--signature.
Consider supporting signing/verifying every file in a directory.