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.
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.
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.
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.