
Server Security - jashkenas
https://keybase.io/docs/server_security
======
jashkenas
Hey mods editing this post — this isn't a general article about server
security, this is a _specific_ article about "Keybase.io's Server Security",
which was the original, more appropriate, more useful, title. Why fix what
ain't broke?

~~~
oconnore
Based on the lack of human sensibilities, it could be a robot implemented by
someone who believed the heuristic was acceptable.

------
peterwwillis
So here's how I would make a Keybase.io that is resistant to server
compromise.

1\. don't store private keys (of users). 2. distribute the organization around
the globe; different datacenters, different states/countries, different
peers/service providers. 3. use different infrastructure, hardware/software,
hardened, with tripwires. 4. make your clients auth all the sources, with a
minimum of N/3 valid, identical responses from distinct parts of the network.
5. implement the rest of the service's functionality as described in the post.

As long as you have a shit-ton of distributed locations you can survive
internet outages, state actor intervention, service provider compromise and
server compromise. It would all have to be highly available mesh network, of
course, but it's feasible and should be pretty low on resource use as it's
just public keys you're copying around.

~~~
kylec
Yes, you can architect a system that's more difficult to compromise or knock
offline, but a better solution would be to remove the need to trust the server
or to have it constantly online. To their credit, the Keybase guys have done
this - their client fetches information about a user from the Keybase server,
but performs the verifications itself and deposits the public key into your
PGP keyring if successful. Once that's done, you don't need Kebase at all in
order to communicate with that person securely.

------
rdl
Wouldn't a server compromise allow someone to "lie" to the web client only,
while continuing to give correct answers to the standalone client? Seems like
that would be very difficult to catch.

(or, just hack the web client so it lies, independent of what it actually sees
from the server)

Server compromise wouldn't even need to take place on the server itself.

------
eric_bullington
I'm really enthusiastic about Keybase and am hopeful that it will succeed
where others have failed to push mainstream adoption of PGP.

I've been trying to think of innovative applications of the Keybase API [1],
which exposes much (most?) of the functionality available via the command line
client.

I've got a few vague projects in mind but would love to hear more ideas. I've
got a few Keybase invites left and will give them while they last to anyone
who proposes an interesting use of the API, as long as Keybase doesn't object
to this type of "contest" [2].

1\. [https://keybase.io/docs/api/1.0](https://keybase.io/docs/api/1.0)

2\. maxtaco and malgorithms, please let me know if that's an inappropriate use
of the invites and I'll rescind the offer.

~~~
malgorithms
Totally appropriate. I should say that we don't really want to be in the
business of building general crypto apps ourselves, but Keybase identity
proofs can make a bunch of things possible. Anything from financial
transactions (send a BTC to twitter user X and know it's going to an address
they control) to data access (let Keybase/github/twitter user Y access this
server/file/whatever). The idea here is that any app can (1) ask Keybase for a
user's key and identity proofs, and then (2) verify it all.

The API is not done, btw. If another call is needed, and you're really serious
about building it, we will expand the API.

~~~
eric_bullington
>send a BTC to twitter user X

Exactly. I've had my eye on Keybase issue #218 [1], and I'm hoping that you
all will provide a way for users to provide a confirmed Bitcoin payment
address.

You could just generate a unique message for the user to sign with the address
using their Bitcoin client. Most bitcoin-qt and most other GUIs even have a
menu option now for signing, so it should be easy for users to do.

To preserve privacy, a user could even post a stealth address, to the extent
that stealth addresses are supported in the user's client software. Most
clients aren't there yet, but I think more will start supporting stealth
addresses this year.

1\. [https://github.com/keybase/keybase-
issues/issues/218](https://github.com/keybase/keybase-issues/issues/218)

------
mikegioia
I love Keybase and the possibilities are endless with it. I've already started
working on an end-to-end, encrypted filesharing app utilising the keybase API
and I've got 2-3 ideas for other apps already. It's amazing what having easy
access to PGP can do.

I think the biggest nut to crack is going to be making the onboarding process
as simple as signing up for an email account. I dream of a day where the
majority of people have PGP keys and while I think keybase's signup flow was
straightforward, I can see how it would be very confusing for an average
computer user.

------
Siecje
Why not use Oauth to verify someone on Twitter instead of having someone post
a tweet?

How many people are automatically logged in?

The only thing is that you would see the keybase message that you didn't send
but it is Twitter and most people don't look back on their recent tweets.

~~~
Sidnicious
Tweets can be seen publicly, unlike OAuth connections. This is true for the
other Keybase proofs too.

~~~
malgorithms
yes, the premise here is that the Keybase server can be caught lying. If you
want twitter user X's public key, Keybase can tell you the key and which tweet
to look at to verify it. Then you can check it yourself. OAuth doesn't allow
this.

------
lifeisstillgood
did anyone think there ought to be a similar way to hash-chain all the /etc
files on a server - a 'tripwire' approach (hmmm, I seem to remember tripwire
doing hashes but not as a chain)

------
mschuster91
For the untrained eye, this looks like a partial implementation of a Bitcoin
blockchain, just without the proof-of-work. Or like a git repository without
forking.

Am I right or did I pick up something wrong?

~~~
oleganza
It's more like Git where the latest action is linked to all previous action +
data is organized in a tree so any piece can be efficiently demonstrated as a
part of the trusted whole (via a merkle branch).

~~~
malgorithms
Yes; here's a tl;dr: for a given user, all of their signatures form a chain of
signed statements, where each one points at the previous statement. They don't
have to be the same kind of statement: your identity proofs, your tracker
statements, etc.

And then each user's chain is itself pointed at in a leaf node of the signed
merkle tree. (The tree is signed by Keybase).

So you as a client can verify any individual's personal signature chain, and
you can verify Keybase's merkle tree. Finally, and this is the more subtle
connection, each user's signature chain has statements about the merkle tree
itself, so you can verify all these users are seeing the same Keybase-signed
merkle tree.

