On 03/26/2014 03:27 PM, Joseph Bonneau wrote: > I hope not, because I fully expect most users will do neither. My goal > was to provide *some* protection for users who don't do anything thanks > to a few users who actually do audit the log against their own history. > Security comes from the fact that the authorities might be able to MITM > some users who aren't checking, but eventually they'll slip up and > attack a users who does check and can then prove it.
Maybe I don't understand. My reading was that no 3rd party can audit the log to discovery anything about a MITM of any other user, since key changes will happen frequently in the normal use case, which would look identical to a MITM. 3rd parties will just see keys changing a lot. They'll even frequently see keys changing, then changing back to what they were before that change. That would mean the only people who can derive potentially useful information from the log are the users themselves, or potentially the people they're corresponding with at that moment. That's why I understand it to be trading in-band verification for self-audit based verification. My sense is that users won't be able to handle that themselves, and worse, the ones who try will forget their own history and end up concluding that they've been MITMd when they haven't. > Hopefully this is > enough to make the attacker wary. This has been referred to as the > "malicious but cautious" adversary model, and I like Tom Ritter's > explanation that 98% of users trust and 2% of users verify. If we're going for 2% verify, does this accomplish more than making the visibility of key conflicts an option that defaults to off, but which 2% of users will flip on? - moxie -- http://www.thoughtcrime.org _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
