I'm a big fan of what Keybase is doing, but I've avoided installing it on my newest computer because I'm unhappy with their client.
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].
> 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!
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.
What bugs me about the direction Keybase is going is that they still have not implemented a way of disabling the ability for users to send me encrypted messages.
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:
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.
> 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?
People could just post these encrypted messages on pastebin, Dropbox, whatever. It's someone else's choice to send you the message and paste it somewhere. You can choose to ignore it, but it's not really your right to tell someone else not to do it.
As a casual user who has occasionally used
Keybase for sharing work-related sensitive things, it will be interesting to see how KBFS vs. upspin plays out. As far as E2E encrypted file storage goes, the two seem to offer very similar abilities. Obviously, Keybase's other services offer more in the way of messaging and user social proof. I also like the way you can privately share things with individuals using the directory names, vs. the ACL file in upspin, though I guess that allows read-only sharing and a stronger concept of ownership... you can't do that for shared private files in KBFS right?
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.
Yeah it's not new. The chat feature has existed for a short while, too, which deserves more fame as being an e2e encrypted multi-device IM system that isn't tied to your phone number.
I realize keybase has raised a lot of money but can someone clarify how they plan to make money other than make "cool" stuff that only highly technical engineers understand?
It is a good question, but no, I don't think anybody will be able to tell you more than what's in the "Business Model?" section of the article:
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.
They say they won't sell ads or data, and however they make money will be from organizational users with a goal to provide a useful free tier that can be used by every person in the world. I assume that means that in addition to staying free, it will get easier to understand over time.
It's pretty nebulous, but at least they are saying the right things while saying nothing... :)
keybase uses your gpg key more as a _bootstrap_ to prove your identity, and to then sign your _keybase key_ (which isn't gpg as far as I could tell from the spec).
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:
I was very confused about this as well. I setup an account on my computer a few weeks ago with my yubikey, and since then I have reset my computer, so I decided to install keybase again. Unfortunately it asked for me to approve the new device from an existing one, and didn't offer the option to use my yubikey instead.
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.
This looks really cool. I'm a little concerned that "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." What's the harm in charging $5/month for 50GB as a beta service that might not last forever to help fund development? Maybe even keep the same level but allow people to pledge monthly to support your efforts? It just always seems to be the case that there's a lot of runway until there isn't. Building a product and making money are not mutually exclusive.
The harm is that $5 / month for 50GB is the wrong model.
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.
I've come to love Keybase. I can be chatting with someone, and decide to share a file. So I just create a shared private folder, and copy the file there. All GnuPG authenticated and end-to-end encrypted.
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.
I just used keybase fs the other day to send someone a draft of a book I'm working on, with nothing but our reply chain on HN as a starting point. It's like you're just one `cp` away from anyone who uses keybase!
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.
I'm interested in this as a technical solution, but I'm not sure what content I actually expect to share or see shared on Keybase. Public dropbox links work pretty well for me right now for "ordinary" files.
I've always wondered, is there a possibility for a state MITM if they manage to control the root-signing authorities? Can't they always replace it with their own signed certificate?
As I understood it, they'd have to MITM both Keybase.io and every single one of the websites where a given user verifies their identity (and then there's certificate pinning which I would assume the Keybase client would know about and respect, but then again if your download of the client was compromised ..). Not impossible, but there's a lot of logistics to get right.
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.
I don't know much about crypto, but this argument seems extremely compelling to me. Why would I want my network of trust to be public or centralized? Can someone more knowledgeable comment on whether parent is making sense?
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.
Anecdotally, it seems that new files (or new revisions) are downloaded on first use.
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.
I've slightly lost confidence in Keybase recently, since logging on after a while and discovering that they're _heavily_ promoting their app.
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.
You can verify to keybase by posting a hash using the "about" field in your user page on HN. Simply making a comment is insufficient. The details of what to do are available at keybase.
We don't use GitHub releases for our official packages. Instead (if you're on Linux) we publish Debian/RPM/Arch packages that update automatically through your system package manager. See the install instructions here: https://keybase.io/docs/the_app/install_linux
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.
[+] [-] TheAceOfHearts|8 years ago|reply
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...
[+] [-] vfaronov|8 years ago|reply
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.
[+] [-] rdslw|8 years ago|reply
I reported it [0] for Windows few months ago, and not a reply :(
[0] https://github.com/keybase/client/issues/6541
[+] [-] bascule|8 years ago|reply
[+] [-] gexcolo|8 years ago|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.
[+] [-] cyphar|8 years ago|reply
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?
[+] [-] beaner|8 years ago|reply
[+] [-] ereyes01|8 years ago|reply
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.
[+] [-] songgao|8 years ago|reply
Actually you can!
Check out `/keybase/private/songgao#ereyes01@hackernews/hi` and try writing to that folder :)
EDIT: typo and missing quote
[+] [-] johnhenry|8 years ago|reply
[+] [-] amingilani|8 years ago|reply
[+] [-] LeoPanthera|8 years ago|reply
[+] [-] the_common_man|8 years ago|reply
[+] [-] veidr|8 years ago|reply
It's pretty nebulous, but at least they are saying the right things while saying nothing... :)
[+] [-] simias|8 years ago|reply
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:
So, what am I missing?[+] [-] travisby|8 years ago|reply
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.
[+] [-] xur17|8 years ago|reply
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.
[+] [-] film42|8 years ago|reply
[+] [-] trjordan|8 years ago|reply
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.
[+] [-] mirimir|8 years ago|reply
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.
[+] [-] j2kun|8 years ago|reply
[+] [-] drdaeman|8 years ago|reply
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.
[+] [-] paulgerhardt|8 years ago|reply
[+] [-] akanet|8 years ago|reply
[+] [-] amingilani|8 years ago|reply
[+] [-] rubatuga|8 years ago|reply
[+] [-] mseebach|8 years ago|reply
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.
[+] [-] tnone|8 years ago|reply
Instead of private and distributed trust, we got public and centralized. No thank you.
[+] [-] fwdpropaganda|8 years ago|reply
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.
[+] [-] amelius|8 years ago|reply
What does that mean? Do I need to wait every time I use the same file again?
[+] [-] OJFord|8 years ago|reply
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.
[+] [-] arethuza|8 years ago|reply
[+] [-] pgl|8 years ago|reply
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.
[+] [-] griko|8 years ago|reply
[deleted]
[+] [-] abiox|8 years ago|reply
[+] [-] rainforestqa|8 years ago|reply
[+] [-] ajarmst|8 years ago|reply
[+] [-] ukd1|8 years ago|reply
[deleted]
[+] [-] daurnimator|8 years ago|reply
[+] [-] AlphaWeaver|8 years ago|reply
[+] [-] oconnor663|8 years ago|reply
[+] [-] songgao|8 years ago|reply
[+] [-] matunixe|8 years ago|reply
[+] [-] sillysaurus3|8 years ago|reply
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.
[+] [-] Semaphor|8 years ago|reply