I'm the maintainer of pypdf, a Python library for reading/manipulating PDF documents. I recently discovered that pypdf used random instead of secrets for ...

  1. Generating the initialization vector (IV) in AES
  2. As part of generating the U-Value (PDF specs: "Password Algorithms", the "user password" )
  3. As part of generating the O-Value (PDF specs: "Password Algorithms", the "owner password" )
  4. As part of the data of AES_ECB_encrypt

The bug is fixed.

I'm now thinking about issuing a security notice, besides the entry in the changelog.

To clarify: this question is about (1). Hence the question: Would an attack on a document encrypted with an initialization vector generated via Pythons random module become feasible?

  • 1
    You would have trouble if you encrypted two different strings with the same key and the same IV. The IV don't even need to be random, it must be unique. Could even be a sequence.
    – ThoriumBR
    Mar 27, 2023 at 19:04
  • Nice! So it wasn't even theoretically an issue 🎉 If you make that an answer, I'd accept it (although I would appreciate a source for that) Mar 27, 2023 at 19:07
  • That would be the case for CTR, but not for CBC, which is used here. CBC requires an unpredictable IV.
    – bk2204
    Mar 27, 2023 at 19:09
  • CBC should not be used when possible, as it does not guarantee data integrity.
    – ThoriumBR
    Mar 27, 2023 at 21:07

2 Answers 2


In this case, you're using CBC, which requires an unpredictable IV, so this is a security vulnerability. To quote Wikipedia:

If an attacker knows the IV (or the previous block of ciphertext) before the next plaintext is specified, they can check their guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS CBC IV attack).

If your library is used to process multiple PDF files that may use the same key and an attacker can see the output of one before submitting more data to be encrypted, then they will be able to verify a guess for a previous plaintext. This may seem far-fetched, but I bet you there are in fact many tools which generate PDFs on demand like this.

In general, you can generally assume that it is never safe to use a non-cryptographic RNG for any aspect of a cryptographic operation. That's because for most non-cryptographic RNGs, the entire state can be predicted given enough output (this is never true for CSPRNGs) and thus an attacker can generally guess every output, past, present, and future.

I will also mention just for the record that RC4 (ARC4) is completely insecure and shouldn't be used, but I'm sure that this is for compatibility only.


You usually need two random primes a and b. There was a case where the software creating private keys used the same a and b for two keys leading to duplicated private keys, which is not a big problem.

Then someone figured out they someone used (a, b) for one key and (b, c) for another key. If you have two such keys they are very easily both cracked. If you have a billion public keys where some have a prime in common, that’s an interesting mathematical problem but all those keys can be cracked in reasonable time.

  • Are you talking about AES? Sounds more like RSA. The question is about AES Mar 28, 2023 at 8:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .