Introducing the Keybase filesystem
keybase.io
keybase.io
To list a few points:
* No application preferences, so no obvious place from which to disable KBFS. Even though I never use it, it somehow idles at 160MB memory, and after each restart it adds itself to the top of my Favorites on Finder!
* Between the Electron app and Keybase services, another 360MB of memory gets used. In total that's 520MB, which is a fairly large amount of memory for a laptop with only 8GB.
* Quirky menu bar behavior which doesn't match macOS design guidelines.
* No option to disable automatic updates, or even reduce the check's frequency. Currently, it runs every hour, even though they can go weeks without a release!
They're trying to do way too much with a single app, desktop apps are usually more granular. You could break it up into three or four apps:
* Core. Includes account, device manager, identity proofs, and CLI tools.
* Chat. Includes contacts and people search. Heck, you could even offer to scan the user's contact list or keyring for matches on Keybase.
* KBFS. A menu item app with a preferences view. Functionality should probagbly be implemented as a Finder Sync Extension [0].
[0] https://developer.apple.com/library/content/documentation/Ge...
Why is this a problem? Is the check heavy somehow? An hour between quick checks sounds like a reasonable interval for a security-sensitive app.
I reported it [0] for Windows few months ago, and not a reply :(
I do not want Keybase to hoard encrypted messages I will never be able to read because I do not want to install their application on my computer. My Github issue for this has gone largely ignored:
https://github.com/keybase/keybase-issues/issues/2808
I am thinking I am long overdue to placeholder my account until this is solved. I already have 10 encrypted messages I will never be able to read. I joined Keybase as a public key repository with external verification support, not for them to store private conversations -- encrypted or not.
While I agree with your comments on feature-creep, in order for you to worry about someone having a copy of your encrypted communications you must assume that the encryption scheme is completely broken. This raises the question: why are you using PGP at all if you think the cryptography is broken?
The cryptography is almost certainly not broken. That does not mean it won't be broken in the future. I would have the same concern if my TLS-encrypted traffic was being saved. If my ISP was saving TLS traffic or my XMPP provider (the one that I don't host, anyway) was saving OTR conversations, I would be equally concerned.
Even worse, actually. TLS (usually, nowadays) and OTR both employ forward secrecy. PGP does not, at least traditionally.
The other cool thing about upspin is the ability for anyone to spin up their own server infrastructure for storage. I can imagine a service offering an on-premise secure Dropbox to paranoid big companies. I'm not sure if you can deploy a private Keybase, though their client code at least is open source.
Actually you can!
Check out `/keybase/private/songgao#ereyes01@hackernews/hi` and try writing to that folder :)
EDIT: typo and missing quote
... section "The Keybase namespace"
On the other hand, it doesn't feature forward secrecy.
(by signal public key I mean that your safety number with any given person is always a concatenation of a string that identifies you and a string that identifies them and you'll find that same string across your safety numbers with all your contacts)
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.
It's pretty nebulous, but at least they are saying the right things while saying nothing... :)
I use a GnuPG "smartcard" (a yubikey) so I'm certain that keybase has no direct access to my private key.
So I've tried "echo test > /keybase/private/simias/secret.txt"
So far it seems to work, the file is here and I can read it.
Then I shutdown keybase, make sure nothing is running and /keybase is unmounted, remove my yubikey and run_keybase again:
cat /keybase/private/simias/secret.txt
test
e.g. you can see I used my GPG key to sign all of my proofs (proving identity), and to also sign my keybase keys which then have signed other keybase keys:
https://keybase.io/travisby/graph
We can view yours at https://keybase.io/simias/graph .
Your device still has worked-key on it which is decrypting secret.txt for you.
But then the problem that I have with that is this worked-key is a lot less secure than my PGP key on a hardware token. What I'd like would be for keybase to make those keys depend on my PGP key, for instance by decrypting them at the beginning of each session.
I'm not sure I get the point of these device keys to be honest. Why not simply generate a new key every time one is needed, and then sign and encrypt it with my PGP key?
After all that's basically how basic PGP encryption works, it's encrypted with some symmetric cipher using a random key and then this key is encrypted with the assymetric cipher (sever times if there are several recipients). Nobody has to worry about those "intermediate" throw-away keys, they're just stored alongside the ciphertext.
If anything it seems more complicated than what I'm proposing. People who don't use crypto will probably let keybase manage their private keys (at least at first) so this could be handled transparently.
I mean, you could turn it the other way around. If this system is confusing and unintuitive for somebody like me who is familiar with the details of asymmetric cryptography, how are less technical users supposed to figure it out and understand the trust model?
I doubt the average person on the street would understand what https://keybase.io/travisby/graph means.
I don't have any issues with using sub-keys, it's a very good idea actually, for the reason you mention. I just wish I had the option to tell keybase "never store those keys in cleartext, always encrypt them with the master key". Then it would ask be to decrypt the keys on startup and everybody would be happy (well, at least I would be).
I have since emailed support, and they clarified that they don't support yubikeys as the auth layer since there aren't enough users with them for them to justify this work, which is understandable, but I have to say it was pretty confusing.
If this is valuable, they think 10GB is enough to test the fundamental premise and see people hit the edges of what they'd want to pay for.
There might be a segment of the market for whom this is worth vastly more than $5 / month. There might be a segment who wants to pay that little, but it's not about storage. They may not learn these things by priming people on a per-GB storage model.
It's not reliable for storing customer data, no. But it's quite useful for a lot of quick engineering work.
I also failed to mention that having an internal namespace for an organization may be relevant. People may not want to be public.
And, are you suggesting that a corporate process has to rely on technology that is always available? I'm fairly sure that they don't. If corporate Wi-Fi and Microsoft Office are any indication, anyways.
Please excuse any punctuation or capitalization today. I am training a new interface to Hacker News and the voice recognition sometimes produces slightly odd text.
I get that they don't implement forward secrecy. I gather that forward secrecy would break the GnuPG model, in that stuff couldn't be decrypted on any device with the requisite key pair.
No, they have their own key and encryption scheme (called saltpack), which is - to best of my knowledge - is not compatible with GnuPG.
I'd wish they have made it compatible with modern GnuPG, making it possible to transform the container format for keys and messages (I'm not sure it's possible for messages, but certainly must be possible for the keys). Sadly, it's not.
But still, it is GnuPG authenticated, I think. Because the account is tied to both a GnuPG key and the Keybase container encryption.
Also, they'd have to do it as you sign up. Once your profile is active and you've followed people and their signatures are cached on your local computer, the root CAs are no longer the single point of failure and MITM'ing becomes impractical.
That said, if a state, especially the one you're in, targets you personally, you're going to have a bad time.
Instead of private and distributed trust, we got public and centralized. No thank you.
EDIT: In fact look, from their /docs/server_security they have this:
> Here are the attacks we are most concerned about:
> Server DDOS'ed
> Server compromised; attacker corrupts server-side code and keys to send bad data to clients
> Server compromised; attacker distributes corrupted client-side code
Why would I want my GPG security to depend on whether some company got hacked or not? This seems like a terrible idea.
What does that mean? Do I need to wait every time I use the same file again?
If you have sufficient local space and use KBFS only on a single machine, then you'll never wait. If you modify a file every time you open it, and do so on alternate machines, you'll wait every time.
It's a bit disturbing to see them act like so many other sites that are pushing something you just don't need. Also, after asking them on Twitter about this, I didn't get a reply - for an organisation who's all about identity, this isn't a great sign.
▶ ERROR failed to open chat conversation: KBFS client wasn't found
You probably installed via instructions at https://keybase.io/docs/the_app/install_linux which will get you 1.0.27.
The official arch package is stuck on 1.0.22 waiting for you to make a tag on github.
Security-wise, you could verify our signature on the .deb package that aur/keybase-bin is downloading. The Linux install instructions describe where to find the sigs.
https://news.ycombinator.com/newswelcome.html
https://news.ycombinator.com/newswelcome.html
I'm not a mod, but three out of your five comments contain the word "shit," and one of the five was flagged. HN has a lot to offer, but only if you put effort into it.
EDIT: Just to clarify, it's fine to call out something as bullshit, but you have to justify your reasoning. Ideally it wouldn't be so emotional, but an informative comment is valuable regardless of the clothes it wears. E.g. if you dig into the ToS and highlight clauses that illustrate why it's bullshit, that would be useful.