Hacker News Reader

Comment by jrockway | Hacker News Reader

> Your app will encrypt just for you and then awake and rekey in the background when that Twitter user joins and announces a key.

Isn't this the weak link in the chain? If you can convince the client that you're the person the data was encrypted for, it will re-encrypt it with a new key and send it to you, thus making the encryption useless. What's the protection against this, other than "don't worry, we won't introduce bugs"? (I'm not saying Random Twitter Troll will do this, but couldn't "the government" compel Keybase to re-encrypt your content with a key they have?)

What does the encryption add here that a server controlling access doesn't?

View on HN

Well I can audit the source code of my client and be assured that it will only rekey when it sees proof (posted via twitter) that the person the data was encrypted for has joined.

Keybase doesn't have my private key (only I do), so they can't re-encrypt the contents.

(sorry if I misunderstood your question)

Cross device usability suffers, then. Credential locked keyfiles stored server side could be served to end users without revealing the key to the server - you would still need to input the credential locally to open the keyring, but then you could just login to a client rather than having to copy public keys around by file.

I imagine the later isn't impossibly complex, but would require slick engineering to get over the barrier of expectations most people have.

I'm not sure about that either. The weakest link seems to be a national security letter to Keybase where they distribute a backdoored version of the FS driver to Alice, and adds the key of Eve to all messages also encrypted to Bob.

However, Keybase can't just broadcast "Eve on twitter is Bob!" - the client gets that announcement and links you to the tweet that claims it, where you audit the twitter handle, key fingerprint, etc.

Anybody who's worried about being the target of a National Security Letter can just compile from source instead of using a binary distribution.

This is why the CJEU doesn't view the USA as a safe habour anymore.

US laws have broken the internet.

If the NSA is your adversary model, Keybase isn't for you. If the NSA is your adversary model, NO system involving any central servers is for you, unless they only act as a dumb relay. Since Keybase is also the provider of your proof that another party is who they claim to be, they will always be suspectable to a government adversary. If you want to be NSA-safe, you can't trust any third party companies code, and that just leaves you DOA.

tldr; this isn't for the NSA adversary model

I think the bigger problem with this is the Skype message deliverability problem. Everyone uses battery-powered devices (laptops and cell phones) now, so it's possible that days or weeks could go by before the app could wake up and rekey the data.

Reply on news.ycombinator.com