Security Through Transparency

Can't upvote this enough!

I even wrote a prototype chrome extension for a few friends and myself: http://lettergram.github.io/AnyCrypt/

I love the idea of keybase, I just wish it was used by more people.

I just got an invite to Keybase. Is there a reason why

1. it's invite based?

2. it supports very few external services that you can verify (I can't figure out a way to verify LinkedIn or Gitlab for instance) ?

Off-topic: I have 10 Keybase invites — does anybody want or need one?

Got a link to a copy of this paper you can share? A quick google search didn't turn up anything useful.

Is this something more than a public key server? Unlike a simple public key server, this provides privacy protecting elements. The project utilizes Zero Knowlege Proofs (ZKP) to limit your access to keys associated with users you already know.

How is this different than KeyBase? It is similar. Some differences include the use of ZKP, it is a generic key store designed (could be used for PGP or E2E messaging), it is designed to scale to trillions of entries, anyone can run a log, and architecturally it should scale significantly better. KeyBase is doing great work, though.

Looking at the documentation in the repo, it sure looks to me like it's just a keyserver with a provable append-only model so you can audit every change. My cursory glance did not come up with any way to prove that the keys for a given account were actually added by someone with the authority to do so (there was even a screenshot showing that users could see when new unrecognized keys were added - https://raw.githubusercontent.com/google/key-transparency/ma... - which suggests that it relies on the user themselves to notice something going wrong).

The Design Overview does reference the fact that a user would have account credentials, and suggests that an attacker would have to compromise those credentials in order to change the keys on the user's account. So that's good. But that's still a single point of failure.

Compare this with keybase.io, where if an attacker compromises your account, they can't associate a new key with e.g. your twitter account thus tricking anyone who knows you over twitter into using your new key (they'd have to remove your twitter account from your profile in order to change the key). So keybase.io uses the variety of social networks as proof that your key really is owned by you, whereas Key Transparency seems to rely entirely on other people noticing via the key transparency history that the keys on the account all changed at some point (which doesn't necessarily even mean the account was compromised, it's possible the user did that deliberately because e.g. they lost control of their private key).

Note: I must repeat that I gave this only a cursory glance, and I didn't pay attention to some of the potentially-interesting properties here such as privacy protection. It's very plausible that Key Transparency does have valuable properties that keybase.io doesn't provide.

I can give you in comparison, right now.

CT is mostly an automagic comparison.

You don't need to do anything and you get encryption and trust and all that stuff.

While keybase is a step in the right direction, it does not make communication any more secure by default.

You still need to setup PGP and use it to benefit from keybase.io

So in essence; CT is that one step ahead of keybase.io that makes it much much more useful but keybase is still a step in the right direction.

One of the differences between Key Transparency and other solutions is the role of certifying and logging have been separated. In other words, being in the directory does not mean the identity has been verified. The verification of control of an email address is the role of the certifier. Your requirements of the certifier are an application specific decision.

I didn't see any evidence of them suggesting that.

No.

First, like CT you want an ecosystem of logs.

Second, you have caching and in-band exchanges as means to mitigate some of that.