5 ms·

This sounds like a brilliant solution to a difficult problem, but I fear it only solves a portion of the problem. It deals with the issue of stolen keys, but ho

by Arnor 13y ago

This sounds like a brilliant solution to a difficult problem, but I fear it only solves a portion of the problem. It deals with the issue of stolen keys, but how does it protect against cryptanalysis? If an organization were able to reveal the a key with a replicable process, couldn't it be simply repeated for each session key?

jstanley 13y ago
I think that is an intractable problem. It is impossible to design a system that is not vulnerable to flaws in its design. The idea is to design a system that doesn't have flaws.
gknoy 13y ago
I think your concerns are mitigated by the attack vectors. If cracking encryption with N bit length keys someday becomes trivial, it doesn't matter what keys we used in the past: You're right. My meager understanding is that we don't expect this to be the case anytime soon, and worries about moore's law or asics for cracking keys can be mitigated by increasing key size until it's infeasible to brute force. If your main SSL key is compromised/subpoenaed, at least you still have the PFS keys for individual conversations. Those would need to be subpoenaed (or otherwise made not-secret) as well, and so in theory your data is still safe even if they go after john Q terrorist's data.
bigiain 13y ago
The hope is that the "replicable key revealing process" is difficult and time consuming - which is worthwhile for an attacker with sufficient resources if going to the effort to reveal a key results in breaking every encrypted session from that source. PFS means they'd go to all that effort to reveal an ephemeral key for only one session. It'd be _well_ worth the NSAs time/money to burn 10 million cpu hours brute forcing Google's TLS key if it gave them every encrypted session's cleartext past and future. It's not practical to burn 10 million cpu hours for every SSL session connecting to Google's servers.
- graue 13y ago
  Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panacea here.
  - spicyj 13y ago
    If I understand properly, having Google's private key only allows you to do MITM attacks, not to passively decrypt traffic using PFS algorithms.
    - graue 13y ago
      Absolutely. This is why PFS protects past sessions, because you can try to decrypt the past, but you can't MITM the past. But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? I really doubt it. PFS or not, a leaked private key means game over for all data transferred after the leak and until that key is replaced. And that's my point, the reason I made the statement you're replying to: it would still be well worth the NSA's time to crack Google's private key, and PFS doesn't somehow make that scenario not bad. Your statement is correct, but, I argue, not terribly relevant. (Sorry if this post sounds confused; it's late.)
      - mortehu 13y ago
        > But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? MITM attacks have the disadvantage that they can be noticed by communicating the session key through a second, more secure, channel, for example one using a client certificate.
  - bigiain 13y ago
    Isn't it a little more complicated than that? With PFS, the webserver and the browser (yeah, oversimplifying here) each generate a random number and "create" a temporary session key without revealing enough about their individual random numbers to an eavesdropper. So as well as Google's private key, the attacker also needs the "agreed upon ephemeral key" for each session if they want to passively snoop. (And if they're deeply enough into Google's infrastructure to see and archive those, then don't need to decrypt SSL connections - they can just syphon the cleartext out from inside the SSL termination). (Note: I'm still trying to educate myself here. I fear I may be not fully understanding the subtleties and differences between DH & DHE, and when that "E" means "ephemeral" and whether it also sometimes means "elliptic"…)

by Arnor 13y ago

jstanley 13y ago

I think that is an intractable problem. It is impossible to design a system that is not vulnerable to flaws in its design. The idea is to design a system that doesn't have flaws.

gknoy 13y ago

I think your concerns are mitigated by the attack vectors. If cracking encryption with N bit length keys someday becomes trivial, it doesn't matter what keys we used in the past: You're right. My meager understanding is that we don't expect this to be the case anytime soon, and worries about moore's law or asics for cracking keys can be mitigated by increasing key size until it's infeasible to brute force. If your main SSL key is compromised/subpoenaed, at least you still have the PFS keys for individual conversations. Those would need to be subpoenaed (or otherwise made not-secret) as well, and so in theory your data is still safe even if they go after john Q terrorist's data.

bigiain 13y ago

The hope is that the "replicable key revealing process" is difficult and time consuming - which is worthwhile for an attacker with sufficient resources if going to the effort to reveal a key results in breaking every encrypted session from that source. PFS means they'd go to all that effort to reveal an ephemeral key for only one session. It'd be _well_ worth the NSAs time/money to burn 10 million cpu hours brute forcing Google's TLS key if it gave them every encrypted session's cleartext past and future. It's not practical to burn 10 million cpu hours for every SSL session connecting to Google's servers.

graue 13y ago
Although even with PFS, cracking Google's private key would still give them access to every future encrypted session, until the key changed. So PFS is no panacea here.
- spicyj 13y ago
  If I understand properly, having Google's private key only allows you to do MITM attacks, not to passively decrypt traffic using PFS algorithms.
  - graue 13y ago
    Absolutely. This is why PFS protects past sessions, because you can try to decrypt the past, but you can't MITM the past. But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? I really doubt it. PFS or not, a leaked private key means game over for all data transferred after the leak and until that key is replaced. And that's my point, the reason I made the statement you're replying to: it would still be well worth the NSA's time to crack Google's private key, and PFS doesn't somehow make that scenario not bad. Your statement is correct, but, I argue, not terribly relevant. (Sorry if this post sounds confused; it's late.)
    - mortehu 13y ago
      > But do you think the slightly harder task of running MITM attacks (as opposed to simply siphoning off a copy of the data as it passes) would thwart an entity like the NSA? MITM attacks have the disadvantage that they can be noticed by communicating the session key through a second, more secure, channel, for example one using a client certificate.
- bigiain 13y ago
  Isn't it a little more complicated than that? With PFS, the webserver and the browser (yeah, oversimplifying here) each generate a random number and "create" a temporary session key without revealing enough about their individual random numbers to an eavesdropper. So as well as Google's private key, the attacker also needs the "agreed upon ephemeral key" for each session if they want to passively snoop. (And if they're deeply enough into Google's infrastructure to see and archive those, then don't need to decrypt SSL connections - they can just syphon the cleartext out from inside the SSL termination). (Note: I'm still trying to educate myself here. I fear I may be not fully understanding the subtleties and differences between DH & DHE, and when that "E" means "ephemeral" and whether it also sometimes means "elliptic"…)