Introducing the Keybase filesystem
keybase.io
keybase.io
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.
https://keybase.io/docs/server_security https://keybase.io/docs/sigchain
They do specifically mention the problem of javascript crypto. They also mention the fact they want to be mirrored.
That said, I don't actually know enough to make smart decisions in this space. But I'd be interested in your thoughts after reading the docs (if you haven't already).
First of all, you don't have to use the browser app at all. I personally don't trust Javascript crypto and hence don't do anything in the web app.
They're also acutely aware of the dangers of centralization and all the Keybase crypto is based on minimal trust. Check the documentation: https://keybase.io/docs/server_security
P.S. If anyone wants an invite then details are in my profile.
I'd be happy to go with something that has more crypto than Dropbox but stop short of full tinfoil hat. Consider FileVault on Mac OS. You flip the switch and you're done. If someone steals your laptop they are unlikely to be able to access your files. Win. Will it stop a dedicated hacker or NSA (or even a court order compelling you to decrypt your computer)? Nope.
Could someone with more expertise explain how Keybase protects against MitM attacks please? Does it simply rely on the difficulty of compromising the SSL certs of multiple assertions (twitter.com, github.com, etc)?
As far as I can tell, if someone was able to 'pretend' to be Twitter, ie, MitM an HTTPS connection to twitter.com, they could 'pretend' to be someone who only has their Keybase info on Twitter. Of course, putting your key data in more places makes it harder to appear as you.
2) In Keybase, if you 'track' someone, you sign the assertions they've made as of today. So in the future you (or anyone else -- tracking is public) can detect if those assertions have changed since you first started tracking them.
Thanks!
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.
>There is no paid upgrade currently. The 10GB free accounts will stay free, but we'll likely offer paid storage for people who want to store more data.
Or are you saying you prefer the command line interface?
Edit to add link to EFF ratings: https://www.eff.org/who-has-your-back-government-data-reques...
tarsnap is nerdish, secure and reasonably priced for what it provides IIRC. Haven't used it though but expect someone would have yelled out here if it was bad. (In fact the only one I've seen bashing it was patio11, -because it was too cheap and too nerdish.)
Dropbox was listed on PRISM documents. Are you kidding me?
Additionally, creating an easy way to share files with friends without taking up their quota is awesome. This looks like it could be a very, very powerful competitor to Dropbox.
But they've since moved away from that in favor of Dropbox-style selective sync for reasons that didn't seem very convincing to me. [1]
[1] http://arstechnica.com/information-technology/2014/11/onedri...
That said, my point is more that for people who start storing 100GB+ of data, it becomes harder and harder to actually manage which bits you want at any time.
Thank you so much and congratulations on the release!
(email in profile)
Best of luck with this thing you're building. I haven't been excited about any tech stuff in ages. This is really cool.
Which makes sense, of course, since Keybase is a funded startup that needs to capture value... and, well, centralized file sharing is a more straightforward solution, too.
The file system thing seems really cool and useful. I'm a fan of Keybase and will recommend this to people with whom I need to share sensitive data.
It'd be interesting to hear the Keybase people talk openly about how they see their role as both infrastructure providers for an open web of trust, and an economic entity that requires for its survival some degree of lock-in and centralization.
As an infrastructure provider, they open source the client software and design it to trust the server as little as possible. They also endeavor to document the behavior of the server so that, in theory, you could build your own Keybase-compatible server.
As an economic entity, they're positioned to tackle the issues that open source projects usually face, like support, development resources, UI design resources, and "where do you put all of this encrypted data" by getting their most needy users (mostly businesses) to pay them.
I mean, if I want to do some Torrent like P2P stuff, I need to...
- gather public keys of all the people who want to download from me
- encrypt every chunk for every person separately
By the way, how did you manage to install Keybase FS? It won't work for me at all.
EDIT: Still doesn't work, unfortunately. I get the /keybase dir, but it's empty.
Have you read about Monero or Bitcoin + Coinjoin + Joinmarket?
> 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".
( http://www.merriam-webster.com/dictionary/product )
There's another sense (not listed) in which "product" specifically refers to prohibited drugs. I know, and you should know, that quadrangle wasn't using that sense. As regards the point being disputed, rburhum is plainly wrong to say "If you are not trying to make money, then you can't call it a 'product'", and quadrangle is completely correct to call him on it. You can call anything produced a "product". That is the meaning of "product".
The bit rburhum objected to says "We're not trying to make money. We're testing a product right now." This is correct idiomatic use of the word "product" (in the sense "something we make"), and it's a relevant answer ("we don't have one") to the question "what is your business model?".
You could, however, say you are testing a product. Which is probably how users should treat startups that don't know how they'll make money yet -- as a product in testing.
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.
Read your messages: tail -f /keybase/private/yourname/inbox.log
Send a message to someone: echo 'Hi, friend!' >> /keybase/private/yourfriend/inbox.log
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.
I'm not sure what to expect though. Does it rename subsequent files by appending _##? Or does it overwrite? Or does it allow 2 files with identical filenames, like Google Drive (at least on the web) does?
The conflict resolution Keybase does do is simple and much like what Dropbox does. The clients will determine a winner, and the loser will be written as something like `Keybase Logo.conflicted (sjs382's imac5k copy 2016-02-04).psd` Note in this case 'imac5k' is a guaranteed unique device name for sjs382, due to the way our merkle tree of key announcements works.
By the way, the conflict resolution of a single file is one case in a fairly large list of possible conflicts. What happens if you remove a directory on one machine, but add a file to it on another? And so on. The conflict resolution flow is designed to protect you from data loss above all else.
Thanks for the answers and thanks for the awesome kbpgp.js!
KBUSER=`keybase status | grep Username | awk '{print $NF}'`;
function say() { echo "$KBUSER: $@" >> /keybase/private/shared,folder,between,multiple,users/chat.txt }
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.
Agreed that they need to work on the narrative a bit.
As a benefit, it's much simpler to implement - you don't need to work as hard to handle conflicts where two people made incompatible changes while offline. However, it will be slower for bulk operations and will require an internet connection.
Unfortunately the FUSE model isn't as simple to implement as it might seem. For performance reasons we're going to have to accept writes locally and push to the server in the background, which means all the same conflict resolution logic needs to be there. (In our case "there" means the client; the server can't help us, because it doesn't have any keys.) It's not clear exactly how much we'll be able to do for you without an internet connection, but the files you've read recently at least will need to stay in cache somehow. Fun times :)
In my interpretation, files are stored on keybase servers.
Is that correct? I agree that the "sync" sentence in the article is confusing and maybe a bit misleading.
How about something completely decentralized, but permanent:
The InterPlanetary File System (IPFS)
- You still have to host yourself, since you don't get free hosting.
- Not encrypted, so you gotta add the encryption in yourself.
https://youtu.be/HUVmypx9HGI?t=3210
And you do not have to host yourself once your content is distributed. That is what makes it permanent!
The Internet Archive will eventually be the "pin" of last resort.
For public files, I hope that there will be several organizations organizing multiple long-term pins of files.
Home users with enough bandwidth and storage. Existing CDNs. New cloud storage entrants (Backblaze).
Literally anyone with an internet connection and storage would be able to securely serve your content.
EDIT: I just saw your profile :) Thanks for the work you do at the IA!
Decentralized simply gives you the additional option to host it yourself. It also does not preclude free hosting.
Example: email.
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.
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?
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.
US laws have broken the internet.
tldr; this isn't for the NSA adversary model
Keybase doesn't have my private key (only I do), so they can't re-encrypt the contents.
(sorry if I misunderstood your question)
I imagine the later isn't impossibly complex, but would require slick engineering to get over the barrier of expectations most people have.
I wonder how hard it would be to use the NTFS pseudo-files that OneDrive used in Windows 8.1 (and abandoned in Windows 10 for being "too confusing to the average user")?
There's always the ability to use a SAMBA server variant and be a network share. Still a lot of dumb Windows apps that fail on network shares, but most of those are long in the tooth and should be retired anyway (and the tried and true Map Network Drive is still a power user workaround).
It looks like one application I use (JungleDisk) is somehow faking a removable drive (such as USB). I'm curious how they've built that.
https://akenn.keybase.pub/index.html (not mine)
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.
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?
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).
* IPFS project lead interviewed at Ethereum conference: https://www.youtube.com/watch?v=t7VjUKCdfpg
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.
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.
You can now write data in a very special place: /keybase/public/fsargent
Very cool.
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?
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.)
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.
The former should be good - that sounds like a smart client in front of a dumb server. The latter is a different problem and as far as I'm aware the service is merely aggregating proves - and can link to those. Verify them?
Good luck getting people to do that.
Edit: I guess if the audience for this is technical people, then the kind of person who follows them is likely to be the kind that would download it, but that's a very small market. There's a far greater barrier to getting people to install software (with little tangible gain) than getting them to sign up for your website.
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 hash I provide, once the login is successful it would remove this file
this would basically mean that I could have single-use passwords for any site as it would be trivial to have a browser add-on that generates a random password and corresponding hash when I want to log in somewhere, it types the password in the password field on the page and puts the hash in the keybase directory corresponding to it, and alert me if the site does not remove the file after the login.
The approach you detailed is the way to go once the filesystem is in the wild. Such power!
So, reply to me here or email me (wanda {at} teknik.io) and I will send you an invite. First co-- actually, first noticed, first served.
FAO: "AY" (full name omitted)
I'm sorry, I ran out before
I could get an invite to you.Please either reply with an email address or have one visible in your profile if you want one.
Edit: Thanks a lot for the invite !
KBFS:
status: not running
Anyone?
https://keybase.io/simonjgreen
EDIT: all gone for now, but see https://news.ycombinator.com/item?id=11037629 for more
robinlambertz+dev at gmail
Edit: brennan at umanwizard dot com
EDIT: All gone.
Edit: Got it. Thanks!
Thanks in advance!
(I've updated to my profile to actually include my email now.)
WOW: That happened fast, I'm all out of invites now... 2 minutes after posting emails started coming in and within 3 minutes I was out. Sorry if you didn't get one...
Edit: All out. I you got one from me, please use it within 24 hours, otherwise I will reclaim it and give it to someone else.
I'll delete this comment once I get one.
Thanks!
Many thanks!
hn@cinigl.io
Put myself in the alpha queue this morning. I'll look forward to testing it out.
keybase pgp updateEmail in my profile :)
jlu@twmug.com
tomkinsc@[google's consumer email service].com
My email address is visible on my profile.
Thanks in advance to the HN community!
> My email address is visible on my profile
If that's the wrong email then let me know where to send it.
Edit: Got it. Thanks!
I'd love to give Keybase a spin as well! =)
(Email is in my profile)
Edit: GOT IT, thanks!
What can you provided over and above yubikey?