The case of the 9 bit AES key

PDF AES-256 encryption relies on a randomly generated 32-byte file key, which is then protected by password-derived keys. The analysis shows that this design can fail when implementations generate the file key with weak randomness: the advertised 256-bit strength does not help if the key comes from a tiny or predictable set. In MuPDF versions before 1.28.5, a timestamp-seeded drand48 generator supplies the key. Because of how its output bytes are formed, only nine timestamp bits affect the key, leaving just 512 possible streams. The document’s plaintext /ID field provides an additional way to identify the right candidate, and a test key was recovered by checking all candidates in about 11 milliseconds.

Foxit Reader 2026.1.3.36551 derives its key from the current timestamp and a buffer that is zero-filled in practice, making timestamp guesses sufficient. The known structure of the encrypted permissions block allows each guess to be checked without password hashing; a multithreaded search can cover timestamps back to 1970 in under five seconds on the tested machine. OpenPDF and iText also use weak randomness: an ARC4 stream seeded from the millisecond clock and available JVM memory generates both the key and visible salts, which help test guesses. The analysis traces Foxit’s derivation to old PDFium code and notes that similar code spread to other editors. Vendors were notified, MuPDF fixed its flaw, and decryptors for MuPDF and Foxit were released; already-created PDFs remain exposed.