search

xgess / keybase_merkle_prover

dockerized, deployable python keybase chat bot that OpenTimestamps Keybase's merkle roots
MIT License
12 stars 1 forks source link

How does this prevent Keybase servers from presenting different merkle roots? #1

Open InnovativeInventor opened 4 years ago

InnovativeInventor commented 4 years ago

Interesting project! Timestamping Keybase messages is a great idea (although redundant). In the README.md it says

that uses OpenTimestamps to create proofs so the Keybase servers cannot present different merkle roots to different users (this would theoretically allow them to withhold information like Alice revoking a device). Keybase already does this (i.e. without OpenTimestamps), but I'm doing it in a different way with different tradeoffs (much more often - 20 minutes instead of 12 hours, and a different process to verify).

How exactly does this make it harder for Keybase servers to present different merkle roots to different users? How does this provide the same security properties that Keybase is already providing? What is stopping the adversary from simply timestamping multiple different merkle roots and presenting the corresponding proofs/hashes to different users?

(Disclaimer: I have only read the README)

xgess commented 4 years ago

hi @InnovativeInventor! sorry i missed this earlier. thanks for your interest :)

the way to see if keybase is lying is to catch them serving different merkle roots to different people -- or serving you a merkle root that does not eventually have a path to something that got pinned into bitcoin. every ots verified merkle root should have a path to the recent changes keybase tells you have happened to the users you care about. this bot just give you more chances to catch them, it doesn't do the comparison or verification. i suppose that's an exercise left for now to the reader.

the other super neat thing you can do with this bot is have your own private system inside a team, which would make it significantly harder for keybase to lie, because they don't know what you're checking. so let's say you and i (and 10 of our favorite colluders) were in a team called supersecret. we could make a channel called #merklechecks, and run a slightly modified version of this bot to post into that channel instead of publicly. it could even be a "restricted_bot" so it cannot read any of the other messages in the team. since it's a private team with messages encrypted only for members of the team, the keybase servers would not know that this bot was anything other than a 20-minute cron job. BUT now you and i would know that, as long as we can both see these messages in the channel, we have a canonical keybase-merkle-root that we can both compare to. if keybase serves either of us anything that does not have a path to what's been ots verified, something is wrong.

InnovativeInventor commented 4 years ago

Thanks, that makes more sense. Perhaps you should clarify some of the claims made in the README. From the README, it isn't so clear what threats you're trying to prevent/protect against.