5 ms·
Um, so you realize that the BEAST attack is pretty TLS (and heck, pretty implementation specific --- it only works against certain websockets implementation).
by tytso 13y ago
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.
- caf 13y agoBEAST 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).
- tptacek 13y agoHe 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.
- wbl 13y agoRogaway published though: was lack of attention the result of the NSA influencing industry to ignore academic work?
- tptacek 13y agoRogaway 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.
- anologwintermut 13y agoIs 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).
- tptacek 13y agoI don't believe it was broadly known to be wrong during IPSEC standardization.
- anologwintermut 13y agoIs that true for the LFSR proposal?I thought LFSRs were basically never thought to be cryptographically secure.