About 4 years ago I was involved with a commercial software project attempting to do exactly this. What we built worked but it wasn't positioned in a way that interested our target audience (Enterprise customers).
First, bravo for making it happen in a way that is getting people excited. Second, I sincerely wish you the best luck in getting people to pay for it in a way that is sustainable for a business. We built a user interface that made truly secure group file sharing accessible to mere mortals and said mortals were uninterested.
About three months after we shut down the business Edward Snowden made his infamous leak(s) and it became obvious to me that commercial crypto products coming out of the United States would be met with extreme levels of skepticism for some time to come. Any remotely centralized solution to the problems of key distribution and encryption are probably dead on arrival because of the single point of jurisdiction/political failure. It really doesn't matter how open you are (unfortunately).
Two things really stand out to me about this implementation. 1) The trustworthiness of the key exchange doesn't appear to employ a mechanism that protects against a man in the middle. 2) They mention the possibility of in-browser Javascript crypto. These are not small issues. The people who need crypto require rigid, durable implementations that don't gloss over security concerns in favor of usability. Everyone else is just being trendy.
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.
> We're a long way off from worrying about this, but we'll
> never run an ad-supported business again. And Keybase will
> never sell data.
> [....]
> But, as stated above, there is currently no pay model, and we're not trying to make money.
> We're testing a product right now, and we'd like to bring public keys to the masses.
I know a lot of people will see this as a pro, but honestly I see it as a huge negative. Raising capital doesn't mean that you "are not trying to make money". If you are not trying to make money, then you can't call it a "product".
This is my biggest worry about using this service. It looks great, but if they don't make any money, how can they keep it running for free in the long term? They should charge users money for storage, not give it away for free - hopefully they have a plan to do so soon but they should make that clear.
It would also be nice to be able to completely self-host, that would be really reassuring, not sure if it is possible but they could certainly sell that as a service and support it for businesses interested in running their own keyserver and encrypted file store.
It's indeed a very valid point, but they are already making a huge progress and few people noticed the abrupt change. When they launched here, it was full of negative comments, many questioning how much funding they got given that the idea 'wasn't very good', some security professionals said. Now their filesystem is making such a noise and they're getting and will get more users. It's a gamble to see if they could put the commercial layer on top of it or not. That's why funding startups is risky. The good business model may not get enough users and the absent business model may get many users and could try to monetize on top of it. It's a gamble, as usual.
Except that "product" means some real result of a creative process. There's zero about the term "product" that has any reliance on any element of money inherently.
They aren't trying to make money short term. That's the kicker. I think they'll be able to monetize it later in a way that doesn't impact the average Joe.
It's a negative but not a huge negative. I, and basically anyone sane, would prefer them to have a business model we could evaluate in our minds - it's just an unknown that isn't helpful. However, it's common and we can deal with it.
It works to repeatedly append to a file on one machine and `tail -f` it on another. Even an encrypted file. It just works.
As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.
If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.
On the page it says it is "open source Go". Does that mean that, at least theoretically, I (or another independent provider) could build this and run my own personal keybase server? If so, that would really excite me. The one thing that really keeps me away from most cloud storage and sync services is lockin. I just am not willing to be come super dependent on a service that is building their business around proprietary lockin rather than providing an excellent service.
Yes it's pretty straightforward. You can even do something much simpler if you want to self-host and just want a sort of encrypted dropbox for yourself.
I recently did a little proof of concept hackathon entry (gopher gala) for a very similar idea which works with keybase.io for keys or your own server - https://sendto.click, which is also open source. This is far simpler of course but there's no reason in principle you couldn't just compile the client yourself, write your own client and use their server, or just write your own client and server, using the same golang crypto libraries, which are here for pgp:
It doesn't have to be quite as complex as the keybase tools, though I'm sure they have reasons for every decision and have thought hard about the way it all works, the crypto libraries they've based it on are open source and relatively straightforward to use.
My one hesitation about using keybase.io would be their business model and whether they'll be around in 5 years. They might have the best intentions but if it doesn't make money, and/or is bought by a large corporation, all bets are off on how the service will evolve or whether it will continue to exist. I'd love to see them start charging money and have a sustainable business model.
Maybe it's because I am not a keybase user, but can somebody explain this product in human terms? I am not an idiot, and it does sound interesting, but the post is too long and I just want to know what makes it unique compared to dropbox, etc. in one sentence.
I'm all for IPFS, but I think you're missing the forest for the trees. Crypto is hard, especially PKI. KeybaseFS is crypto first, global FS second, while IPFS just says "do crypto yourself" - which, as we've seen with email and texting and literally everything else, doesn't work.
I would love for KeybaseFS to work via IPFS instead of their own servers. But pointing at IPFS as a /replacement/ for this crypto+FS project is disingenious.
> 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?
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.
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.
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.
I would be really interested to see how they're making the filesystem cross platform if they're supporting Windows. I see in their 'hiring' page they mention FUSE which would give Linux and OS X support.
I too am very interested in if they are currently supporting Windows and/or if/when they plan to. I was hoping this blog post would have at least mentioned it in passing.
It's a public accounting of everyone's keys. All participants can review the blockchain to confirm the accuracy of their own public key. Three-letter agencies can't fork the blockchain and replace a key from the perspective of one participant.
It's not a forking attack, it's a selective-lying attack -- a malicious Keybase server could serve up old versions of someone's files, or pretend that e.g. no shared files exist between you and another user even though they do.
Putting everything into Merkle trees with published updating hashes allows clients to catch a malicious server -- if the server wants to lie to someone (without being caught), it has to lie to everyone at once.
When reading this I though, is this how the next "web" will look like!? Having the world mounted at file system level and content streamed or pushed on demand.
What about a public key block-chain where "mining" is storing and serving data!? A system with baked in hosting/browsing, identity (public key) and micro-transactions (web-money).
Unfortunately you just need to hack keybase and serve malicious code. It doesnt matter if its signed if my malicious code tells you the signature verification succeeded.
Client side needs versioned code to make this harder. Including signed, versioned javascript code, automagically.
This will also make alterations of web sites code a lot easier to detect.
Since this is a filesystem that streams data on demand, how does it behave under poor network conditions? I'm also curious how much data it caches locally, e.g. if I'm on a laptop and lose wifi for an hour, how much of the data in the keybase filesystem can I reasonably continue to access?
This is an awesome announcement and got me totally fired up.
Unfortunately, I wasn't even able to log in to my keybase account on a new computer. Judging from the 1,000 outstanding issues on their Github, it seems like Keybase should first be focusing on fixing the bugs in existing software before rolling out new products. [0]
As for the substance of the filesystem, it would be nice to have some concept of named/shared groups. So I could create a "company" folder and then add people to it over time instead of having to create a whole new shared folder each time we add someone new. (And having to manually copy over all relevant files.)
I hate begging but I've been in the keybase queue for at least a year and would like to finally see what it's all about. I'd appreciate it a ton if someone could shoot me an invite: [removed] Thank you very much ashishchaudhary! :)
[+] [-] ary|10 years ago|reply
First, bravo for making it happen in a way that is getting people excited. Second, I sincerely wish you the best luck in getting people to pay for it in a way that is sustainable for a business. We built a user interface that made truly secure group file sharing accessible to mere mortals and said mortals were uninterested.
About three months after we shut down the business Edward Snowden made his infamous leak(s) and it became obvious to me that commercial crypto products coming out of the United States would be met with extreme levels of skepticism for some time to come. Any remotely centralized solution to the problems of key distribution and encryption are probably dead on arrival because of the single point of jurisdiction/political failure. It really doesn't matter how open you are (unfortunately).
Two things really stand out to me about this implementation. 1) The trustworthiness of the key exchange doesn't appear to employ a mechanism that protects against a man in the middle. 2) They mention the possibility of in-browser Javascript crypto. These are not small issues. The people who need crypto require rigid, durable implementations that don't gloss over security concerns in favor of usability. Everyone else is just being trendy.
I wish you the best of luck.
[+] [-] rdl|10 years ago|reply
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.
[+] [-] rburhum|10 years ago|reply
> We're a long way off from worrying about this, but we'll > never run an ad-supported business again. And Keybase will > never sell data. > [....] > But, as stated above, there is currently no pay model, and we're not trying to make money. > We're testing a product right now, and we'd like to bring public keys to the masses.
I know a lot of people will see this as a pro, but honestly I see it as a huge negative. Raising capital doesn't mean that you "are not trying to make money". If you are not trying to make money, then you can't call it a "product".
[+] [-] grey-area|10 years ago|reply
It would also be nice to be able to completely self-host, that would be really reassuring, not sure if it is possible but they could certainly sell that as a service and support it for businesses interested in running their own keyserver and encrypted file store.
[+] [-] andersonmvd|10 years ago|reply
[+] [-] quadrangle|10 years ago|reply
[+] [-] swsieber|10 years ago|reply
[+] [-] javajosh|10 years ago|reply
[+] [-] tomasien|10 years ago|reply
[+] [-] sjs382|10 years ago|reply
[+] [-] malgorithms|10 years ago|reply
As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.
If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.
[+] [-] akenn|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] zmmmmm|10 years ago|reply
[+] [-] grey-area|10 years ago|reply
I recently did a little proof of concept hackathon entry (gopher gala) for a very similar idea which works with keybase.io for keys or your own server - https://sendto.click, which is also open source. This is far simpler of course but there's no reason in principle you couldn't just compile the client yourself, write your own client and use their server, or just write your own client and server, using the same golang crypto libraries, which are here for pgp:
https://godoc.org/golang.org/x/crypto/openpgp
It doesn't have to be quite as complex as the keybase tools, though I'm sure they have reasons for every decision and have thought hard about the way it all works, the crypto libraries they've based it on are open source and relatively straightforward to use.
My one hesitation about using keybase.io would be their business model and whether they'll be around in 5 years. They might have the best intentions but if it doesn't make money, and/or is bought by a large corporation, all bets are off on how the service will evolve or whether it will continue to exist. I'd love to see them start charging money and have a sustainable business model.
[+] [-] ptman|10 years ago|reply
[+] [-] volaski|10 years ago|reply
[+] [-] lisper|10 years ago|reply
[+] [-] manyoso|10 years ago|reply
How about something completely decentralized, but permanent:
https://ipfs.io/
https://youtu.be/HUVmypx9HGI
The InterPlanetary File System (IPFS)
[+] [-] hatsunearu|10 years ago|reply
- You still have to host yourself, since you don't get free hosting.
- Not encrypted, so you gotta add the encryption in yourself.
[+] [-] chc4|10 years ago|reply
I would love for KeybaseFS to work via IPFS instead of their own servers. But pointing at IPFS as a /replacement/ for this crypto+FS project is disingenious.
[+] [-] jrockway|10 years ago|reply
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?
[+] [-] lkowalcz|10 years ago|reply
Keybase doesn't have my private key (only I do), so they can't re-encrypt the contents.
(sorry if I misunderstood your question)
[+] [-] chc4|10 years ago|reply
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.
[+] [-] cbhl|10 years ago|reply
[+] [-] ryan-c|10 years ago|reply
[+] [-] WorldMaker|10 years ago|reply
[+] [-] sjs382|10 years ago|reply
https://akenn.keybase.pub/index.html (not mine)
[+] [-] akenn|10 years ago|reply
[+] [-] davepeck|10 years ago|reply
[+] [-] mdavidn|10 years ago|reply
[+] [-] cjbprime|10 years ago|reply
Putting everything into Merkle trees with published updating hashes allows clients to catch a malicious server -- if the server wants to lie to someone (without being caught), it has to lie to everyone at once.
[+] [-] thomasfromcdnjs|10 years ago|reply
It has a link at the bottom -> "latest download (possibly without the filesystem)"
I'm guessing that means not all of the OS builds have it enabled yet?
[+] [-] preya2k|10 years ago|reply
[+] [-] flashm|10 years ago|reply
[+] [-] z3t4|10 years ago|reply
What about a public key block-chain where "mining" is storing and serving data!? A system with baked in hosting/browsing, identity (public key) and micro-transactions (web-money).
[+] [-] patcon|10 years ago|reply
* https://ipfs.io/
* https://ethereum.org/
* IPFS project lead interviewed at Ethereum conference: https://www.youtube.com/watch?v=t7VjUKCdfpg
[+] [-] OJFord|10 years ago|reply
Show HN: Signed Blogs with Keybase.io file system [1]
It's ugly as anything (no stylesheet), but just wanted to demonstrate what I think could be an interesting use.
[1](https://news.ycombinator.com/item?id=11039145)
[+] [-] zobzu|10 years ago|reply
Client side needs versioned code to make this harder. Including signed, versioned javascript code, automagically.
This will also make alterations of web sites code a lot easier to detect.
[+] [-] fsargent|10 years ago|reply
You can now write data in a very special place: /keybase/public/fsargent
Very cool.
[+] [-] StavrosK|10 years ago|reply
[+] [-] eridius|10 years ago|reply
Since this is a filesystem that streams data on demand, how does it behave under poor network conditions? I'm also curious how much data it caches locally, e.g. if I'm on a laptop and lose wifi for an hour, how much of the data in the keybase filesystem can I reasonably continue to access?
[+] [-] morgante|10 years ago|reply
Unfortunately, I wasn't even able to log in to my keybase account on a new computer. Judging from the 1,000 outstanding issues on their Github, it seems like Keybase should first be focusing on fixing the bugs in existing software before rolling out new products. [0]
As for the substance of the filesystem, it would be nice to have some concept of named/shared groups. So I could create a "company" folder and then add people to it over time instead of having to create a whole new shared folder each time we add someone new. (And having to manually copy over all relevant files.)
[0] https://github.com/keybase/keybase-issues/issues
[+] [-] vmp|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] salimmadjd|10 years ago|reply
[+] [-] joefkelley|10 years ago|reply
Or is it only available to a limited set of users?
I see there's a "keybase fuse" command that might be related, but there's no docs for how to use it.
[+] [-] a_bonobo|10 years ago|reply