Weak Cryptography — QPDF 11.9.1 documentation (2024)

Definition of Weak Cryptographic Algorithm

We divide weak cryptographic algorithms into two categories: weakencryption and weak hashing. Encryption is encoding data such that akey of some sort is required to decode it. Hashing is creating a shortvalue from data in such a way that it is extremely improbable to findtwo documents with the same hash (known has a hash collision) andextremely difficult to intentionally create a document with a specifichash or two documents with the same hash.

When we say that an encryption algorithm is weak, we either mean thata mathematical flaw has been discovered that makes it inherentlyinsecure or that it is sufficiently simple that modern computertechnology makes it possible to use “brute force” to crack. Forexample, when 40-bit keys were originally introduced, it wasn’tpractical to consider trying all possible keys, but today such a thingis possible.

When we say that a hashing algorithm is weak, we mean that, eitherbecause of mathematical flaw or insufficient complexity, it iscomputationally feasible to intentionally construct a hash collision.

While weak encryption should always be avoided, there are cases inwhich it is safe to use a weak hashing algorithm when security is nota factor. For example, a weak hashing algorithm should not be used asthe only mechanism to test whether a file has been tampered with. Inother words, you can’t use a weak hash as a digital signature. Thereis no harm, however, in using a weak hash as a way to sort or indexdocuments as long as hash collisions are tolerated. It is also commonto use weak hashes as checksums, which are often used a check that afile wasn’t damaged in transit or storage, though for true integrity,a strong hash would be better.

Note that qpdf must always retain support for weak cryptographicalgorithms since this is required for reading older PDF files that useit. Additionally, qpdf will always retain the ability to create filesusing weak cryptographic algorithms since, as a development tool, qpdfexplicitly supports creating older or deprecated types of PDF filessince these are sometimes needed to test or work with older versions ofsoftware. Even if other cryptography libraries drop support for RC4 orMD5, qpdf can always fall back to its internal implementations of thosealgorithms, so they are not going to disappear from qpdf.

Uses of Weak Encryption in qpdf

When PDF files are encrypted using 40-bit encryption or 128-bitencryption without AES, then the weak RC4 algorithm is used. You canavoid using weak encryption in qpdf by always using 256-bitencryption. Unless you are trying to create files that need to beopened with PDF readers from before about 2010 (by which time mostreaders had added support for the stronger encryption algorithms) orare creating insecure files explicitly for testing or some similarpurpose, there is no reason to use anything other than 256-bitencryption.

By default, qpdf refuses to write a file that uses weak encryption.You can explicitly allow this by specifying the--allow-weak-crypto option.

In qpdf 11, all library methods that could potentially cause files tobe written with weak encryption were deprecated, and methods to enableweak encryption were either given explicit names indicating this ortake required arguments to enable the insecure behavior.

There is one exception: when encryption parameters are copied from theinput file or another file to the output file, there is no prohibitionor even warning against using insecure encryption. The reason is thatmany qpdf operations simply preserve whatever encryption is there, andrequiring confirmation to preserve insecure encryption would causeqpdf to break when non-encryption-related operations were performed onfiles that happened to be encrypted. Failing or generating warnings inthis case would likely have the effect of making people use the--allow-weak-crypto option blindly, which would be worsethan just letting those files go so that explicit, conscious selectionof weak crypto would be more likely to be noticed. Why, you might ask,does this apply to --copy-encryption as well as to thedefault behavior preserving encryption? The answer is that--copy-encryption works with an unencrypted file as input,which enables workflows where one may start with a file, decrypt itjust in case, perform a series of operations, and then reapply theoriginal encryption, if any. Also, one may have a template used forencryption that one may apply to a variety of output files, and itwould be annoying to be warned about it for every output file.

Uses of Weak Hashing In QPDF

The PDF specification makes use the weak MD5 hashing algorithm inseveral places. While it is used in the encryption algorithms,breaking MD5 would not be adequate to crack an encrypted file when256-bit encryption is in use, so using 256-bit encryption is adequatefor avoiding the use of MD5 for anything security-sensitive.

MD5 is used in the following non-security-sensitive ways:

• Generation of the document ID. The document ID is an input parameterto the document encryption but is not itself considered to besecure. They are supposed to be unique, but they are nottamper-resistent in non-encrypted PDF files, and hash collisionsmust be tolerated.

  The PDF specification recommends but does not require the use of MD5in generation of document IDs. Usually there is also a randomcomponent to document ID generation. There is a qpdf-specificfeature of generating a deterministic ID (see--deterministic-id) which also uses MD5. While it wouldcertainly be possible to change the deterministic ID algorithm tonot use MD5, doing so would break all previous deterministic IDs(which would render the feature useless for many cases) and wouldoffer very little benefit since even a securely generated documentID is not itself a security-sensitive value.

• Checksums in embedded file streams – the PDF specificationspecifies the use of MD5.

It is therefore not possible completely avoid the use of MD5 withqpdf, but as long as you are using 256-bit encryption, it is not usedin a security-sensitive fashion.

API-Breaking Changes in qpdf 11.0

In qpdf 11, several deprecated functions and methods were removed.These methods provided an incomplete API. Alternatives were added inqpdf 8.4.0. The removed functions are

• C API: qpdf_set_r3_encryption_parameters,qpdf_set_r4_encryption_parameters,qpdf_set_r5_encryption_parameters,qpdf_set_r6_encryption_parameters

• QPDFWriter: overloaded versions of these methods with fewerarguments: setR3EncryptionParameters,setR4EncryptionParameters, setR5EncryptionParameters, andsetR6EncryptionParameters

Additionally, remaining functions/methods had their names changed tosignal that they are insecure and to force developers to make adecision. If you intentionally want to continue to use insecurecryptographic algorithms and create insecure files, you can changeyour code just add _insecure or Insecure to the end of thefunction as needed. (Note the disappearance of 2 in some of the Cfunctions as well.) Better, you should migrate your code to use moresecure encryption as documented in QPDFWriter.hh. Use theR6 methods (or their corresponding C functions) to create fileswith 256-bit encryption.