In general I find Keybase to be a step forward in user experience and two steps backwards in terms of actual security. They just don't seem to care about the latter at all and have not demonstrated any cooperation with standards bodies like the OpenPGP working group where members have expressed interest multiple times in adding generic URL uids to the openpgp public key itself to replicate and decentralize the idea of social media based trust bootstrapping (the one good idea from Keybase in spite of terrible execution). Instead they insist on their complex proprietary walled garden system that does not integrate with existing keyservers and throws everything on the bitcoin blockchain for reasons.
Keybase has become the IE of crypto and I can't take any security project seriously that even -integrates- with them.
Honestly, the OpenPGP world has so competently failed at usability and is only adopted by the most hard core of nerds. Even I have stopped using it for the most part.
And that it is two steps back in security overall is just not true. Maybe in some individual features that you care about, but not in general.
And the same thing counts that always counted, crypto that nobody is using is not protecting anything.
The have mostly moved on from GPG any a different libraries now. The GPG is mostly a legacy feature.
This seems pretty inaccurate.
* Lots of software projects sign their releases with PGP.
* Almost all Linux distributions sign their software with PGP. If you use Linux, your security relies critically PGP.
* Github has support for PGP, and I see people use it.
* My random server hoster happens to sign all their emails with PGP.
You could claim that all these systems are run "by the most hard core of nerds", but at that point the statement loses its relevance.
There's only one thing that's worse. Crypto that people think is protecting them, but which isn't.
Also there are projects in the OpenPGP world making very easy to use workflows and interfaces without centralizing or breaking standards. OpenKeychain for android is a fantastic example of this.
I use OpenKeychain on my phone and can sign files, access passwords, or decrypt email by tapping my yubikey to it. I can tap someone elses key to my phone to import their key to my addressbook. No terminals or fuss and at no point does any key come in contact with system memory of any device involved so I have strong assurances it can't be stolen even if my phone is totally compromised.
A big example of the 2 steps backwards of keybase: they use keys in system memory and abandoned any compatibility with the openpgp smartcard spec, yubikeys, etc. The industry is moving to smartcards for very good reason: malware is a thing and it can use/steal keys from system memory without user interaction. A key stored in a yubikey 4 OTOH never touches system memory and requires a physical touch for each operation.
You can have usability without throwing out security and standards. Keybase is just another in a long line of companies ignorantly throwing out any security features they don't understand using usability as an excuse for bad engineering.
Don't you know? There's a rule that all cryptographic software must be arcane and obscure and virtually impossible to use correctly by anyone other than obsessive nerds.
For the record it soon may be possible to use native GnuPG through the browser extension:
> Installer: New optional module "Browser Integration" to register GnuPG as backend for Mailvelope 3.0.
Source: https://www.gpg4win.org/change-history.html
But given Keybase's track record I already know they're not interested in that.
Is that a normal thing to do on github?
[0]: https://wire.com/
The browser extension is not their main product and they explicitly say so. The author is completely dismissing [0] the entire product just because of a side project, which in the worst case scenario could be fixed by the community by submitting a patch.
It is also strange that the author seems to feel the need to reinforce the sensationalism of this post by linking something completely unrelated to Keybase.
Also, where are the quotes on this post coming from? Where is the rest of the communication?
There is really nothing to see here.
[0] - "Initially, I planned to take a closer look at the crypto in Keybase, to see whether I can find weaknesses in their implementation. But that’s off the table now."
[1] - "But as experience shows (https://palant.de/2018/07/11/ftapi-secutransfer-the-secure-a...), the claim “end-to-end encryption” doesn’t automatically translate into a secure implementation."
The author is completely dismissing [0] the
entire product
Fool me once, shame on you; fool me twice...
And BTW, I also don't like the option to upload private keys. I mean, no sane person would ever do that. It's not that hard to copy keys to multiple devices, if that's really necessary for your work flow. Me, if I used mobile devices, I'd use dedicated keys, because those things are so readily pwned.
The extension is very much an official Keybase product and recommended heavily on their end. Why should I waste more time on a product where valid security issues are being dismissed? It isn't even so much about not being paid, as: if they don't care about such edge cases subverting their end-to-end encryption, what do they care about?
> there were technical reasons why iframes didn’t work, though I forget the details
It could be that there is one or a couple of engineers at Keybase who made this decision and are also the same entity that replied to the bug bounty. It feels like they haven't thought it through properly or brought it up for proper discussion inside the organization. Let's hope that they remedy this and adjust their general approach to this if this gets enough attention.
On the other hand, even if this is addresses, unfortunately it's an indicator that other compromises in this category are done in other parts of Keybase.
Then I found out that they're not using popular and audited libraries like OpenPGPjs instead... writing their own!
But more serious and nested "secure" communication would be wiser done elsewhere.
Of course, it goes against orthodoxy to share/upload your private key, but I'm not sure I've ever seen a good rebuttal to Filippo's post.
It seems to me though that you're reducing the entropy of your key from the 2048 bits or whatever to the entropy of your key phrase, which would normally only be some 100 or so bits (if you have a decent one) - but I'm not informed enough to judge the details. However, it seems to me that Filippo is, and he did upload his private key (encrypted) - so how bad is that, really? Anyone got some substantiated insights there?
[1] https://blog.filippo.io/on-keybase-dot-io-and-encrypted-priv...
As best I can tell they have rolled their own mostly closed source crypto solution from day 1.
Right, but if the social network website can modify the HTML that the Keybase extension is injecting, then surely it can also modify the iframe's URL to an attacker-controlled one? Or, for that matter, replace the event handler on the "Keybase Chat" button itself before it even gets clicked?
I'm not an extension developer, so there might be APIs available to extensions or restrictions on webpage JS that I'm not aware of, but I suspect the only secure way to do this (if you don't trust the page you're embedding in) might be to have the extension communicate with the native Keybase app, which then opens a chat window with the appropriate user, similar to how the 1Password browser extension works.
Keybase could minimize that by showing the user's name and/or logo in the iframe. Barring another vulnerability, the site shouldn't know who is logged in into the extension, so they shouldn't be able to fake that.
Keybase is fantastic.
i've been using keybase for 2 years now and have had no issue accessing my files through kbfs.
with keybase teams you can store secrets at rest and make them easy to access across your team.
the client loads 10x faster then slack and has nice ux.
How do you feel about someone else composing the message that "you" (your encryption software) are going to encrypt? Because that's what the article is talking about.
And I would think it is analogous to running kbfs on a machine with a virus or keylogger.
And one nice thing is your root key is still protected by a paper key which you can physically secure, and use to de auth any compromised device keys.
For the casual user who is just getting into keybase, social integration like this may be worth the risk in order to help onboarding new users. Once they start seeing the real benefits of using keybase, they can delete the extension and still make use of the good stuff.
Finally, keybase is open source right? They are a small team and might not have the resources to improve the extension, but just getting the first iteration out there might be enough to attract contributors who see its value and can improve its security.
My reasoning is that you're given some encryption software (keybase javscript on its website or browser extension) but the software is changing all the time: it might get re-downloaded on a tab refresh, the extension might download a "new version" or whatever... So basically you're supposed to trust an always changing piece of code (can you be auditing every piece of javascript that you download? every version of that javascript?) and you running in a super-connected runtime (like a browser). What could possibly go wrong?
I am not an encryption expert at all, but I feel a lot safer doing my crypto on a regular environment (linux shell or whatever) and then sending the cyphertext via any other mean (web, email, whatever).
Back in the day you could use pidgin to chat on the Facebook chat, and it was possible (and relatively easy) to use the OTR plugin to have really end-to-end encrypted chats. But (guess what?) Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)
Facebook later disabled the possibility interacting with its chat via external non-facebook-branded clients (afaik)
In the case of Caprine, it appears not to use any official API and is just scraping the web page for the right elements. This seems quite fragile and also a non-trivial body of code.
I understand why Keybase principals don't want to do that, because the extension is an addon that probably doesn't do anything in particular for them as far as adoption goes. I'm not sure I understand why they continue to ship the existing extension, knowing that it's insecure.
And I don't see any excuse at all for editing the bug report on Github out of existence - that strikes me as sufficiently sketchy that I may no longer use Keybase at all, and certainly will no longer rely on it to be especially secure.
http://lettergram.github.io/AnyCrypt/
https://github.com/lettergram/AnyCrypt
https://chrome.google.com/webstore/detail/anycrypt/hddfngccl....
It worked fairly well (haven't tested it in a bit), but I had to reverse engineer pretty much all the Keybase APIs at the time.
The thing is, the author is totally correct. I wrote mine as a proof of concept, and quite frankly was surprised that the Keybase chrome extension (even a year ago when I checked) had the same issue(s) my implementation did...
That being said, this isn't an "end-of-the-world" kind of thing, I think there are several easy solutions to this problem as the author pointed out. Personally though, only 3 people use my extension with me. I couldn't get anyone to use the Keybase extension.. so I really think they should just update that phrasing on their extension page (perhaps add a warning) and let it be.
I just signed up for keybase and was definitely steered towards installing the browser extension. I quickly uninstalled it because I found it annoying, though.
I wouldn't use a keybase key for anything that should be rendered eternally unbreakable, based on side-channel threat analysis alone. Private keys are not something that should be sourced from a website.