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.
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.
>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.
Dropbox works with the NSA to hand over customer data. You are absolutely right that something like this would go over like a turd in a punchbowl at Dropbox HQ.
Unlike Google, Microsoft and Slack, Dropbox does have the top, 5 star, EFF rating for protecting your data from the government... I'm not sure what more they could be doing.
Then use tarsnap already. Bonus: it is owned by our own cperciva.
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.)
Their profitability depends on being able to dedupe and compress data across all customers. They would need to raise prices significantly to make client side encryption a built in feature.
What's also impressive is doing away with Dropbox's clunky "selective sync". While having everything stored locally sounds like a good idea at first, as you store more and more data is gets less and less user-friendly; in other words, power-users get the worst user experience.
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.
Not storing files locally sounds like a good idea at first - you don't have any syncing issues. But nobody has a perfect always-on internet connection. Having files local is worth the occasional sync cockup.
Oh for sure there's a reason that approach is dropbox's default - its really hard for people to understand their files aren't really "there".
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.
I don't think it's distributed in the IPFS fashion, right?
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.
Well, what I'm hoping for from Keybase is enough user friendly tooling to encourage a lot of people to start using public-key cryptography. I don't see IPFS as really addressing any of that, even though it is extremely cool and valuable in other ways.
IPFS alone is usable for the public web, but is not usable for private sharing. You need a social identity-oriented public key infrastructure with a good UI. That is Keybase, and it's incredible that we have this now. Sure, we should implement an IPFS backend for the storage part. But let's not neglect the huge progress the Keybase folks have given us.
I love the ideas behind IPFS, but it isn't even trying to solve the same problems as KeyBase, so comparing them like this is very silly. Users may be able to benefit from both in different ways, or even use parts of the two together in the future.
I'm not speaking for Keybase, but their approach so far is to fill these roles in compatible ways.
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.
The second part is usually handled by encrypting a randomly chosen symmetric cipher key using each public key, and then encrypting the file with a symmetric cipher. And I believe keybase was founded to tackle the first problem.
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).
I managed to find the prerelease packages in the build scripts, and got it working through that. Make sure you restart the keybase service, as it doesn't happen automatically
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.
We are testing a build for Windows that uses Dokan. Early results have been very positive. It's an important feature of KBFS that it can run on Windows.
Hi Chris, the very first versions of Boxcryptor for Windows some years ago also used Dokan. Our experiences have been really bad and as the user base grew so did the number BSOD reports caused by Dokan (v0.6 back then). We are now using the commercial driver CBFS since 3+ years and are really happy with it. Hint: As development at Dokan has picked up again with Dokany, I don't know anything about its current stability.
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")?
Also, it's a terrible Plan B, but it's still a Plan B to keep in mind: Windows still has semi-adequate WebDAV views in Explorer. OneDrive for Business is still WebDAV-based for instance. (I've also seen and used several backup and NAS tools that have relied on WebDAV.)
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.
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.
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.
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.
> As for collisions, a "conflict" is handled as you would expect on file syncing services
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?
Oh I see, sorry for not fully answering. Keybase does not merge files or anything source-control like that. In fact, if that's what you want, you can actually init a bare repo inside of Keybase and clone into and out of it. We do this all the time as we're dogfooding. It's cool that every push is signed automatically, and every pull or clone is verified.
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.
I've got invites (9) for Keybase that are collecting dust if anyone wants one. Email in profile.
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...
>If that person hasn't installed Keybase yet, your human work is still done. They can join and access the data within seconds
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.
That does not work - I have to log in with the command line client, which fails because I it doesn't have GPG sign with the correct key. Edit: Managed to get it to work by restoring a backed up keyring from before I updated my keys.
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.
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).
I don't think Keybase is glossing over security at all.
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
Personally, I don't want someone else storing my private keys; which is a pre-condition for doing anything you'd have to worry about in the browser anyway.
So do I - that was my point to parent: I don't use the browser tools not because of JS (which is a concern) but because of not wanting private keys stored online which would be required to do so.
I think they know what they're doing. The article seems pretty thorough and they're open to feedback. It looks like they've thought of most things but are still able to keep it usable, engaging and at times even humorous (https://keybase.pub/chris/lemon_party.jpg). These are things often missing from security products.
P.S. If anyone wants an invite then details are in my profile.
I think it's more than just being trendy; there's a range of security needs to be considered.
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.
1) MitM on TLS requires being able to issue trusted certificates for any domain. That means you either own an already trusted certificate (which basically means you're a state-level actor), or you can install a certificate on the victim's device (which means you have physical access/ownership of the device). It's also detectable through certificate pinning.
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.
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 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.
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.
"Centralised Crypto" in what sense? Unless I'm very much mistaken, your private key never leaves your control - signing/encryption is done client-side.
Are you talking about the announced file storage service here? Or about the "drudru claims to be foobar on Twitter" service?
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?
The entire system is architected so that you don't need to trust them for anything, beyond the trust you generally need to have in open-source developers. What is a specific scenario that concerns you?
One _can_ host their private key(s) on Keybase (you need to to use in-browser tools) but you don't have to; can instead use Keybase cli, or gpg directly.
Wasn't keybase started due to a problem snowden had? He couldn't easily verify the GPG key of a journalist? They even resorted to tweeting the public key fingerprint to verify: https://twitter.com/micahflee/status/296119710485979136
500 comments
[ 2.2 ms ] story [ 197 ms ] threadImagine 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.
https://keybase.io/jgrahamc
>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?
https://www.dropbox.com/en/help/28
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.
https://ipfs.io
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.
https://s3.amazonaws.com/prerelease.keybase.io/index.html
EDIT: Still doesn't work, unfortunately. I get the /keybase dir, but it's empty.
Have you read about Monero or Bitcoin + Coinjoin + Joinmarket?
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.
You can now write data in a very special place: /keybase/public/fsargent
Very cool.
How about something completely decentralized, but permanent:
https://ipfs.io/
https://youtu.be/HUVmypx9HGI
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.
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!
What can you provided over and above yubikey?
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!
Edit: Got it. Thanks!
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.
https://akenn.keybase.pub/index.html (not mine)
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.
https://s3.amazonaws.com/prerelease.keybase.io/index.html
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!
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!
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?
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?