Security Through Transparency
security.googleblog.com
Security Through Transparency
1–10 of 41 posts
Re: Security Through Transparency
#2Re: Security Through Transparency
#3The post mentioned the inadequacy of PGP. I would like to see a comparison with Keybase ( https://keybase.io ) which addresses similar problems.
Re: Security Through Transparency
#4This description sure sounds like exactly what https://keybase.io provides.
Re: Security Through Transparency
#5> 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.
Re: Security Through Transparency
#6The blog is more 'why' while the repo is mostly 'how'.
Re: Security Through Transparency
#7This 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/gpg-and-me/
Re: Security Through Transparency
#8Re: Security Through Transparency
#9Is 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…
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.
Re: Security Through Transparency
#10Is 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…
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.