[messaging] Transparency for E2E encrypted messaging at a centralized service

[Trevor Perrin]

On Sat, Mar 29, 2014 at 3:39 AM, Ben Laurie <ben at links.org> wrote:
> On 29 March 2014 04:15, Trevor Perrin <trevp at trevp.net> 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