Great time for by modem to reset. :/ But that's what signing is for.
https://pastebin.com/WsRmRCJn
Beyond 4 chars we are going to have to get a lot smarter with how we pick what passwords to try. It not hard to imaging a 20 char passphrase.
One way to do this is to try the endings of long dictionary world and short words with a space and short random prefix. Then run the same set through 1337 speak substitutions. And then add ending punctuations.
Another idea I had is to score perspective random passwords based on the combinatorial frequency of character pairs. "TH" is more common than "ZD". We could have crunch generate a 100, 000 times as many passwords as we could directly check and then filter them down to the top 99.999th percentile.
Obviously the optimizing it from the start would be better. But I don't think I'm smart enough to work out all of the patterns in how people chooses passwords and phrases or to build a highly optimized generator (I could eventually, but I'm not going to spend the rest of my life on this).
In the short term we could keep a file of all failed password. Diff might get awfully bogged down comparing TB scale sets. But if the archive is kept asciibetically presorted then a custom tool could be it efficiently enough for it to be worthwhile.
SecureRandom basically works by taking the password, hashing it with SHA1 to set the initial state (160 bits, 20 bytes), passing these bytes out as requested, and rehashing the state to create a new state when it runs out of bytes. It does this as many times as needed to create as many psudorandom bytes as requested.
This data is first used to shuffle a list of integers (0 to the number of DCT coefficents, which is also happens to be the number of pixels) which is used as a secret treasure map to scatter bits the message throughout the image. Further output of SecureRandom acts as a simple XOR cypher upon the payload message.
Without the password we don't even know which bit of what pixels and in what order contain the encrypted message. We are not even sure there IS a message. It could just be a wonky JPEG encoder.
Any kind of REAL cryptanalysis, linear or differential, is waayyyyy out of our league. And the password is always going to be the weakest part of the system. Efficient and smart password guessing is really the only option.
If you want to see the exact details you can download it directly from Oracle. https://download.java.net/openjdk/jdk8/
That is exactly what I did immediately.
Lines 147 to 149. I also early abort if the 32bit message length comes out as an unreasonable number. It should never be more then a couple kilobytes.
BruteCrackPK.java. Give it a file and feed it lines through STDIN. I haven't got around to multithreading it. So just run it in four terminals.
https://pastebin.com/hu1nZLLn
When ( if ) I ever stop getting distracted by side projects, I intend to make a C based implementation. There are a lot of steps between the five state integers in the SHA algo and the permutation table could be trimmed down.
-
Add the above to the F5-steganography files from here. Drop in next to Embed and Extract compile.
https://github.com/matthewgao/F5-steganography
That's odd. I found the same image on Medium last week and it had the same hash as the one from /pol/. Now it doesn't. It has indeed been changed. And the archive now has one with yet a different hash.
Someone is cleaning up. Good thing we have offline backups.
All of the files from our reduced set all traced back to Medium, Motherboard, or Flipboard. And I spot checked a few of them last week; and the files from there had the same hashes as on their source sites.
CM has been doing that here too, but without changing the filenames. After we found a easy way to spot the products of the weird JPEG encoder used by PixelKnot (hash the first 100 bytes) images posted here with that characteristic started being reencoded behind the scenes. 4Chan has probably heard by now and is doing the same.
I posted this image that I made with PK,
It has been totally reencoded. It's not a case of them appending a few bytes.
8chan uses the SHA256 sums of files when they're uploaded to uniquely identify them. Grab a random file from around here and check it. The SHA256 hash of the above impostor is now
e27a833560d84ee9260920b61f8ec4de287386b2eddd22774c885b929b32b38b
They would never just stick extra bytes onto the end of a file. And they have no reason to "bust the cache" for guaranteed uniquely named static content. It's only files missing their JFIF headers that are mysteriously changing.