1

I (think) I understand roughly how Keybase works to establish verifiable connections between a user on Keybase and a set of other identities (e.g. Twitter, GitHub, etc.). One of the steps to accomplish this to sign and publicly post a proof of this connection on each connected account. Part of that proof consists of "the hash of his previous signature" (which I assume means hash of the previous proof).

What is the purpose of this element of the Keybase architecture: what does signing hashes of previous proofs achieve?

  • This might be of help. In essence its forming a chain that proves your current process follows on from the previous. It forms an immutable log of events : keybase.io/docs/server_security/… – ISMSDEV May 30 '17 at 12:10
  • @ISMSDEV: The feature asked about here existed (and presumably accomplished something) before Keybase added posting to the Bitcoin blockchain (which is what you link discusses). – orome May 30 '17 at 12:13
  • Thanks, good point. But is the purpose not the same. To build an immutable log? – ISMSDEV May 30 '17 at 12:15
  • @ISMSDEV: I guess. I'm not at all knowledgeable about security (I just impersonate someone who is) so I'm not sure what an "immutable log" accomplishes (that's distinct from what the reset of what Keybase does). So, for that matter (and this would be a part of an answer) I'm not sure what posting to Blockchain does. – orome May 30 '17 at 12:59
1

I see there are great comments already, but let me condense them and add the missing pieces:

Why hashing the previous proof into the current proof?

As already indicated by ISMSDEV, keybase is essentially building an append-only data structure, an immutable log. The idea is that by incorporating the previous proof, you not only sign the current statement but reassure your knowledge of the previous one, as well.

Why is such a chain a good thing?

Append-only data structures have some nice properties: The sequence is fixed and this is easy to prove and verify. Assume you have a chain like this:
A -> B
Where A is the first proof and B is a proof that incorporates the hash of A. If you now want to later add a proof X that "happened" between A and B, you can embed the hash of A to make it a successor. However, the forked chain now looks something like this:
X <- A -> B
If you would really want X to be part of the chain, you would need to create a new B' that incorporates the hash of X instead the one of A. This would look like this:
A->X->B' Now the nice thing is that this will render the existing proof of B (the signature) wrong, since the signed content changed. Hence, people can detect this, because the head is now B' instead of B. To make this more clear, if you have a long chain, such as:
A-> B -> ... -> Z, then you can verify no element of the whole chain ever changed by remembering only the current head of the chain. If at ANY point in the chain something is changed, all elements following would need to be recreated and the top element('s hash). So for a service that continuously publishes the chain and hence the head signature, you only need to remember this one and as soon as the chain changes (probably new elements were appended), you just need to verify everything from the head you already had and after that, remember the new one.
If you are interested in more details, Keybase explains some more details of their approach here.

About committing to the Bitcoin Blockchain...

Ok so what I explained above already holds without Bitcoin. But why now also push to the Bitcoin chain? Essentially, Bitcoin users/clients are continuously checking and verifying the Bitcoin chain to be an append-only log, a public, timestamped ledger. This gives us a public, sealed log of events that is secured by a large, global community. Now people started to exploit this by committing data, such as hashes, to the Blockchain in order to securely and irrevocably timestamp their data. The important part here is that in contrast to a sig chain that you as a service owner publish yourself, you cannot rewrite history. For you as a Keybase user, this means the following: If, at any point in time, the head hash available through the Keybase service and the one hashes into the Bitcoin Blockchain at that time diverge, you now something is fishy. The Keybase people call this "Be Honest or Get Caught". You cannot achieve this by posting to a web page only since it can change any time. The Bitcoin Blockchain however is (almost*) unchangeable.

(*) Of course, Bitcoin is not perfect as well, but the probability or attacks that achieve large-scale history rewriting are tiny (see 51% attack).

So what's the bit picture

The big picture is that companies like Keybase put a lot of effort into building crypto software that reduces the amount of trust you have to put into the creators/service owners to a minimum. Beside establishing transparency through open sourcing code, publishing the sig chains, hashes etc allows customers to even use the service if they do not trust it. The idea is that you as a service provider cannot cheat your customer.

Ok so that was a long answer, but I hope it will clear things up. I just felt that there is some context that needs to be mentioned when talking about such things.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.