# Known limitations ## Unicode passwords Kryptor uses [UTF-8](https://www.rfc-editor.org/rfc/rfc3629) to convert password strings/characters to bytes. Unfortunately, [Unicode normalization](https://www.unicode.org/reports/tr15/) is not applied, meaning the same Unicode character can get encoded in different ways depending on the operating system, keyboard, etc. This can cause issues decrypting files when non-ASCII characters are used in a password. Sadly, there's no pretty solution to this problem. Even if you use Unicode normalization, you can [still](https://1passwordstatic.com/files/security/1password-white-paper.pdf) encounter this issue, so it's only a partial fix that annoyingly duplicates the password in memory. Confusingly, there are also multiple forms of normalization, with different organisations [not](https://pages.nist.gov/800-63-3/sp800-63b.html) [agreeing](https://datatracker.ietf.org/doc/html/rfc8265) on which one developers should use. To eliminate the problem, you have to enforce [ASCII](https://www.rfc-editor.org/rfc/rfc20) characters, which some people are against since it's restrictive and reduces password entropy for the same number of characters. Furthermore, organisations like [NIST](https://pages.nist.gov/800-63-3/sp800-63b.html), the [IETF](https://datatracker.ietf.org/doc/html/rfc8265), and [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) recommend supporting Unicode characters. However, people should be randomly generating passwords/passphrases using a [password manager](https://bitwarden.com/password-generator/) or [Diceware](https://en.wikipedia.org/wiki/Diceware) (even if you're going to memorise them), which results in ASCII passwords unless you go out of your way to use Unicode characters (e.g. a [non-English wordlist](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md)). Additionally, some websites don't support Unicode passwords, and websites that do support Unicode passwords have password reset functionality in case there's an issue, which isn't possible with an offline application. ## Multi-recipient sender authentication Kryptor currently only has sender authentication with a single recipient or if all recipients are honest. When sending a file to multiple recipients, if any are malicious or have had their private key compromised, they can create a new file that looks like it came from the original sender. This is possible because all recipients have access to the same file key (to avoid encrypting the file repeatedly, which is slow and would require sending multiple files) and the wrapped keys aren't tied to that specific encrypted file payload (they can be decrypted independently of the payload). Protecting against this requires processing the entire file in one go rather than or as well as in chunks, either using a signature scheme (outsider non-repudiation) or a MAC (insider non-repudiation). This is something that was actively avoided due to the benefits of chunking. ## 20 recipients An indistinguishable file format means [more complicated parsing](https://en.wikipedia.org/wiki/PURB_\(cryptography\)#Encoding_and_decoding_PURBs), and you don't want to leak the number of recipients. As such, I decided to use a fixed header format like before. This is simple but less efficient, adds constant storage overhead regardless of how many recipients you have, and limits the number of recipients to 20. However, this was the [original](https://github.com/FiloSottile/age/issues/139) limit with age and should rarely be a problem. ## File metadata Whilst encrypted files are intended to be indistinguishable from random data, if an attacker knows that the same file has been encrypted many times, they may be able to determine the unpadded file length. The headers are also fixed in size, so there's a range of small file sizes that Kryptor doesn't produce. Thus, files of the minimum length could be seen as an indicator that Kryptor was used. However, dummy random files could be stored to address this type of problem. Finally, the timestamps on encrypted files are currently untouched. This may change in the future, perhaps only when file name encryption is specified, but [proper](https://www.inversecos.com/2022/04/defence-evasion-technique-timestomping.html) [timestomping](https://attack.mitre.org/techniques/T1070/006/) is more complicated than simply [changing](https://docs.microsoft.com/en-us/dotnet/api/system.io.file.setcreationtime?view=net-6.0) the [standard timestamps](https://az4n6.blogspot.com/2014/10/timestomp-mft-shenanigans.html). ## Post-quantum security The **asymmetric** algorithms in Kryptor aren't [post-quantum secure](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.html?nn=433196). However, a pre-shared key can be specified when encrypting with your private key to add post-quantum security. Alternatively, you can [keep your public key secret](https://crypto.stackexchange.com/q/119226/102678) (e.g., when encrypting files to yourself or only sharing it with people you trust via an [end-to-end encrypted messenger](https://signal.org/) with [disappearing messages](https://support.signal.org/hc/en-us/articles/360007320771-Set-and-manage-disappearing-messages) enabled). Why a pre-shared key instead of post-quantum algorithms? * Pre-shared keys are known to be post-quantum secure (when managed correctly). In contrast, various post-quantum schemes have been [proven](https://eprint.iacr.org/2022/214) [insecure](https://eprint.iacr.org/2022/975), with post-quantum cryptography having generally received less study. * Supporting pre-shared keys is simple, whereas post-quantum or hybrid KEMs mean a protocol redesign. * Standardisation is ongoing for both [post-quantum](https://csrc.nist.gov/projects/post-quantum-cryptography) and [hybrid](https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem) crypto. In Kryptor, there's also KEM [obfuscation](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-kemeleon) and [signatures](https://csrc.nist.gov/projects/pqc-dig-sig) to consider. * The cryptographic libraries used by Kryptor don't support post-quantum crypto yet, and it's preferable to have as few dependencies as possible. Therefore, waiting is sensible. * Post-quantum crypto is far from the norm in practice today. For example, the [NSA](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF) and [UK NCSC](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines) mention a deadline of 2035 for migration. As of December 2025, [BSI](https://www.bsi.bund.de/dok/study_status_quantum_computer) estimate cryptographically relevant quantum computers (CRQCs) will be available within 15 years (by 2040). ## Hardware support [ChaCha20-Poly1305](https://www.rfc-editor.org/rfc/rfc8439) is not as fast as algorithms like [AEGIS](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aegis-aead) and [Rocca-S](https://datatracker.ietf.org/doc/html/draft-nakano-rocca-s) with hardware support. However, it's still fast, doesn't require hardware support, is widely used, and the cryptography is unlikely to be a performance bottleneck compared to disk IO. With that said, ChaCha20-Poly1305 will likely be replaced in the future. ## Compromised machine If an attacker has physical or remote access to your machine, they could retrieve sensitive data (e.g. encryption keys) whilst Kryptor is running. This is quite literally impossible to prevent. However, Kryptor does attempt to zero out sensitive data as soon as possible from memory. With pinning, this should be guaranteed, but sometimes pinning can't be used. For example, non-interactive string inputs (e.g. pre-shared keys) can't be erased from memory and will unfortunately get [leaked](https://www.netmeister.org/blog/passing-passwords.html) into the process table/shell history. [Ed25519](https://ed25519.cr.yp.to/) for digital signatures can also be susceptible to [fault attacks](https://eprint.iacr.org/2017/1014.pdf) when an attacker has physical or remote access to the machine. As this is generally only a concern for [embedded devices](https://cybermashup.files.wordpress.com/2017/10/practical-fault-attack-against-eddsa_fdtc-2017.pdf) and most mitigations are [slow and ineffective](https://eprint.iacr.org/2017/1014.pdf), this type of attack is typically not protected against. --- # 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/security-limitations.md?ask= ``` 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.