Imagine you build a bank vault with a 10-digit combination lock, but then wire the dial so only the last two digits actually move. Anyone who knows to try just 100 combinations walks in. That is what happened to AES-256 encryption in several major PDF implementations — the algorithm is fine, but the key generation collapses the 256-bit keyspace down to something trivially enumerable. The core finding: MuPDF (before 1.28.5) seeds its pseudorandom number generator with the Unix epoch in seconds, feeds it through a 48-bit linear congruential generator, then extracts output bytes from bits 17–24 of the state. Because higher bits never propagate downward in an LCG, and the bottom 16 bits are hardcoded to 0x330e, only 9 bits of the timestamp actually determine the AES-256 file key. That means 512 possible keys. An unoptimized Python brute-force finishes in 11 milliseconds. Foxit PDF Reader 2026.1.3 is worse in a different way. It derives the file key by hashing the current Unix timestamp, 32 uninitialized bytes (which in practice are zero-filled), and the string literal "there" through SHA-256. The keyspace equals the space of plausible timestamps. A Rust implementation on a Ryzen 9 7950X tests 370–376 million timestamps per second, covering every second since the Unix epoch in under 5 seconds. A recently created document falls in milliseconds. The Foxit pattern turns out to have a deeper lineage. The exact key derivation appeared in PDFium's initial public commit from May 2014, with file headers crediting Foxit for the original code. Other PDF editors likely inherited the same broken pattern through PDFium, making this a supply-chain problem rather than an isolated bug. OpenPDF 3.0.5 and iText 9.7.1 use a related but slightly stronger approach — an ARC4 stream seeded with a millisecond timestamp and JVM free memory — still far below the 256-bit security the format promises. The architectural error is the same in every case: the AES-256 spec protects the document with a random 32-byte file key, then wraps that key under a password-derived key with deliberate slow hashing (revision 6). This design assumes the file key has full 256-bit entropy. When the PRNG collapses that entropy, the entire password-protection layer becomes irrelevant — you skip the password entirely and just guess the file key. The practical consequence is stark. Any PDF encrypted by affected MuPDF versions can be decrypted without any password, anywhere, in 11 milliseconds. For Foxit, the cost is a few seconds at worst. The researchers published working decryptors for both. Previously encrypted documents cannot be retroactively fixed. MuPDF patched in version 1.28.5; Foxit's status is less clear, and the PDFium-derived pattern may persist in other editors. This is a textbook case of what happens when cryptographic APIs are treated as black boxes. The algorithm works perfectly; the randomness feeding it does not. The gap between the promised security level (AES-256, 2^256 keyspace) and the delivered security level (9 bits, 512 keys) is among the largest ever documented in production software. It is a reminder that key generation is the most dangerous line of code in any crypto implementation.
