bamboo comments on I wonder if this was made by AI or a shit programmer

[–] bamboo@lemmy.blahaj.zone 10 points 1 year ago (2 children)

I'm not familiar with NSA’s Translator, so any info would be appreciated.

I saw your other comment about DES, and it should be noted that DES was with a key length of 56 bits, and that was enforced precisely because the NSA could brute force it. It wasn't even a secret they could brute force 56 bit encryption, and written into law. Back then, if you wanted to use more than 56 bit encryption in the United States, you had to provide a key escrow system to allow the government to decrypt the content if they needed to. Around the 2000s with the rise of e-commerce, they dropped the export restriction because it was doing more harm than good. No one wanted to use so few bits in the encryption keys, but it was illegal at the time to write software which did.

A UUID's 122 bits of randomness are exponentially more than the 56 bits DES offered. My original point being, all crypto is inherently brute forceable on an infinite timescale, but key length and implementation decisions are chosen to so that it would be computationally infeasible to brute force.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] 01189998819991197253@infosec.pub -2 points 1 year ago (1 child)

The Translator was the nickname given to, what essentially was, the NSA supercomputer that could solve any (non-shift text) encryption by bruteforcing the key in under an hour (most of the time, in about 15 minutes). I mentioned DES, because it was an encryption so old that nearly everyone has heard about it, and one that I know was used on The Translator. And you're right, DES was capped at 56 bit keys, because they could crack it without The Translator, if needed.

But the scope isn’t if the UUIDs are crackable (which, of course, they’re not, since they’re not encrypting anything). The scope is if using UUIDs as filenames in this publically accessible db a good way to hide the files. And the answer is: no it is not a good way, because a computer powerful enough can guess all possibilities in a matter of minutes, and query them all against the db to discover all files stored within.

permalink

fedilink

source

parent

hideshow 1 child comment

[–] bamboo@lemmy.blahaj.zone 5 points 1 year ago

a computer powerful enough can guess all possibilities in a matter of minutes, and query them all against the db to discover all files stored within.

Again, it would be computationally infeasible on any reasonable timescale of human existence. It's no secret what every possible UUID would be, it's the fact there are 5316911983139663491615228241121378303 of them and trying each one would be futile. They're actually all on https://everyuuid.com/ to see for yourself.

Just for shits, I encrypted a file with a password being a UUIDv4. Here's the encrypted file as base64:

YLIR6fL46HfRmueb1tZWiQUFQHYnZOKO9oujOzhvWYpfTtB5RnHtAvMgUgeIsffLC1wz7D17Vp0VT5YIJMb5pA==

Here's everything you would need to do to decrypt this file with a password:

$ echo "YLIR6fL46HfRmueb1tZWiQUFQHYnZOKO9oujOzhvWYpfTtB5RnHtAvMgUgeIsffLC1wz7D17Vp0VT5YIJMb5pA==" | base64 -d > file.enc

$ openssl enc -aes-128-cbc -d -nosalt -in file.enc
enter AES-128-CBC decryption password:
u/01189998819991197253@infosec.pub can't brute force this

The password to decrypt the file is a UUIDv4. See if you can try every UUID and figure out which one I used as the password.

permalink

fedilink

source

parent