Live data from Hacker News

Introducing the Keybase filesystem

keybase.io

121–130 of 501 posts

Re: Introducing the Keybase filesystem

#121

so assuming one trusts the model, would it work to have something like: I have a /me/private/yourwebsite.com set up to be shared between me and your particular site, the link is set-up when I sign up when I log in your site, it would look for this directory to be there, in this directory there will be a file with a password hash, the server would load it, and validate the hash of the typed in password against the has…

You can get rid of the middleman and just sign a nonce for the site, modulo the "don't sign whatever someone gives you" caveat. If you have a PGP key that uniquely identifies you, there are many many things you can do.

Re: Introducing the Keybase filesystem

#123
post #3

Earlier quoted context omitted.

Came here to say pretty much the same thing. It's slick and easy to use. It's actually the 'dropbox' I've always wanted and if they introduce a storage limit I'd pay. https://keybase.io/jgrahamc

Hi John, mind sharing an invitation?

Sent to email in your profile.

Re: Introducing the Keybase filesystem

#126
post #2

I've been using this for a couple weeks. Along with Zcash, it is the most amazing crypto-engineering project I've seen in years. Imagine being able to share files on an ad hoc basis with anyone -- on any network. Share with someone based on Twitter, on Facebook, or email address. Even better, all with cryptographic proofs of identity, strong crypto at every level, and open source.

A bit offtopic, but what do you like about Zcash, and what's different from Bitcoin?

Zcash is an actually anonymous cryptocurrency (BitCoin is not, since senders and receivers are public). The crypto is definitely impressive (which it is, it uses zero knowledge proofs -- which are really cool math -- for a lot of its sending operations).

Re: Introducing the Keybase filesystem

#127

> 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 introd…

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.

Re: Introducing the Keybase filesystem

#130

Earlier quoted context omitted.

You don't have to, but unless someone decides to "pin" it it might just disappear at any time. So you better pin it yourself or find someone reliable to pin it for you.

> or find someone reliable to pin it for you. The Internet Archive will eventually be the "pin" of last resort.

For encrypted personal files?
Post reply on HN