3 ms·

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

by jcr 14y ago

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-information-leak-hijack-https-sessions-090512 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.

tptacek 14y ago
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.
- jcr 14y ago
  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.
  - marshray 14y ago
    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.
    - daeken 14y ago
      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.
anologwintermut 14y ago
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.

by jcr 14y ago

tptacek 14y ago

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.

jcr 14y ago
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.
- marshray 14y ago
  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.
  - daeken 14y ago
    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.

anologwintermut 14y ago

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.