Known limitations

Note that most of the following limitations will be resolved in the next major version of Kryptor, as explained by the informational hints. Please see the Roadmap for more information.
File metadata
Kryptor files are identifiable by looking at the magic bytes. You cannot hide the fact that a file was encrypted by Kryptor since the magic bytes, version number, and ephemeral public key are authenticated, meaning they cannot be tampered with. Curve25519 ephemeral public keys are also distinguishable from random.
Furthermore, Kryptor does not strip the timestamps from encrypted files because they may be useful for cloud synchronisation and proper timestomping is more complicated than simply changing the standard timestamps.
An idea for v4 was to make the encryption file format truly indistinguishable from random (e.g. no magic bytes). However, this is not planned for the following reasons:
1.Since Kryptor is/was on the machine used to encrypt files, it provides a strong indication of where a bunch of random files came from, meaning it would not work for deniability in many cases.
2.Seeing lots of random files, especially if they are large, is likely more suspicious than seeing regular encrypted files and suggests you have something more serious to hide. Average people do not have a bunch of randomly generated files laying around.
3.It would require using Monocypher as well as libsodium to get access to Elligator2 whilst maintaining the same level of performance for the other cryptography. It is less than ideal to have to rely on multiple cryptographic libraries.
4.It would limit input validation, leading to a worse user experience.
Directory encryption
If a password and/or keyfile was used for directory encryption, then an attacker can determine whether multiple encrypted files were encrypted using the same password and/or keyfile by looking at the salt of each encrypted file. However, they cannot tell whether the files were encrypted using a password, a keyfile, or a password and a keyfile. This is unavoidable when allowing the user to decrypt files individually rather than forcing them to decrypt the entire directory.
Another quick way of identifying whether a directory was encrypted using a password and/or keyfile is by looking for the kryptor.salt file. Directories encrypted using asymmetric keys do not have this file.
Finally, the number of files in an encrypted directory is also not a secret.​
This will change in v4 because directory encryption will result in a single encrypted file, meaning no difference between an encrypted file and an encrypted directory, no two files will have the same salt, and the number of files inside the directory will be hidden.
Using shared secrets directly
A current v3 design flaw is that the key derivation for private key and private and public key based file encryption does not include both public keys involved in the key exchange. This is advised against in the libsodium documentation as it can cause subtle vulnerabilities. Including the public keys also improves the entropy of the key, although only insignificantly.
Unfortunately, I somehow overlooked this detail as APIs like crypto_box() and crypto_key_exchange() do not do this. Fortunately, it is not a serious problem with Kryptor as the recipient is expected to use a known/verifiable public key and a random salt is used for key derivation.
This will be fixed in v4.
Compromised machine
If an attacker has physical or remote access to your machine, then they could retrieve sensitive data (e.g. encryption keys) whilst Kryptor is running.
Note that Kryptor does attempt to zero out sensitive data as soon as possible from memory. However, this currently cannot be guaranteed due to garbage collection in .NET.
This is a limitation for all software using cryptography, not just Kryptor. Software cannot magically run securely on a compromised device.
However, v4 will use some memory pinning, which should guarantee that certain arrays are zeroed.
​Ed25519 for digital signatures can also be susceptible to fault attacks when an attacker has physical or remote access to the machine. As this is generally only a concern for embedded devices and most mitigations are slow and ineffective, this type of attack is typically not protected against.
However, like Minisign, Kryptor verifies an authentication tag that includes the private and public key prior to signature generation. Prehashing also offers some protection for the message, but Kryptor does not prehash by default/in all cases as it affects the collision resistance of the signature algorithm.
For the reasons outlined above, there are no plans for implementing further countermeasures. Memory dumping is more practical and harmful.
Post-quantum security
The asymmetric algorithms in Kryptor are not post-quantum secure. However, this should not concern you yet because such quantum computers are hopefully a long way off.
Once post-quantum cryptographic algorithms become common in online protocols and available in libsodium, I will investigate making the switch to future-proof Kryptor.
Until then, v4 will introduce support for a pre-shared key as part of the key exchange, which will provide post-quantum security.
Best practices
Technical details
Last modified 1mo ago
Copy link
Outline
File metadata
Directory encryption
Using shared secrets directly
Compromised machine
Post-quantum security