9-Bit AES Keys: The Randomness Crisis Behind PDF Encryption

What Happened

When PDF documents are encrypted, the user password does not directly encrypt the file content. The process is divided into two steps: first, the software generates a 32-byte file key randomly and encrypts the text with AES; then, it encrypts and saves this file key using the key derived from the user password. When opening the document, the user must first calculate the derived key from the password, decrypt the file key, and then use the file key to decrypt the text. This design itself is fine and is a common practice in many document encryption software. The problem is that the quality of the file key is the foundation of the entire encryption chain. If the file key can be easily guessed, even the powerful AES-256 algorithm will be ineffective.

Rick de Jager, a researcher at V12, discovered during audits that there were serious issues with file key generation in at least four common PDF implementations. The problem wasn’t that the algorithm names weren’t catchy enough, but that the random sources used to generate the keys did not meet the basic requirements of cryptographic security.

Let’s look at older versions of MuPDF (<1.28.5>). It uses the drand48 linear congruential generator, with a seed based on Unix timestamps in seconds, and only takes bytes from bits 17-24 of the state. The first 16 bits of the state are fixed at 0x330e, so only 9 timestamp bits actually affect the output. Different timestamps within 512 seconds can produce exactly the same key stream. With an unoptimized Python brute-force script, it takes about 11 milliseconds to try all 512 possibilities. Once an attacker obtains the document, they can quickly enumerate the correct file key. More concerning is that MuPDF’s /ID field also uses the same LCG for generation and is stored in plaintext, providing an additional checkpoint to further narrow down the search space.

Next, consider Foxit PDF Reader 2026.1.3.36551. The file key is derived from a hash of “current timestamp + 32 uninitialized bytes + constants.” The so-called uninitialized bytes are actually zero-fillers, meaning there is no randomness. V12’s Rust implementation shows that on a 32-thread Ryzen 9 7950X, it can test 370-376 million timestamps per second. A document took about 0.84 seconds to crack 10 years ago, and searching from the Unix epoch only takes about 4.85 seconds. Foxit’s /Perms block contains known plaintext; verification only requires one hash and one AES block decryption, further reducing attack costs.

OpenPDF 3.0.5 and iText 9.7.1 present another issue. They replace the content that should be provided by a secure cryptographic random number generator with an ARC4 stream through IVGenerator. The ARC4 seed consists of millisecond-level timestamps and JVM idle memory, while the 32-byte salt stored in /U and /O is also in plaintext and can be used to reverse-engineer the timestamps and memory values. This means that attackers don’t need to exhaust the entire key space; they only need to restore the seed based on information exposed in the document.

V12 also noted that the problematic code pattern in Foxit can be traced back to the first public submission of PDFium in May 2014, and since the PDFium file header credits Foxit, it suggests that this pattern may have originated from Foxit and has existed for over a decade. In other words, this vulnerability was not introduced recently but is a historical issue long existing in the PDF ecosystem. More concerning is that these implementations are relied upon by numerous downstream projects and commercial products, and a flaw in a underlying module could spread to broader scenarios through code reuse.

Manufacturers and Fixes

The issue has been disclosed to relevant manufacturers. The current progress is as follows:

• MuPDF has been fixed, affecting versions prior to 1.28.5.
• The fixing status for Foxit, OpenPDF, and iText should be confirmed by their respective official announcements.
• V12 has released decoders for MuPDF and Foxit, proving that the vulnerability can be actually exploited.

It is important to note that encrypted PDF files that have already been generated cannot be retroactively protected. Even if the software is fixed today, files generated with these versions may still be vulnerable. This differs from common vulnerability patches: patches only prevent new files from being affected, while old files can only be remedied by re-encrypting or converting them with reliable tools.

This also involves a question of responsibility. The PDF encryption standard itself does not mandate that cryptographic secure random numbers must be used, nor does it specify what level of entropy the random number generator must achieve. The standard only defines the algorithm framework, and manufacturers decide on the implementation details. As a result, the quality of implementations varies among manufacturers, and users find it difficult to distinguish security differences from interface or function names. If the documentation states “AES-256,” ordinary users usually assume it is secure enough. This information asymmetry creates a huge gap between “encryption” in marketing terms and its actual effectiveness.

Another point worth noting is that such issues are often not detected by traditional vulnerability scanning tools. Because the code does call AES-256 and stores the key in standard format, it’s just that the random source itself is insecure. Static analysis and black-box testing struggle to identify semantic flaws like “insufficient key entropy,” which require specialized security audits to expose.

From another perspective, this disclosure also exposes the risks associated with code reuse. There are many shared implementations and reference codes in the PDF ecosystem, and if a basic module handles random numbers poorly, subsequent tools built on it may carry the same issue. For companies that rely on PDF encryption to protect sensitive information, this means they cannot simply trust well-known manufacturers or mature projects; they must actively verify whether the implementation meets modern cryptography standards.

What the Comments Say

A highly praised comment on Hacker News came from tptacek, who pointed out that the real problem is not “the key being only 9 bits,” but that the key is not a cryptographic random number at all. This distinction is important: AES-256 itself has not been cracked; what has been cracked is the random source for generating the key. Describing the problem as “9-bit AES key” is a colloquial term, but it can lead readers to misunderstand that there is an error in the AES algorithm. The algorithm name provides a theoretical upper limit, while the implementation details determine the actual lower limit.

Other discussions focus on the historical burdens of the PDF encryption ecosystem. Many believe that the PDF standard makes encryption seem complex, yet it has long not mandated the use of cryptographically secure random numbers, leading to recurring vulnerabilities in various implementations. The PDF encryption specification was born out of document protection needs, not modern threat models, thus leaving many gray areas.

Others remind that ordinary users assume a file is secure just because it claims to support AES-256. However, any error in the implementation of random number generation, key derivation, or salt processing can render high-security algorithms ineffective. Some comments point out that disclosing such vulnerabilities is meant to force organizations relying on PDF encryption to reevaluate their assumptions, rather than simply blaming a specific vendor. Even more developers state that many projects only care about whether a feature exists when choosing an encryption method, without considering whether the implementation has been audited. This mindset itself is the root of the problem.

Some comments also address the practical difficulties of fixing these issues. Since PDF files cannot be retroactively encrypted once generated, companies must re-encrypt large amounts of historical documents, which adds extra burden to storage and processes. Therefore, some believe that the impact of this incident will not disappear immediately but will last for months or even longer. Others suggest that future revisions of the PDF specification should mandate the use of cryptographically secure random numbers; otherwise, similar problems will continue to occur.

Three things ordinary users can do

1. Do not rely solely on the “AES-256” label. Encryption security depends on multiple factors, such as key generation, key derivation, and random number sources. If a tool only emphasizes the algorithm name while being vague about implementation details, be cautious. For truly sensitive content, consider adding an independent layer of encryption beyond PDF encryption, such as using audited file encryption tools. This way, even if there are implementation flaws in PDF encryption, the document content will not be directly exposed.
2. Check whether you are using sensitive PDFs generated with the disclosed version. If so, it is recommended to re-encrypt them with a fixedified version or switch to another audited encryption method, rather than relying on the old PDF password protection. It is important to note that modifying document properties or re-saving does not equal fixing; you must regenerate the file key and re-encrypt the text. For companies, this step should be combined with document version management and backup strategies to avoid content loss or权限 loss during re-encryption.
3. For companies, include PDF encryption in security baseline reviews. Focus on the source of random numbers, key derivation functions, and salt processing methods, not just whether “AES-256” is checked. Also establish a document lifecycle management system to mark which files were generated with known problematic versions, and prioritize re-encrypting or migrating these files. Additionally, security teams can regularly monitor the security announcements of PDF processing tools and assess the impact as soon as they are disclosed.

Conclusion

“The 9-bit AES key” incident once again demonstrates that the security of cryptographic products is not determined by the name of the algorithm, but by the implementation details. AES-256 can provide a high theoretical security boundary, but if a 32-byte key actually comes from a random source with only 9 bits of entropy, its true strength is only 9 bits. Even more problematic is that PDF encryption standards do not mandate the use of secure random numbers, which leads to this issue recurring in different implementations. For ordinary users, the most practical action is not to crack others’ files, but to check whether they are still using old versions with security issues to generate sensitive documents and promptly migrate to more reliable encryption methods. Tech trends will pass, but document security will not repair itself automatically. A truly responsible approach is to take this revelation as an opportunity to review the security status of digital assets. For organizations that rely on PDF encryption to protect core materials, this incident serves as a warning: no matter how strong the algorithm, it cannot save the laziness in using random numbers. Only by evaluating cryptographic products based on “implementation” rather than “name” can we prevent similar risks from occurring again.

Reference Sources

• V12 Security Company blog: The case of the 9-bit AES key (2026-10-27)
• Hacker News discussion, objectID 50280722 (2026-10-28)