6 ms·
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 re
by caf 13y ago
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).
- 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.
- tptacek 13y agoI 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?
- anologwintermut 13y agoDo 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.
- tptacek 13y agoI'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.
- wbl 13y agohttp://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt 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.
- tptacek 13y agoWhat 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.
- cryptbe 13y ago> 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>?
- tptacek 13y agoI 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.
- cryptbe 13y ago> 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.