How to solve “Unknown encryption type R = 6” errors

In recent months we’ve noticed an increasing number of questions on our Jira Support board, Stack Overflow, and indeed all over the Internet, all asking pretty much the same thing: What does "Unknown encryption type R = 6" mean, and how do I fix it?

If you’ve Googled this error and landed here, then congratulations! You’ve come to the right place. We’ll tell you all about what this mysterious error message means, why you’re seeing it, and most importantly how you can resolve it.

What does “Unknown encryption type R = 6” mean?

First things first though, let’s unpack exactly what this message is telling you. You’ve passed an encrypted PDF file to iText, and it has thrown an exception because it has encountered a type of password encryption that it does not understand. In the case of “Unknown encryption type R = 6” this refers to 256-bit AES encryption.

If you’re using iText 5/iTextSharp, or something even older like iText 2, then you’re increasingly likely to come across this error. If you’ve never encountered this error when dealing with encrypted PDFs, then you should be aware they are not secure by today’s standards – as we will soon learn.

To resolve the issue, you’ll need to use newer versions of iText (7.1 and later) that do understand this encryption type. If you need to upgrade though, you should seriously consider going straight to iText 8, which has just been released and supports even more modern PDF features. Incidentally, all versions of iText since 2009 have the exact same dual licensing scheme – AGPL and commercial – so there’s really nothing stopping you using the latest and greatest!

Why don’t older versions work though, and what types of PDF will cause the error? To answer that, first we’ll need to talk about how the PDF specification has evolved since its introduction.

A brief history of the PDF specification

Unsurprisingly for a file format that is now almost 30(!) years old, the PDF specification has gone through many revisions to add new features. Adobe released version 1.0 on June 15^th 1993, which at the time only supported text, images, pages, hypertext links, bookmarks, and thumbnail sketches.

Version 1.1 followed in 1994, and introduced device-independent color, threads and links, and binary format for smaller files. Perhaps most importantly though, documents could now be protected via passwords and encryption, with Adobe introducing the concepts of encryption dictionaries and security handlers.

What is an encryption dictionary?

A PDF file is constructed from basic data structures known as objects. The PDF syntax currently consists of nine basic types of objects: boolean values, integers, real numbers, strings, names, arrays, dictionaries, streams, and the null object.

Dictionary objects are associative tables which contains pairs of objects. The first is a name object which serves as the key, and the second object serves as the value. This may be any kind of object, including another dictionary.

The PDF 1.1 specification defines an encryption dictionary as the following:

“Every protected document must have an Encrypt dictionary, which specifies the security handler to be used to authorize access to the document. The Encrypt dictionary also contains whatever additional information the security handler chooses to store in it.”

What is a security handler?

In the same version of the specification, a security handler is defined thus:

“Security handlers authorize users to access the content of PDF files. They may use whatever data they choose to do so, such as passwords, the presence of a specific hardware key, or the output of a fingerprint scanner.”

Acrobat 2.0 and compatible PDF viewers included one built-in security handler known as Standard, though there is provision for additional handlers to be supported by plug-ins. The built-in security handler supported two passwords (owner and user) obtained via a password dialog box, and also supported the restriction of permissions for users, set by the owner.

“In addition to granting access to the contents of the file, a security handler may grant permission to perform specific operations on the file.”

In Acrobat 2.0, the permissions available were printing the document, copying text and graphics to the clipboard, modifying the document, and adding or modifying notes in the document.

Table 6.47 from the PDF 1.1 specification describes the information in the Encrypt dictionary used by the standard security handler. This defines the requirements for the owner and user passwords, and when permissions should be granted when opening a password-protected file. In addition though, it includes the following definition:

Spoiler alert: this will be important later… 😉

At that time the only encryption algorithm allowed by the encryption dictionary contained in PDF files was RC4 40-bit. It should go without saying, but don’t use RC4 for anything these days. It is horribly insecure, even with much larger key lengths.

Version 1.2 followed in 1996 and introduced things like fill-in forms and interactive page elements, while 1.3 was released in 2000 with a wealth of new features like digital signatures, JavaScript actions, embedded file streams, and much more. Coincidentally, 2000 was also the year the very first public version of the iText PDF library was released; 0.3.0 on 14^th February.❤️

The release of PDF 1.4 in 2001 added a number of cool things like enhancements to interactive forms and the Forms Data Format (FDF), XML form submissions, and also introduced tagged PDF and other accessibility features which eventually resulted in the development of the PDF/A and PDF/UA standards for archiving and universal accessibility. For document security though, a big change was the support for RC4 encryption key lengths greater than 40-bits, with up to 128-bits being supported.

2003 saw the release of version 1.5 of the PDF specification. 1.5 brought enhancements to embedding and playback of multimedia, plus XFDF for interactive form submissions (replacing 1.4’s use of XML). As for document password encryption, we were still stuck with RC4 128-bit, though the security handler could now use its own encryption and decryption algorithms.

The release of PDF 1.6 in 2004 introduced support for a new type of password encryption algorithm: the Advanced Encryption Standard (AES) with a maximum key length of 128-bits.

PDF 1.7 in 2006 was the first release of the PDF standard to be published by the International Organization for Standardization (ISO), with all future versions being produced by ISO technical committees. However, Adobe continued to publish their own extension levels to PDF 1.7 which specified proprietary features supported by their newly released products.

These extensions were published between 2008 and 2011, and included a number of proprietary extended features. Of specific interest for this article though was the introduction of 256-bit AES encryption in Extension Level 3; though 2011’s Extension Level 8 revised the password handling to address a weakness in the algorithm that had been discovered.

PDF 2.0 enters the ring

While the first PDF specification published by the ISO Technical Committee was ISO 32000-1:2008, this was simply the ISO-approved version of PDF 1.7 and thus included all the functionality previously documented in the Adobe PDF Specifications for versions 1.0 through 1.7. Therefore, it would not include any of the subsequent proprietary Adobe extension levels mentioned above.

A new ISO PDF standard was published in July 2017. ISO 32000-2, or as it is more commonly known, PDF 2.0. The ISO committee developing PDF 2.0 had multiple goals in addition to adding new features. These included the standardization of the Adobe proprietary specifications that were still relevant, while also deprecating features that were no longer used. In addition, they updated and clarified the documentation to resolve ambiguities, and established tighter rules for the specification’s future development.

As a member of the ISO committee, iText was closely involved in the development of PDF 2.0. At the time, we had only recently completed a comprehensive rewrite of the wildly successful iText 5 library, with iText version 7.0 being released in May 2016 for Java and .NET (C#).

In addition to making iText 7 a more streamlined and modular library, one of the main aims for rewriting the iText library was to more easily support the new features of PDF 2.0, and subsequent revisions of the specification. While some features of PDF 2.0 (such as PAdES digital signatures) were already supported in initial releases, full support of the PDF 2.0 specification would come in iText 7.1, released in December of 2017.

PDF 2.0 brought numerous improvements and new features, such as in tagged PDF, associated files, and digital signatures, although one particular change is pertinent for this article. As of PDF 2.0, 256-bit AES encryption was now the standard for password-protected PDFs, with both the RC4 and AES-128 algorithms being deprecated.

If we look at the equivalent table for the standard security handler from the PDF 2.0 specification, we can see many differences and additions to the definition for the R key from the original 1.2 spec we saw earlier. The following is not a direct copy from the specification, since we have removed some information relating to access permissions which are out of scope for this article.

As stated, an encryption dictionary must contain a number specifying which version of the standard security handler should be used to interpret this dictionary. This number is read when the document is opened by a PDF processor - whether this is a PDF reader like Acrobat, or a PDF library like iText. In addition, the revision number also denotes the V value, which tells the PDF processor exactly what type of encryption has been used.

We can see that all R values below 5 are deprecated in the PDF 2.0 specification, and also that the only valid encryption (V) value for revision 6 of the standard security is 5, which represents the 256-bit AES encryption now required by PDF 2.0 compliant PDFs.

This can be verified by referring to Table 20 which defines the integer values that represent the types of encryption. Again, some information has been omitted from the following extract:

So, with all that we can deduce that the “Unknown encryption type R = 6” error is caused by an older version of iText attempting to read or process a PDF protected by the AES algorithm with an encryption key length of 256 bits. The PdfReader class in iText 5/iTextSharp and previous versions reads the R value stored in the encryption dictionary, and compares it to a prior PDF version's specification. Which, since it does not include the value of 6, causes the “Unknown encryption type R = 6” exception to be thrown.

This is a strong indication, although not a confirmation, that the document in question is PDF 2.0 compliant. If you were paying attention earlier, you may have noticed that initial support for 256-bit AES encryption was added to PDF 1.7 Extension Level 3 all the way back in 2008. Indeed, Adobe Acrobat has supported this encryption type since Acrobat X back in 2010.

Of course, since iText 7.1 and later fully support the PDF 2.0 specification, the PdfReader class (Java/.NET) in these versions does not result in an exception, since it reads the R value and is aware of the correct encryption (V) value to use for these documents.

A word about standards

It takes time for a standard to become the standard. The PDF 2.0 specification was published in 2017, and many PDF vendors (including ourselves) quickly added support for it. Seeing PDF 2.0 compliant documents in the wild is still relatively rare, though is becoming more common as features like its more secure encryption become desirable to businesses.

Incidentally, one of our favorite PDF 2.0 features is portable collections or PDF portfolios. This was introduced in PDF 1.7 and extended in PDF 2.0 by adopting the concept of “associated files” introduced in the PDF/A-3 archiving subset of the ISO PDF standard. Portable collections enable the integration of many different file types into a single PDF "container" which can be easily secured using a password, or even a digital signature. If you’ve ever sent anyone a PDF containing poorly scanned or converted images, spreadsheets, or slide decks, then you might want to use this feature instead of simply combining files into a PDF.

Time moves on though, and standards evolve along with technology. In 2020, the second edition of PDF 2.0 was published containing significant corrections and clarifications to the specification. More importantly though, two ISO-approved PDF 2.0 cryptographic related extensions were published in 2022, with two more being finalized for expected publication in 2023.

As iText is now part of the Apryse family, we were recently pleased to see a unique collaboration between the PDF Association and the three leading PDF companies, including Apryse. The ISO PDF 2.0 specification is now available to download for no charge for PDF software developers to more easily leverage the newest PDF 2.0 features, including these latest cryptographic extensions.

What was that about iText 8?

Following the release of iText 7 in 2016, iText 5/iTextSharp became deprecated and is now considered EOL. While there have been maintenance releases to address security issues, iText 5 does not support PDF 2.0 and its encryption standards, and no new features have been added. Instead, our main focus has been on the continued development of iText 7 and the add-ons that make up the iText Suite SDK.

Seven years after the first iText 7 release though, iText 8 brings a whole host of improvements and changes to support newer PDF features and standards and will provide a stable and extensible platform to continue iText development.

Just as with iText 7, the rationale behind iText 8 is to build upon iText’s reputation as the best and most performant PDF library. We want to make it even easier to create and manipulate PDF documents, particularly when it comes to templating and high-volume document generation. Just as important though, is our desire to allow open source developers to benefit from the latest PDF standards and features.  

Since we are closely involved with both the PDF Association and the ISO committees which publish these extensions, we believe it is crucial for open source projects (such as iText) to adopt and popularize such standards early. If development happens in public view, it’s more likely to drive further adoption across the industry.

Therefore, if you’re concerned about taking advantage of the latest security-related features in PDF, we highly recommend taking a look at what we have announced in this initial release of iText Core version 8. Especially relevant to this article is the support for SHA-3 hash functions as specified in ISO/TS 32001, and from ISO/TS 32002 modern elliptical curves for digital signatures will also be supported. Keep your eyes peeled for some upcoming blogs from the current chair of the PDF Association’s Digital Signatures Technical Working Group, Matthias Valvekens, which will dive deeper into these extensions.

In addition, by supporting the Java and .NET Bouncy Castle FIPS APIs directly in iText Core, it will be compliant with the Federal Information Processing Standard (FIPS 140-2) for validating the effectiveness of cryptographic hardware! More information on the FIPS 140-2 standard can be found in this FAQ on the Entrust website, or see the Bouncy Castle changes page on our Knowledge Base for more details on using our FIPS implementation. In addition, we have code examples for using FIPS in approved mode with the SHA3-512 algorithm.

Just as we do for all our releases, we made development snapshots available for developers on our Artifactory prior to the release date, so people could get up to speed with the new features and API differences. You can also check out our Java and .NET repos on GitHub to see the contributions from our wonderful community which made it into this release!

Conclusion

This concludes our look into this unknown encryption type error specific to AES-256 encrypted PDF documents. Armed with this knowledge and the now freely-available ISO PDF specification, you can also decode other PDF encryption errors you may encounter.

Whether you found this article via traditional search engines, or perhaps some ChatGPT-like method, we hope you found it useful and informative.

Happy coding!