51–60 of 75 posts
The genius of this is the realization that browsers do not send the named anchor (technically "fragment identifier"[1]) to the server. Using the named anchor as the cryptographic key enables users to pass around simple URLs to encrypted data. Data is stored on the server, but the server never has access to the complete URL with the key, so it cannot decrypt it. As others have pointed out, this doesn't protect the dat…
Earlier quoted context omitted.
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...
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…
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.
Earlier quoted context omitted.
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…
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 cipher…
thanks for the info!
Earlier quoted context omitted.
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 cipher…
maybe will just stick with the AES, then. thanks for the info!
Earlier quoted context omitted.
So what happens when Zerobin or SnipURL is ordered to take down "all posts from the same client IP address as the post with the shortened URL of ..."?
Don't log IPs? End user IP's are mostly dynamic anyway.
Imma gonna clear all my caches and de-bank my cash. Imma gonna get a plane ticket to the Isle of San Mosh. Imma gonna get away from The Man, away from all this tosh.
Imma gonna paste my data where nobody can see. Imma gonna paste my data where it can be truly free. Imma gonna paste my data in grandma's apple tree.
So, the same thing as https://ezcrypt.it/ ?
This is so ingenious that it baffles me how no one thought of it before. Needs an alternative way of unlocking. A short link and then a passphrase generating key.