troydaniels / polar-encrypt Goto Github PK

Where to begin...

• Never ever call your crypto unbreakable. This is directly asking to be made fun of.
• Some of your outputs have two numbers and some have three. The page source goes "" and the output line word count is all like "222222222233332". Gee, I wonder where the lowercase letters are?
• You effectively have a block cipher operating in counter mode. This means that an adversary who has a plaintext/ciphertext pair can determine if a new message has the same or a different block at each position. This is made disastrously worse by the fact that your blocks are character-sized instead of 128 bits or longer, and that your counter wraps around after the key length instead of after 2^128 elements.
• Like the Vigenere ciphere, you are vulnerable to frequency analysis. The attacker rotates through the possible periods, checks when the resulting frequency tables look like html page source frequencies, then matches up characters. The fact that you're rotating more for some characters, due to outputting more values, makes this a bit non-standard at the moment but it can still be done.
• You don't have any authentication. This is a big problem. Watch this talk. You are vulnerable to replay attacks. You are vulnerable to oracle attacks.
• It's possible to distinguish messages encrypted by different keys, because the generated points are more precise than necessary. This might even allow attackers to brute force parts of the key from a single output point.
• Adversaries can probably learn quite a lot about your key by intercepting ciphertexts, perturbing the points a bit, asking you to decrypt it, and seeing if you throw an error due to a rounding error mangling the message.
• Saying that the mapping can map from 0..b to 0..inf, and then pretending your key has infinite entropy, is simply wrong. In practice people will have finite sized keys.
• Did you make the code resistant to timing attacks?
• What is the polar coordinate transform adding, here? Why not use a finite field instead?
• You always encrypt a plaintext into the same ciphertext. This is very bad for protecting repetitive data, like weather reports.
• Your unit tests check the happy cases, but not the bad cases where attackers give tampered data and you fail gracefully.
• Although the message as a whole depends on the entire key, each character is affected by only small portions of the key. This means that changing one bit of the key will affect only a small fraction of the resulting ciphertext's bits. You want an avalanche effect, where changing any bit of the key tends to change approximately half of the ciphertext bits.