Is using weak random numbers for the initialization vector of AES just a theoretical issue?

Question

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?

Answer 1

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.

Answer 2

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.