That assumption was not taken for granted back in the 90's. It was only with years of cryptanalysis of AES (which had had resistance to known plaintext an explicit design goal) that designers felt comfortable with things like CTR mode.
In practice, we've learned that the block ciphers are by far the strongest part of the system, and it's the block cipher modes that provide the weakness for attackers.
IMHO this is the type of poisoned knowledge that the US spies should be blamed for.
We should be paranoid, but mostly that we might be not worrying about the right things.
1. There's this proof that a trapdoored symmetric cipher is equivalent to a public key system (there's a link in the metzdowd thread somewhere). No one seems to have figured out how to build a public key system with anything close to the efficiency of AES.
2. The specification of AES itself isn't that large. It's not minimal, but neither does it seem to have large arbitrary-looking constants. https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number
The NIST Dual-EC DRBG fails on both counts: 1. it is based on an obvious public key system, and 2. it recommends the use of large arbitrary constants that could easily be a trapdoor.
Now is it possible that NSA occasionally intentionally fails to backdoor a NIST standard in order to help us underestimate how often they succeed? Can we ever develop a coherent threat model with the possibility of this kind of adversary?
But really we need to ask some the folks older than I am. It would be a good question for the randombit or metzdowd crypography lists. Also, I'll tweet at Bellovin.
Edit: https://twitter.com/marshray/status/376600321637638144
Also, remember in the early 90's, when IPSEC was still going through its indeterminable standardization process, this was pre-AES, and most of us were still using DES (or if we could afford the CPU --- CPU's were much slower back then) 3DES. Heck, some of this work was going on before Javascript was even invented! :-)
BTW, I was wrong, the comments about not using a counter did make it into an RFC. See RFC 2405, which does state that using a counter or some other low-hamming distance is preferred.
Note that there are dangers with using a random IV --- if you do this, the RNG used to generate your IV's had better be independent of the RNG used to generate your session keys, or else you might potentially leak information about your RNG state that might be yet another wedge into attacking the crypto. (In particular, I would NOT recommend using RDRAND in bare fashion --- see comments on my G+ post #ThinkLikeTheNSA --- about what fun and games you might have if you could compromise the RDRAND instructuction.)
If you really want to be paranoid, generate a separate key (different from the key used for encryption and for generation of the MAC) and use that key as the basis of a Cyptographic RNG, and then use the output of that CRNG for your IV.
In the context of network stacks rather than browsers, inducing the target to encrypt chosen plaintext is often possible - ICMP ECHO, for example. Of course it seems rather difficult to arrange for your chosen plaintext to be right at the start of an IPSEC packet, since there will usually be a TCP or UDP header - but perhaps it is possible (and even if it isn't, that looks like rather flimsy protection).
Either way, IPSEC was formulated in the dark ages of crypto. Almost nobody (except Phil Rogaway) knew this stuff about CBC back when the standard was being drafted.
LFSRs are also sometimes used in counter mode, too.
Again: obviously, a simple LFSR isn't cryptographically secure, and anyone who would deploy one in a cryptosystem probably already knows that. The question is: how are you mounting the attack you're talking about?
Lots of smart people have involved themselves with IETF, but those among them that I have talked to about it seem universally and profoundly frustrated by the whole process.
I don't think BEAST was a product of Bard. If we read Bard's papers then we probably never came up with BEAST [1]. Bard wanted to apply Rogaway-Dai's attack to SSL, but he didn't understand how browsers worked. His papers didn't target cookies - in fact he didn't even mention that word - but he wanted to decrypt short PIN sent in POST requests, which is impossible as far as I can tell. The reason we cited Bard was because his English is much better than us, so we'd thought that we could re-use his explanation of Rogaway-Dai's attack in the context of SSL. In other words, we both attempted to exploit the same vulnerability, but we used different approaches and targeted different secrets.
Another way to look at this: imagine if one reads Bard's do you think if he or she could use any of Bard's ideas to invent new BEASTies attacks, e.g., CRIME, Lucky 13, the RC4 attack, <your attack here>?
But here, we're talking about IPSEC, not HTTPS/TLS, and the fundamental cryptographic design weakness we're talking about is, I think, Bard's. I could be wrong, though.
No, it wasn't Bard's. It's Rogaway and Dei's.