Comment by tytso | Hacker News Reader

Comment by tytso | Hacker News Reader

Parent Full thread

Um, so you realize that the BEAST attack is pretty TLS (and heck, pretty implementation specific --- it only works against certain websockets implementation). That's because it is a chosen-plaintext attack, so it is dependent on TLS being used to encrypt Javascript, where the Javascript libraries are hosted on a server under the attacker's control.

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.

BEAST does not require encrypting of Javascript. It uses Javascript, which can just as well be delivered unencrypted, to induce the browser to make separate requests to the HTTPS site, which include the chosen plaintext.

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

He is right about how specific the circumstances are that give rise to Bard's CBC IV attack. Not only that, but BEAST itself was the product of a former NSA cryptologist, now a Wisconsin university math professor; it is vanishingly unlikely that it was common knowledge inside of NSA, since the guy PUBLISHED it just a year or two after leaving the agency.

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.

> He is right about how specific the circumstances are that give rise to Bard's CBC IV attack. Not only that, but BEAST itself was the product of a former NSA cryptologist, now a Wisconsin university math professor; it is vanishingly unlikely that it was common knowledge inside of NSA, since the guy PUBLISHED it just a year or two after leaving the agency.

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

I think it's fair to say that BEAST introduced and established the modern CPA browser attack methodology, and that (for instance) Lucky 13 depended on it.

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.

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

Rogaway published though: was lack of attention the result of the NSA influencing industry to ignore academic work?

Rogaway didn't publish academically. He commented on the mailing list, and a bunch of standards group denizens pooped all over him. The same thing happened to Dan Bernstein on namedroppers. Is Perry Metzger an NSA agent? I have reason to doubt it.

http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse... If you could provide some more information on responses, perhaps emails dismissing it, I think we can figure out what went wrong.

What went wrong with IPSEC was that a bunch of standards group people set out to build a crypto standard that would impact every networking vendor on the planet, and did so with frank and open hostility towards academic cryptographers. The idea that NSA would have tried to subvert IETF implies that IETF was organized enough to subvert. But it wasn't and isn't. IETF is like the Internet's student council.

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.

Could this hostility be the result of the NSA subversion? It seems as though the same few hardware vendors keep popping up as the people slowing down security fixes.

No, I don't think so.

Is the argument whether using either of the proposed IV generation modes is wrong or if it was do to NSA tampering? It certainly is wrong to do so (and should have been known to be wrong by the time of Rogaway's comment).

I don't believe it was broadly known to be wrong during IPSEC standardization.

Is that true for the LFSR proposal?I thought LFSRs were basically never thought to be cryptographically secure.

I don't know the specific proposal, but I know how CBC designs with LFSR-generated IVs work, and why you'd want a deterministic generator for your IVs, and it's because it allows both sides to agree on a non-repeating progression of IVs without actually sending the extra block on every message.

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?

Do you know of protocols that use LFSRs for IV generations of cryptographic purposes? Can you link to them ? I'd like to see if they are breakable.

I've got nothing I can cite to you; it's also true that a lot of bespoke crypto enjoys a lack of usable attacker chosen plaintext, which is admittedly not a good property to rely on for a standard.

Reply on news.ycombinator.com