The case of the 9 bit AES key
ledoge
101 points
50 comments
October 28, 2026
Related Discussions
Found 5 related stories in 120.5ms across 10,874 title embeddings via pgvector HNSW
- RSA-896 madars · 90 pts · September 20, 2026 · 52% similar
- I've factored the RSA keys of a Certificate Authority from the 90s ahlCVA · 232 pts · September 08, 2026 · 48% similar
- Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds hkc · 870 pts · October 21, 2026 · 48% similar
- Anthropic publishes a practical key-recovery attack on HAWK-256 bakigul · 57 pts · July 28, 2026 · 45% similar
- NSA and IETF, Part 9 libroot · 43 pts · August 15, 2026 · 44% similar
Discussion Highlights (10 comments)
paulpauper
it's like the weak hardware wallet entropy bug
jeffbee
You'd have to be completely off your rocker to use a PDF tool written in C anyway.
ubutler
Rule #1 of rolling your own RNG: don’t. Rule #2? Please don’t.
tptacek
"MuPDF versions before 1.28.5 use an implementation of the drand48 family" yeah, ok, so they're basically not doing real encryption. The number of bits in the key space isn't the real story; the keys simply aren't cryptographically random.
NelsonMinar
What is wrong with software engineers that we keep making really stupid basic mistakes like this? Sometimes I think programming should require licensing and regular testing.
RobotToaster
Obligatory xkcd https://m.xkcd.com/221/
esafak
I assume this is the fruit of AI-driven decompilation? Nice work.
jburgess777
Does the DMCA still make it illegal to access encrypted content no matter how easy it is to discover the key? https://www.law.cornell.edu/uscode/text/17/1201 Would the new LLM model owners like to strike this down, or use it to demonstrate how dangerous unrestricted models can be?
snvzz
That's way too many PDF implementations affected by this category of stupidity. It makes me wonder: Coincidence, really? There's enough there to think that there might be some invisible hand behind it.
philsnow
It's so insane to have PDF programs doing their own encryption, not because "don't roll your own crypto" (although yes for that reason too), but because the people who write PDF programs (libraries, viewers, general-purpose tools like qpdf, etc etc) aren't (necessarily) going to be great at understanding or designing good encryption UX. Also, I get that a lot of sensitive information is exchanged with PDFs these days, but why should PDFs have encryption built-in to the file format? Sensitive information is also exchanged in image files, word documents, zip files, html, etc etc etc etc. If you take all the work that goes into making the crypto UX decent for one kind of file and apply that to "all files", then each ecosystem doesn't have to invent their own. This is just like "high-end" car manufacturers insisting on making their own software, and not integrating apple carplay. They're either going to make a truly shitty podcast app, or they're not even going to bother and instead tell people to use bluetooth to listen to podcasts like it's 2006.