The case of the 9 bit AES key
Comments on “The case of the 9 bit AES key”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Security firm V12 reports that several PDF tools generate AES-256 file keys from tiny, guessable state. In MuPDF before 1.28.5, only nine bits of the timestamp seed affect the key, so 512 candidates cover every case and a Python search takes about 11 ms. Foxit Reader hashes a timestamp with zero-filled bytes, and a Rust search covers every second since 1970 in under five seconds. OpenPDF and iText are also affected. MuPDF is fixed; the findings are the authors' own and unverified independently.
Why it ranked
No. 7 of 110 with a score of 0.72. The panel rated it highest on technical depth (0.94) and new information (0.93), lowest on audience breadth (0.53). The judges disagreed most on significance (spread 0.41), so the story is marked contested. Placed No. 7, No. 6 by score alone: the fifth Security story of the day (−0.040). The placement terms move stories; they are not part of the score.
- AI judgeJudge 2claude-haiku-5-5
- Strong, well-evidenced security research with reproducible technical detail on PRNG weaknesses in PDF encryption; significant to security practitioners but narrower audience than mainstream tech news.
- AI judgeJudge 3gpt-5.6-luna
- Primary technical investigation with source-level analysis, reproducible exploit code, measured brute-force performance, affected implementations, and disclosed fixes. It reveals severe cryptographic failures with direct implications for PDF security and software maintainers.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.72total under rubric v2.3Contestedjudges differ by 0.41 on significance
- Significance0.63
- Reader interest0.84
- Audience breadth0.53
- Practical relevance0.75
- Substantiated0.93
- Technical depth0.94
- New information0.93
- Counts against: Promotional0.03
- Counts against: Overclaim0.17
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.59 | 0.45 | 0.86 | 0.63 | 0.41 , above the contested threshold | +0.24 | +0.152 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.75 | 0.80 | 0.96 | 0.84 | 0.21 | +0.26 | +0.218 |
| Audience breadthHow many people who build technology does it concern? | 0.58 | 0.40 | 0.62 | 0.53 | 0.22 | +0.13 | +0.069 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.77 | 0.60 | 0.88 | 0.75 | 0.28 | +0.22 | +0.165 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.99 | 0.85 | 0.94 | 0.93 | 0.14 | +0.05 | +0.046 |
| Technical depthHow technically substantive is it? | 1.00 | 0.85 | 0.96 | 0.94 | 0.15 | +0.05 | +0.047 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.91 | 0.90 | 0.99 | 0.93 | 0.09 | +0.05 | +0.047 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.04 | 0.03 | 0.02 | 0.03 | 0.02 | −0.19 | −0.006 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.22 | 0.20 | 0.08 | 0.17 | 0.14 | −0.11 | −0.018 |
| Sum of contributions | +0.719 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.719 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-29/7/"><img src="https://rubric.hrih.si/badge/2026-10-29/7.svg" alt="Ranked #7 on Rubric, 29 Oct 2026" width="238" height="28"></a>Claim check
Claim check: 7 no source given · 1 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
In MuPDF, only 9 bits of random state affect the actual AES-256 key.
The article gives no link or citation for it.
The article says “In MuPDF, only 9 bits of random state affect the actual AES-256 key”
The source says No source to compare with.
No source givenVersion
MuPDF versions before 1.28.5 use an implementation of the drand48 family to generate random numbers, seeded once with the current epoch in seconds.
The article gives no link or citation for it.
The article says “MuPDF versions before 1.28.5 use an implementation of the drand48 family to generate their random numbers”
The source says No source to compare with.
No source givenNumber
Timestamps that differ by 512 seconds produce exactly the same byte stream in MuPDF.
The article gives no link or citation for it.
The article says “Timestamps that differ by 512 seconds produce exactly the same byte stream”
The source says No source to compare with.
No source givenNumber
Searching all 512 MuPDF key streams in an unoptimized Python implementation takes about 11 milliseconds.
The article gives no link or citation for it.
The article says “Searching all 512 streams in a very unoptimized python implementation using pure brute force takes about 11 milliseconds”
The source says No source to compare with.
No source givenVersion
Foxit PDF Reader 2026.1.3.36551 derives the file key as a hash of the current timestamp, 32 uninitialized bytes, and a constant.
The article gives no link or citation for it.
The article says “Foxit PDF Reader 2026.1.3.36551 derives the file key as a hash of the current timestamp, 32 uninitialized bytes, and a constant”
The source says No source to compare with.
No source givenBenchmark result
On a Ryzen 9 7950X with 32 threads, the authors' Rust implementation sustains 370 to 376 million timestamps per second, searching every timestamp since 1970 in 4.85 seconds.
The article gives no link or citation for it.
The article says “On a Ryzen 9 7950X with 32 threads it sustains 370 to 376 million timestamps per second”
The source says No source to compare with.
Couldn’t checkDate
The same key derivation was present in PDFium's initial public commit from May 2014, whose file header credits Foxit for the original code.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “It was already present in PDFium’s initial public commit from May 2014. The file header credits Foxit for the original code”
The source says No passage could be compared.
Source cited by the article: github.com/chromium/pdfium/blob/5110c4743751145c4ae1934cd1d83bc6c55bb43f/core/src/fpdfapi/fpdf_parser/fpdf_parser_encrypt.cpp
No source givenCausal conclusion
The insecure randomness in these implementations led to weaker keys in practice, and the issues were disclosed to vendors and fixed in MuPDF's case.
The article gives no link or citation for it.
The article says “What was supposed to be a security upgrade over older file keys derived from the user’s password instead led to weaker keys in practice”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 101 pts, front page
Recorded for context only, checked 29 Oct 2026, 05:47 UTC. It played no part in the ranking.