I'm not sure what the point you're making here is. Matthew is very deliberately talking about formal proofs of the protocol; Juliano and Thai are talking about implementation flaws.
It was the "provable security" phrase that just seemed out of place
in light of recent (but still undisclosed) events. But at least I did
differentiate between the flaws in the implementation and flaws in
the underlying crypto... or at least I tried.
The thing to remember is that "proven secure" doesn't mean that any real existing protocol specifications or implementations are actually secure! It means that some cryptographers used some (huge) set of simplifications and assumptions to define a model in which some aspect of the protocol has been proven to resist specific known attacks. Crypto papers assume their audience knows exactly what these assumptions are by reference to one of the standard proof models.
I think Matthew is doing something really good here by trying to bridge the gap between the proofs and the messy reality.
Good example: one-time pads are proven secure, but if I write an application that swaps OTPs before beginning encrypted communication with those pads, bad things will happen.
On the contrary, it seems to be fairly decent timing. Since it draws attention to the issue of formal security in TLS. The formal proofs he refers to have caveats either 1) they use actually secure asymmetric crypto whereas TLS does not or 2) assume both that all parts work correctly in tandem and have some strange assumptions.
The fact that someone has vulnerability only goes to show you that we probably need to do more work both with the proofs and changing TLS so its easier to proof. This is possibly the third time that an ignored, "academic crypto issue' has broken TLS. This is of course assuming that they have a protocol flaw and not an implementation one.
Comments
Matthew Green has remarkably bad timing... The crypto might be provable, but the implementation is another story:
https://threatpost.com/en_us/blogs/new-attack-uses-ssltls-in...
And no, I've found no other details about the new attack, but if anyone knows anything, particularly mitigation methods, please post them.
I'm not sure what the point you're making here is. Matthew is very deliberately talking about formal proofs of the protocol; Juliano and Thai are talking about implementation flaws.
It was the "provable security" phrase that just seemed out of place in light of recent (but still undisclosed) events. But at least I did differentiate between the flaws in the implementation and flaws in the underlying crypto... or at least I tried.
The thing to remember is that "proven secure" doesn't mean that any real existing protocol specifications or implementations are actually secure! It means that some cryptographers used some (huge) set of simplifications and assumptions to define a model in which some aspect of the protocol has been proven to resist specific known attacks. Crypto papers assume their audience knows exactly what these assumptions are by reference to one of the standard proof models.
I think Matthew is doing something really good here by trying to bridge the gap between the proofs and the messy reality.
Good example: one-time pads are proven secure, but if I write an application that swaps OTPs before beginning encrypted communication with those pads, bad things will happen.
On the contrary, it seems to be fairly decent timing. Since it draws attention to the issue of formal security in TLS. The formal proofs he refers to have caveats either 1) they use actually secure asymmetric crypto whereas TLS does not or 2) assume both that all parts work correctly in tandem and have some strange assumptions.
The fact that someone has vulnerability only goes to show you that we probably need to do more work both with the proofs and changing TLS so its easier to proof. This is possibly the third time that an ignored, "academic crypto issue' has broken TLS. This is of course assuming that they have a protocol flaw and not an implementation one.
Matthew talks about a lot of the same concerns I have with SSL/TLS here, far more eloquently than I ever have.
The link is slightly wrong: it's missing the l at the end.
clicky http://blog.cryptographyengineering.com/2012/09/on-provable-...
Oops. That's what I get for submitting a link here five minutes before walking out the door...
working link http://blog.cryptographyengineering.com/2012/09/on-provable-...
The link is dead. Bummer, I'd like to read that article.