Suggesting a new feature

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 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 several other cryptographic algorithms, meaning more dependencies.​


I am currently revising and taking exams, so not much progress will be made towards this release during this time.
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. Furthermore, some changes depend on me finishing my custom libsodium binding.
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 after some more thought.
  • Modify the ChaCha20-BLAKE2b implementation to reuse the same encryption key for each chunk. (DONE)
  • Modify the ChaCha20-BLAKE2b implementation in Geralt to improve the performance.
  • 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.
  • 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. (DONE)
  • Do not append the file name to encrypt zero byte files. (DONE)
  • Encrypt a ZIP without compression of the parent directory for directory encryption. This will require an encrypted header indicating whether the file needs to be extracted after decryption. This will make directory encryption indistinguishable from file encryption but prevent people from decrypting individual files inside the directory. (DONE)
  • Include the public keys, not just the shared secret(s), in the key derivation for private key and private and public key file encryption. (DONE)
  • Do not use the previous authentication tag as additional data. This is unnecessary when a counter nonce is used and just worsens performance. (DONE)
  • Consider using 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 would save me from storing nonces, simplifying the file formats.
  • Store the amount of padding in the final chunk as a header rather than the last chunk length. (DONE)
  • Consider using Base64URL for asymmetric keys.
  • Consider using 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.
  • 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. (DONE)
  • 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.
  • Support signing each file in a directory. (DONE)
  • Consider supporting verifying each file in a directory.
  • Use sodium_mlock() to ensure that sensitive arrays can always be zeroed out properly. This is not available in libsodium-core.
  • Switch to sodium_memcmp() for constant time comparison. This is not available in libsodium-core.
  • Switch to sodium_memzero() for erasing sensitive arrays. This is not available in libsodium-core.
  • Allow verifying a signature without specifying the message if the message is in the same directory. This would mean you could either specify just the message or signature rather than just the message or the message and signature.
  • Do not encrypt files/folders that have invalid characters in their name. (DONE)
  • Remove wrapper classes thanks to Geralt usage.
  • Improve file encryption performance as much as possible.
  • Use Spans or array slices.

Website improvements

  • Rewrite the tutorial to specify use cases (e.g. file storage, file sharing, signing, verifying). (DONE)
  • Write separate Running Kryptor on macOS instructions. (DONE)
  • Add Linux ARM64 building from source CLI instructions. (DONE)
  • Add macOS ARM64 building from source CLI instructions when the next libsodium NuGet is released. (DONE)
  • Explain how to set the PATH variable or aliases for installation?
  • Correct the default key pair directory path for macOS. I only recently tested the program on macOS. (DONE)
  • Improve the Goals section. (DONE)
  • Update the Verifying signatures section for v3.1.0+. (DONE)
  • Link functions consistently on the Technical details page. (DONE)
  • Reread all pages of the website. Check for errors after GitBook update. (DONE)
  • Upload diagrams for the Technical details page. (DONE?)
  • Upload GIFs for the Running Kryptor sections on the Installation page?