31–40 of 41 posts
This is awesome! I was at bar with a group of security people / cryptographers during the Real World Crypto conference last week. We were discussing what we thought some of the most important security research papers from the last five years were. Everyone agreed that CONICKS (which is what Key Transparency is based on), will likely have a huge impact in the next five years or so. I'm excited to see Google finally op…
Got a link to a copy of this paper you can share? A quick google search didn't turn up anything useful.
> The relationship between online personas and public keys should be automatically verifiable and publicly auditable. This description sure sounds like exactly what https://keybase.io provides.
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) ?
> The relationship between online personas and public keys should be automatically verifiable and publicly auditable. This description sure sounds like exactly what https://keybase.io provides.
Off-topic: I have 10 Keybase invites — does anybody want or need one?
In Certificate Transparency, a CA is responsible for sharing its issued certificates to CT. In Key Transparency, anyone can register a key for an email address; they just have to arrive first. Is there any provision for preventing squatting ?
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.
Is this something more than a public key server? Unclear if it tries to tie identity to accounts for verification like Keybase. This is something I thought FB would be in a better position to do a while back: http://zalberico.com/essay/2016/03/23/Facebook-and-Public-Ke... . Though I guess most have just moved to walled garden encryption models instead of GPG - Moxie talks a bit about that here: https://moxie.org/blog…
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.githubu…
It's already implemented in Android OpenKeychain.
Earlier quoted context omitted.
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.
Ok I see, KT provides a visible log of all changes happening to a given key, but my initial question still stands: I can squat, say, eschmidt@google.com today and wait for someone to pay me a huge amount of money to give up that name ?
[1]: https://github.com/google/key-transparency/blob/master/docs/...
Earlier quoted context omitted.
Ok I see, KT provides a visible log of all changes happening to a given key, but my initial question still stands: I can squat, say, eschmidt@google.com today and wait for someone to pay me a huge amount of money to give up that name ?
I'm not 100% sure, but it sounds like that's outside the scope of key transparency, and Google is envisioning that the ["certification authority that the system [represents]"][1] would verify that you indeed own `eschmidt@google.com` before letting you register an account using that address. [1]: https://github.com/google/key-transparency/blob/master/docs/...
Thanks for the clear-up !