4 ms·

> If A got his keys stolen, he's indeed in for some trouble. This is slippery-slope weasel-wording. The particular impersonation-to-A scenario is well known (d

by wfn 10y ago

> If A got his keys stolen, he's indeed in for some trouble. This is slippery-slope weasel-wording. The particular impersonation-to-A scenario is well known (due to a standard DH key agreement property) and can be protected against (see lvh's top comment for examples how it's possible to do that).

snvzz 10y ago
> This is slippery-slope weasel-wording. Please. > The particular impersonation-to-A scenario is well known (due to a standard DH key agreement property) and can be protected against (see lvh's top comment for examples how it's possible to do that). Yes, it's an excellent explanation. But ultimately, while this should be fixed, it is not critical, as it requires A's private keys be stolen. For the layman, without touching into the crypto details, the analogy GreyHatter made is not so bad.
- lvh 10y ago
  Would you similarly argue that perfect forward secrecy doesn't matter? After all, Alice should just keep her keys secure. If not, why? (I've made the same point in more detail here: https://news.ycombinator.com/item?id=13395294 https://news.ycombinator.com/item?id=13395294)
  - snvzz 10y ago
    > Would you similarly argue that perfect forward secrecy doesn't matter? No, I wouldn't. I've only seen this reply after reading the post you're referencing, which I found quite elucidating. I would, however, note there's a huge difference in consequences. Without forward secrecy, old communications would be compromised when the private key is. This isn't comparable to anything about future conversations after the key is stolen, a situation where I'd personally have way lower security expectations and would be surprised if this wasn't the case among the general public, outside the crypto community. In the first place, short of another HeartBleed-style vulnerability (not impossible, as heartbleed demonstrated), the key being stolen would typically involve a serious compromise of an endpoint, where the attacker achieves enough execution to install a rootkit, at which stage, with KCI or without, the attacker can present to the compromised user whatever they want. I do, to some degree, understand the attitude of the current developers behind the toktok toxcore fork. They want to read and understand the code, then produce documentation about the code and the protocol, and only at that point (with all the information available) tackle the design issues, including this arguably low priority KCI issue. I believe it reasonable, particularly after considering that they're spending about zero effort in promoting its use to the general public. While it's pretty fair and I'm sure welcomed for their code to be looked at and vulnerabilities found, all things considered, I do not think it's, at all, fair to give them and their early-stages project the kind of negative spotlight they're getting.
    - lvh 10y ago
      I disagree with the assertion that key compromise involves a rootkit; HeartBleed itself doesn't fit that bill. The vast majority of key compromises are operational screwups with data disclosure, they generally do not lead to arbitrary code execution. The specific claim about future communications is having people impersonate anyone to _you_, not you to anyone. I don't think this is obvious to the general public. More importantly, this implies that the victim knows their key has been compromised.
      - snvzz 10y ago
        > I don't think this is obvious to the general public. My point was that I don't think it's obvious to the general public, either, that they can have any expectation after their key is compromised. Forward secrecy, some of them might have even heard about, particularly in the present climate where ssllabs is requiring it for its A grade. > More importantly, this implies that the victim knows their key has been compromised. I threw in some talk about my and the general public's expectations about the scenario where an endpoint's key is compromised, but I don't think I included knowing it actually happened among these expectations. The rootkit scenario which I expect as most common compromise (endpoint machine utterly compromised) kind of implied the user is none the wiser. I'm not sure there's anyone out there that expects an Amiga guru meditation style alert saying "Your private key has been compromised!" to appear. > The vast majority of key compromises are operational screwups with data disclosure, they generally do not lead to arbitrary code execution. This is honestly surprising.

by wfn 10y ago

snvzz 10y ago

> This is slippery-slope weasel-wording. Please. > The particular impersonation-to-A scenario is well known (due to a standard DH key agreement property) and can be protected against (see lvh's top comment for examples how it's possible to do that). Yes, it's an excellent explanation. But ultimately, while this should be fixed, it is not critical, as it requires A's private keys be stolen. For the layman, without touching into the crypto details, the analogy GreyHatter made is not so bad.

lvh 10y ago
Would you similarly argue that perfect forward secrecy doesn't matter? After all, Alice should just keep her keys secure. If not, why? (I've made the same point in more detail here: https://news.ycombinator.com/item?id=13395294 https://news.ycombinator.com/item?id=13395294)
- snvzz 10y ago
  > Would you similarly argue that perfect forward secrecy doesn't matter? No, I wouldn't. I've only seen this reply after reading the post you're referencing, which I found quite elucidating. I would, however, note there's a huge difference in consequences. Without forward secrecy, old communications would be compromised when the private key is. This isn't comparable to anything about future conversations after the key is stolen, a situation where I'd personally have way lower security expectations and would be surprised if this wasn't the case among the general public, outside the crypto community. In the first place, short of another HeartBleed-style vulnerability (not impossible, as heartbleed demonstrated), the key being stolen would typically involve a serious compromise of an endpoint, where the attacker achieves enough execution to install a rootkit, at which stage, with KCI or without, the attacker can present to the compromised user whatever they want. I do, to some degree, understand the attitude of the current developers behind the toktok toxcore fork. They want to read and understand the code, then produce documentation about the code and the protocol, and only at that point (with all the information available) tackle the design issues, including this arguably low priority KCI issue. I believe it reasonable, particularly after considering that they're spending about zero effort in promoting its use to the general public. While it's pretty fair and I'm sure welcomed for their code to be looked at and vulnerabilities found, all things considered, I do not think it's, at all, fair to give them and their early-stages project the kind of negative spotlight they're getting.
  - lvh 10y ago
    I disagree with the assertion that key compromise involves a rootkit; HeartBleed itself doesn't fit that bill. The vast majority of key compromises are operational screwups with data disclosure, they generally do not lead to arbitrary code execution. The specific claim about future communications is having people impersonate anyone to _you_, not you to anyone. I don't think this is obvious to the general public. More importantly, this implies that the victim knows their key has been compromised.
    - snvzz 10y ago
      > I don't think this is obvious to the general public. My point was that I don't think it's obvious to the general public, either, that they can have any expectation after their key is compromised. Forward secrecy, some of them might have even heard about, particularly in the present climate where ssllabs is requiring it for its A grade. > More importantly, this implies that the victim knows their key has been compromised. I threw in some talk about my and the general public's expectations about the scenario where an endpoint's key is compromised, but I don't think I included knowing it actually happened among these expectations. The rootkit scenario which I expect as most common compromise (endpoint machine utterly compromised) kind of implied the user is none the wiser. I'm not sure there's anyone out there that expects an Amiga guru meditation style alert saying "Your private key has been compromised!" to appear. > The vast majority of key compromises are operational screwups with data disclosure, they generally do not lead to arbitrary code execution. This is honestly surprising.