[matthewaveryusa]

The attack here is:

1) You encrypt two pieces of data within the same second in the same process (so probably using the library?)

2) or if you're using the command-line, the attack is you encrypt two pieces of data within the same second, and somehow wrap-around your pid within the second to get the same pid again.

That may be enough, or not enough -- but for those that claim that's not enough, one needs to recognize the cognitive dissonance with reusing the same password

A monotonically increasing integer as IV is perfectly fine, and this dude is a bit out of his depth thinking IVs need to be random.

[tptacek]

Monotonically increasing CBC IVs are in fact not fine; you have them confused with CTR nonces, which need single-use rather than unpredictability. See Bard for more details of the best-known attack on predictable IVs. If you're going to try to take someone down a peg, be right.

[matthewaveryusa]

They are if you don't have an oracle afaik

[tptacek]

I don't follow your response. If you're wondering whether it's OK to have predictable IVs, check:

* Rogaway's IPSEC chained CBC IV attack

* Bard's HTTPS predictable CBC IV attack

* Dai's attack on SSH

* Thai Duong and Juliano Rizzo's BEAST

... all of which are based on predictable IVs (usually: the last block of the previous message, which is taken as a synthetic IV in 1990s-era protocols). In short: no, CBC IVs must be unpredictable.

[matthewaveryusa]

If you reuse an IV on 2 files at rest, information that both files have the same prefix leaks. If you use a counter IV, or a random IV, you got nothing -- that's the only point I'm making ivs don't have to be random in the confines of the right context

[garypoc]

You should read about the attacks tptacek mentioned. If IVs are predictable, it's the same impact as if you reuse the same IV, you just have to compute (m' xor IV' xor IV) instead of just m' if IV' = IV Then in both cases you check if c' = c