On Sat, Mar 29, 2014 at 3:39 AM, Ben Laurie <[email protected]> wrote: > On 29 March 2014 04:15, Trevor Perrin <[email protected]> wrote: >>>> - Even if Bob observes the service being malicious, he has no way to >>>> prove this - it will just be his word against the service. So the >>>> "herd immunity" value of exposing the service's perfidy seems low. >>>> (In contrast to Certificate Transparency for HTTPS, which is likely to >>>> expose bad/hacked CAs who obviously shouldn't be issuing the revealed >>>> certificates). >>> >>> Hmm. Presumably Bob would be able to show a new key, signed by many of >>> his correspondents, that did not correspond to the published key. That >>> seems strong than just Bob's word. >> >> So Bob and his friends call the NY Times and explain that a published >> key for Bob yesterday wasn't Bob's real key, and they've signed Bob's >> real key to prove it. >> >> They're sure this is a "MITM" and not just a glitch in the 3rd-party >> app Bob's running, malware/hackers targeting Bob, or Bob forgetting >> about the other app on his tablet. They promise they're telling the >> truth and not just trying to get attention. >> >> Maybe it's a MITM, maybe not. How would the NYT know? >> >> Or rather - will SocialNetworkCo want to deploy a system that (A) >> advertises they could MITM their users, and (B) gives their most >> paranoid users the ammo to claim they've done so, without proof one >> way or another? > > I guess what you need is multiple independent logs - then they would > all have to collude to present a false key.
In the single-log-run-by-service case, Bob can detect when a key he thinks is false has been published. Adding multiple independent logs (i.e. other parties maintaining their own sparse merkle tree) isn't needed for that. Do these extra logs help Bob prove to some "judge" that a false key was published? Bob would need to somehow authenticate to some set of independent logs to "register" his new public key on every key change. That's more complexity. The presumed benefit is that if one log publishes a different key then the others, it's easier to point a finger. But there's a ton of other ways the logs could get out of sync, besides log misbehavior. For example, Bob or his software could fail to register with the correct set of logs within some timeframe. Or Bob or a hacker/malware could maliciously register a different public key with one log, then falsely accuse it. So I'm not sure this is an improvement in being able to prove log misbehavior. Even if it is, I'm skeptical of the added cost/complexity. Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
