
Security Through Transparency - maxerickson
https://security.googleblog.com/2017/01/security-through-transparency.html
======
eridius
> _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](https://keybase.io) provides.

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

~~~
saycheese
Unless I'm missing something, an invite is not need to use Keybase.

~~~
beardog
Yes it is to skip the long line, although there are semi-secret invite codes
that can be used infinitely.

------
dadrian
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 open-sourcing their efforts in Key Transparency.

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

~~~
srparish
[https://eprint.iacr.org/2014/1004.pdf](https://eprint.iacr.org/2014/1004.pdf)

------
fossuser
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...](http://zalberico.com/essay/2016/03/23/Facebook-and-Public-Key-
Encryption.html).

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/](https://moxie.org/blog/gpg-and-me/)

~~~
eridius
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...](https://raw.githubusercontent.com/google/key-
transparency/master/docs/images/oTXGfRZ2X0m.png) \- 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.

~~~
nhxu
It's also worth mentioning that there is a draft spec for adding social proofs
directly to OpenPGP: [https://tools.ietf.org/html/draft-vb-openpgp-linked-
ids-01](https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01)

It's already implemented in Android OpenKeychain.

------
politician
The post mentioned the inadequacy of PGP. I would like to see a comparison
with Keybase ([https://keybase.io](https://keybase.io)) which addresses
similar problems.

~~~
tscs37
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.

~~~
nickik
Keybase does not need a PGP setup. Keybase has moved on from that and use NaCl
to solve the multi-device problem. GPG is just one more node in your trust
chain.

------
rakoo
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 ?

~~~
rmhrisk
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.

~~~
rakoo
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 ?

~~~
Ajedi32
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/...](https://github.com/google/key-
transparency/blob/master/docs/design-improvements.md)

~~~
rakoo
Ah, that's something that I didn't see at all: google would be in charge of
running the KT peer for google.com, yahoo for yahoo.com, etc...

Thanks for the clear-up !

------
maxerickson
The article links [https://keytransparency.org/](https://keytransparency.org/)
which is currently just a pointer to [https://github.com/google/key-
transparency/](https://github.com/google/key-transparency/) .

The blog is more 'why' while the repo is mostly 'how'.

------
masteryupa_
These principles also have important political ramifications which were
detailed in a recent article sharing almost this exact title:
[https://thedaleyreview.wordpress.com/2017/01/08/transparency...](https://thedaleyreview.wordpress.com/2017/01/08/transparency-
as-security/)

------
rmhrisk
This article from TechCrunch does a good job explaining Key Transparency -
[https://techcrunch.com/2017/01/12/googles-key-
transparency-p...](https://techcrunch.com/2017/01/12/googles-key-transparency-
project-aims-to-ease-a-tough-task-in-cryptography/)

------
rmhrisk
To understand the technical approach to the solution this is a good resource -
[https://github.com/google/key-
transparency/blob/master/docs/...](https://github.com/google/key-
transparency/blob/master/docs/overview.md)

This is also useful for understanding some of the core differences between
CONIKS and Key Transparency - [https://github.com/google/key-
transparency/blob/master/docs/...](https://github.com/google/key-
transparency/blob/master/docs/design-improvements.md)

------
a_imho
Do I understand correctly using keytransparency I'm backing Google to be the
authority to verify that a key is indeed 'me'? Why would I want to do that?
Why would anyone want to do that?

------
baybal2
I don't like how they begin it with an attack on GPG

------
eternalban
So everytime you want to communicate you ping Google's servers?

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

~~~
eternalban
What are the implications of this?

    
    
        Get a /service account key/ and download the generated JSON file.
    
        The service account key is used to verify client OAuth tokens.
    
    

/from here:/
[https://console.developers.google.com/apis/credentials](https://console.developers.google.com/apis/credentials)

