3 ms·
I would love to know why the programmer thought the second base64 would help. "No one would ever expect the data to be base64-encoded twice! Mwa ha!"
by haberman 11y ago
I would love to know why the programmer thought the second base64 would help.
"No one would ever expect the data to be base64-encoded twice! Mwa ha!"
- sarciszewski 11y agohttps://i.imgur.com/UUEDKYA.jpg https://i.imgur.com/UUEDKYA.jpg
- tedunangst 11y agoProbably. "Looks like gibberish. Base 64 decode it. Still looks like gibberish. Must be random bytes." Never mind that random bytes are not likely to all be ascii letters and numbers.
- startling 11y agoRandom ascii letters and numbers are just as good as random bytes.
- sarciszewski 11y agoSort of. There's less entropy per character if you know it will always be alphanumeric versus a string that of random bytes. If you take 32 bytes from /dev/urandom and base64 encode it, it has the same entropy as the original binary string (unless you use it in a way that will result in it being truncated). But the total entropy of the two strings is unchanged. One is just longer. In short: You're correct, but with nuance that bears stating explicitly.
- tedunangst 11y agoRandom ASCII letters decoded as base64 are unlikely to result in only ASCII letters. And if you generated random letters to start, there's no reason to base64 encode it.
- ams6110 11y agoThat's why I always base64-encode three times. And then swap the first and last character.
- douche 11y agoMan, you gotta rot13 that shit a couple times, just to be extra safe. And make sure you generate a random seed to to seed your RNG with. Twice as random, right?
- MichaelGG 11y agoYeah, I mean the IETF thought one pass of Base64 was good enough for HTTP.
- shanemhansen 11y agoHe knew that something wasn't quite bulletproof with his "encryption" scheme. He left a comment: "Won't stop 1337 hackers".