-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Reminder: Providing misinformation is a violation of the DSA laws of the EU.
By the way, all of this has already been refuted and explained away by the lead developer of Veracrypt, which this very project was forked from, here: "Mounir IDRASSI - 2024-08-17".
The author/maintainer misinforms their users claiming that AES encryption will be broken by quantum computing. They mention that using Grover's algorithm would weaken AES keys. However, that's entirely misleading. To the contrary, the main key algorithms considered to be under any serious threat from quantum-based computing would be asymmetrical encryption key algorithms, like DSA and RSA-based PGP keys, because of Shor's algorithm. Symmetrical encryption keys, such as is used in AES and for Veracrypt, on the other hand, are not vulnerable to Shor's algorithm, and the threat imposed by Grover's algorithm would equally affect all encryption keys, including ML-KEM. Therefor, using ML-KEM on its own would accomplish nothing useful in reference to Grover's algorithm. Because it's essentially an attack which takes time to guess at the potential answer, larger key sizes are the only known defense against Grover's algorithm, since the larger the key space the longer it takes, and 256 bit keys are already considered sufficiently large enough to make any attack based on Grover's to be practically infeasible.
As it so turns out, classical computers are already perfectly capable of running Grover's algorithm, and would thus already have broken all encryption, were that really any threat. In practice, even with the aid of a quantum computer, the best that Grover's algorithm can hope to provide in any reasonable length of time, and against current key sizes, is that it might reduce the security margin offered by AES encryption by roughly half. In other words, this means that it might reduce a 256bit AES key down to a 128bit AES key, and that's already considered sufficiently safe enough to secure our nation's Top Secret information, according to the NSA.
Not only does this repository provide misinformation, but it also poses a threat to safety. Using asymmetrical encryption algorithms for the purpose of encrypting data at rest is not only completely unnecessary, but could in fact be hazardous, since this is not the type of data it was designed to secure. Data at rest is vulnerable to a host of alternate attack methods which aren't sufficiently mitigated against by the safeguards provisioned for in asymmetrical key encryption schemes. They are designed to make using encryption to secure data in-flight a little more practical, because having to use symmetric encryption would lead to a number of drawbacks. This poses a threat to anybody relying on that erroneous misapplication of technology, because they might be lured into a false sense of security and end up making decisions which would lead to disastrous consequences, due to expecting the security to provide assurance against the sorts of attacks this technology is not designed for. ML-KEM is not even an asymmetrical key cypher, anyways. It's actually a key encapsulation cypher, which still relies on DSA/RSA/ECC underneath for the actual encryption of the data.
Any cryptographer worth their salt would know all this, which means that whoever the person behind this project is can't be a cryptographer and shouldn't even be attempting to write any encryption software whatsoever, because even if it seems to follow the NIST recommendations, the devil is in the implementation. If the implementation is in anyway invalid, so is the encryption along with any guarantees it hoped to offer, leaving the user in an even worse state than would they be if they hadn't used any encryption, at all. Again, it's far more dangerous to have a false sense of security than no expectation of security.
Providing a false sense of security, and hence placing users in peril, is the only thing this software could hope to accomplish, and that makes it practically a scam, because it lures the user into making poor decisions based off invalid/misleading assurances. Nobody should ever use this dangerous code.... EVER! Please, remove it from Github, promptly.