4 ms·

Sorry dude, your home-brew encryption scheme (not AES) is trivially breakable. All messages with the same key are XORed with the same stream of data, given mor

by pacaro 15y ago

Sorry dude, your home-brew encryption scheme (not AES) is trivially breakable. All messages with the same key are XORed with the same stream of data, given more than one message encrypted with the same key that is trivially reversible - see any cryptography text book for details. Your "seed" doesn't help because you include it in the message...

leeoniya 15y ago
heh, well it was a prototype. nothing in production. the crypto scheme was randomized between 3 algos to reduce the statistical data size for each. one was AES, one was alphacrypt, another one was something else. the json protocol exchanged an algo_id which was stored with each message. as for home-brew, i used the encrypt/decrypt code i found at the provided location. i'm no crypto expert and the guy claims to have a mathematics PhD with "Eleven years of publishing scientific and technical papers (computer science and higher-level mathematics)", so hopefully his security assertions are not entirely without merit. the key is not stored anywhere. it must be exchanged by other secure means, just like any symmetric encryption/AES. if you encrypt "a" using a key "foo" and the lib selects a random seed char to tack onto every word, there can (from what i understand) be 255 variations to encode the same plaintext word...and this set varies for each key. storing the seed, like storing a salt doesn't seem like it would help much. so it's not immediately obvious that having access to many messages encrypted using the same key would allow you to do any kind of trivial statistical analysis other than on word length alone. if it is in fact trivially breakable, i would love to see it implemented by simply having access to the encryption code and ciphertext of 5 different messages of several words in length encoded using the same key 100 times each. it'd be awesome to learn more about crypto....and about 100 other topics, too :)
- jbri 15y ago
  First of all the "seed" is bupkis because it's not actually used in the encryption - it's just used to xor the ciphertext, and then sent along with it. You can trivially reverse that step and then get on attacking the rest of it. After that, the attack is elementary: You have two plaintexts, A and B. These are both xored with the same keystream X, so the attacker has access to both A ^ X and B ^ X. Xoring both cipherstreams gives you A ^ X ^ B ^ X, which is equivalent to A ^ B. Do you see the problem yet, or do I need to continue? EDIT: The real point is if you're not a crypto expert, don't write crypto code. (If you are a crypto expert, you already know better than to try writing your own crypto code). Also, don't trust obscure web pages that present crypto implementations - use a widely-known (and hence widely-vetted) implementation instead.
  - leeoniya 15y ago
    maybe will just stick with the AES, then. thanks for the info!
    - pacaro 15y ago
      "The Code Book" by Simon Singh is awesome reading. It certainly explains how and why naive schemes like this are easy to crack. http://amzn.com/0385495323 http://amzn.com/0385495323

by pacaro 15y ago

leeoniya 15y ago

heh, well it was a prototype. nothing in production. the crypto scheme was randomized between 3 algos to reduce the statistical data size for each. one was AES, one was alphacrypt, another one was something else. the json protocol exchanged an algo_id which was stored with each message. as for home-brew, i used the encrypt/decrypt code i found at the provided location. i'm no crypto expert and the guy claims to have a mathematics PhD with "Eleven years of publishing scientific and technical papers (computer science and higher-level mathematics)", so hopefully his security assertions are not entirely without merit. the key is not stored anywhere. it must be exchanged by other secure means, just like any symmetric encryption/AES. if you encrypt "a" using a key "foo" and the lib selects a random seed char to tack onto every word, there can (from what i understand) be 255 variations to encode the same plaintext word...and this set varies for each key. storing the seed, like storing a salt doesn't seem like it would help much. so it's not immediately obvious that having access to many messages encrypted using the same key would allow you to do any kind of trivial statistical analysis other than on word length alone. if it is in fact trivially breakable, i would love to see it implemented by simply having access to the encryption code and ciphertext of 5 different messages of several words in length encoded using the same key 100 times each. it'd be awesome to learn more about crypto....and about 100 other topics, too :)

jbri 15y ago
First of all the "seed" is bupkis because it's not actually used in the encryption - it's just used to xor the ciphertext, and then sent along with it. You can trivially reverse that step and then get on attacking the rest of it. After that, the attack is elementary: You have two plaintexts, A and B. These are both xored with the same keystream X, so the attacker has access to both A ^ X and B ^ X. Xoring both cipherstreams gives you A ^ X ^ B ^ X, which is equivalent to A ^ B. Do you see the problem yet, or do I need to continue? EDIT: The real point is if you're not a crypto expert, don't write crypto code. (If you are a crypto expert, you already know better than to try writing your own crypto code). Also, don't trust obscure web pages that present crypto implementations - use a widely-known (and hence widely-vetted) implementation instead.
- leeoniya 15y ago
  maybe will just stick with the AES, then. thanks for the info!
  - pacaro 15y ago
    "The Code Book" by Simon Singh is awesome reading. It certainly explains how and why naive schemes like this are easy to crack. http://amzn.com/0385495323 http://amzn.com/0385495323