| > That section is talking about using an incrementing counter as the IV--it doesn't say anything about a PRNG being a bad choice (in this case, the PRNG being a SHA256). Let's try this again. You have two types of inputs that APIs refer to as "IVs". Nonces: Must never repeat. Initialization vectors: Must never repeat AND must be unpredictable. Counters are acceptable for nonces. When an academic cryptographer says in a security proof that a counter doesn't suffice for the security of a scheme, what they're really saying is that you're in the latter category (must be unpredictable too) rather than the former (where predictable is okay as long as it never repeats). If it can be predictable, it can be a counter. If it can't be a counter, it must be unpredictable. The correct way to get an unpredictable IV is to use a CSPRNG. SHA256(some predictable low-entropy inputs) fails to meet the bar for unpredictability. > Are you talking about brute forcing the IV? The IV is not a secret to anyone--it's usually appended to the cipher text. IVs aren't secret, but given the security proof I linked, IVs cannot be predictable. They must be unpredictable. |