There are still some things missing from the app, such as the ability to browse your encrypted files (KBFS), although the app actually has KBFS running inside it. So we're close on that front. Also, provisioning is still a bit clunky.
Possibly interesting to HN: Keybase is one of the only large apps we know of which exists on all 5 platforms (iOS, Android, macOS, Linux, and Windows) and which was programmed almost entirely in Go. Except for the chrome, which is react/react native. Source code for all platforms at https://github.com/keybase/client
If you're an HN user and give it a try, please send us feedback. It's `Gear Icon > Feedback`. We read all the feedback.
I'm really looking forward to that. I use something I cobbled together for password management that's completely backed by KBFS [Passbase] and I haven't worked on it much, but the main gripe I have is the difficulty in using my passwords in Android apps. Web apps are fine, Chrome syncs the password so I just login once from a computer, but any app is a painful `passbase read appname > /Drive/tmp.txt` and open-copy-switchapp-paste experience via Google Drive.
That's a long introductory way of saying: KBFS on phones will be fantastic - but I've long intended to move my (pretty much personal use only, but still) app to using a database rather than raw files, so is there any plan for programmatic access to KBFS for other apps? I realise there are non-trivial issues concerning permissions there, but it could be really great - perhaps silo other apps from full access, e.g. 'App is requesting access to KBFS/Appname, approve?' and 'App is requesting access to KBFS/none-of-its-business, approve?'?
Alternatively, have you considered implementing an input method provider as the means of inputting passwords into your apps? I know that on Android you can create your own input method apps. I think on iOS you will need to jailbreak the device and even then I don't know if you can make your own input method app for it.
I am imagining that the input method shows you your list of credentials and allows you to select from it.
Yep, that would be ideal :)
I'd like to use KBFS' multiparty private storage for shared passwords too though, which I think would be far easier to implement with a proper DB than text files.
The issue then is that if KBFS just comes as an 'explorer' view within Keybase app, I wrote have no way to copy a password for use. Hopefully cross-app access or a fully mounted drive is on the cards though.
Not the end of the world, but I take it this particular UX is a work on progress.
This means I have to wipe it when crossing borders.
Will doing so pollute my graph with lots and lots of device keys?
> This rule got so much press 7 years ago that it will be one of those "truths" about a platform that never dies on internet forums, that and the Playstation platforms using OpenGL as their primary API...
It's true that fork() isn't allowed on non-jailbroken phones, so you can't shell out to a Go binary (you can on Android if you want). But you can build a static library in Go and link it and call into it with cgo from Objective-C or something.
Unless devs are given the option to test the final binary, it's delivering untested binaries to users, and as such should be a no go.
Last night I was pleasantly surprised to discover it is in the FreeBSD repository as well. I really like what you all are doing.
How about Chromebooks?
I've been evangelizing keybase for a while now and was checking almost every week for info on an Android app, but this 'existence' by way of a React app is a huge disappointment. Without a simple, lightweight, native app, it is very difficult to do verified builds and engage community contributions. I sincerely hope there are plans in place for a real Android app; I would happily contribute in any capacity I could.
iPhone: https://itunes.apple.com/us/app/keybase-crypto-for-everyone/... (original link in post was: https://keybase.io/_/download/keybase-for-ios)
Unfortunately, Keybase cannot be considered free software because of this clause.
I am speculating that the clause is intended to be part of the Keybase terms of service, but because the software and service are tightly coupled, it is phrased as a software license restriction.
I think discussing important topics like war, death, and censorship are needed, but then again maybe I'm not "nice" bring up uncomfortable issues especially when they don't make your hero/candidate look good.
"We can't guarantee we'll be nice ..."
For example, you are not nice if you say:
trumptards do x,y
You are nice if you say:
x,y is not good in my opinion, because (list of arguments without resulting to offensive stuff)
...but we're just hoping at this point that they use your definition of "nice" and not the version I gave where having "bad" opinions is "abuse".
I had this issue before. I was complaining about a product on a forum and was a bit annoyed because it was expensive and did not work properly. I didn't call them names, but it was obvious in my tone that I was dissatisfied. Sadly, the moderators on that forum called it "trolling" and I got banned. Those moderators sadly also made money through the company I complained about since the forum is linked to the store.
So yeah. I can see what you mean.
This new mobile experience is very slick, with a very smooth login flow that just 'feels' secure as well.
The Keybase verification of different services feels very much like what ClaimID used to do, back when OpenID was showing promise as an open, secure, easy to use single sign on protocol. I'd still love for someone to solve this challenge once and for all. For some reason I'd love to see what the team behind Keybase might come up with in this space. (For now I'll have to do with using 1Password and 2FA wherever possible.)
On desktop my only complaint so far is that they keep trying to jam everything into a single app. I think they could break things up into three separate apps: core, chat, and KBFS. Personally, I have no use for KBFS and I wish I could disable it. It's also slightly buggy on macOS, and it causes a warning messages to show when restarting.
Because I didn't have an actual piece of paper with me when I tried the app (and writing down things like that on paper is a weird idea anyway) I opened 1Password to create a secure note there. Unfortunately, when I returned to Keybase the app had already silently moved on to the next screen without me having confirmed anything.
I'm not sure what this paper key will be needed for in the future but I hope it's nothing important.
You can add another paper key using `keybase paperkey`, and you may want to revoke the old one using `keybase device remove <key name>`. This is also possible to do from the "Devices" tab in the desktop or mobile app.
Of course, if you have Keybase both on your computer and your phone you already have some redundancy, and maybe having a paper key is not as important.
Will I have to download the app from dubious third-party stores ? :-(
Most notably PGP has been available in France for decade and has never received any form of approval as far as I know.
Just read developer FAQ for the store you want, there is a requirement of "Declaration approval from French ANSSI authorities." which links to http://www.ssi.gouv.fr/en/regulation/cryptology/
However supplying, importing and exporting cryptology means in and from France are regulated activities. These operations are either subject to a declaration or an authorisation process.
ANSSI records declarations and investigates requests for the authorization of cryptology equipment and services in accordance with French and European Community legislation."
So you have to send them ANSSI declaration and get an approval to submit an app to the store.
If you are distributing something through the website which is available everywhere then you can ignore that since there is no entity which would control that you follow French law, but it just a technical details. The law is the same for everyone I believe.
Regarding Telegram, Signal, WhatsApp, etc.: I believe they have sent all the documents and got the permission/registration in all regions they are available in and which require that.
Big app stores like AppStore or Google Play Market make you comply with the law every time you submit an app with cryptography inside.
ANSSI records declarations and investigates requests for the authorisation of cryptology equipment and services in accordance with French and European Community legislation.
 /data/data/io.keybase.ossifrage/files/service.log seems to be getting filled with a tonne of data every time I interact with anything in the app. I can see that filesize becoming a problem.
Looks very cool overall!
First part: if you lose or wipe a phone and want to reprovision, the lost device's private key is GONE. It will not exist in some icloud backup. When you provision your new device, the Keybase app will make fresh keys. To make that device yours, you'll need to either (a) bring together another keybase device, or (b) enter a paper key. When you do that, the old key will sign your newly generated key, and the new key will countersign. The old key will also be used to decrypt and reencrypt access keys for your data, so you can get to your old messages and files. Your data will live on. So even in an extreme example: if you write data in KBFS or send a chat message, provision a new device, and then revoke all your old devices, you'll still have the data on the new device. Assuming at some point you always held at least one of your private keys.
The general rule of thumb here is as long as you don't lose all your devices (and in this sense you can think of a paper key as a device), you won't lose your files in kbfs/chat.
The reason the answer above wasn't 100% correct: the revocation of a device (by another) does not trigger an identity re-proof, even for proofs made by the revoked device. Why? well, the original identity announcement is in a well-ordered signature chain of your announcements, and at the same time you remove it, you also have the power to remove your twitter or other proofs. By choosing not to do that AND leaving up your twitter announcement, it's pretty clear you're still you. This isn't like PGP where revocations and statements are floating around and could be ordered in any-which-way.
1. key X adds key Y
2. key X adds twitter
3. key Y revokes X (leaving twitter proof)
the twitter proof is considered still valid in Keybase's logic. Because 1,2,3 exist in a signed chain and Y had the power to remove twitter but chose not to.
One final point we've made in multiple places: your PGP key is part of your identity on Keybase (like your Twitter account or HN account), but it isn't used as a key in Keybase chat or the filesystem for a variety of reasons. So really, your Keybase-data is protected by your devices+paper keys. Just don't run out of them!
Requests to any Keybase devs reading this:
* UI to disable the macOS app from auto-launching on login (slightly user hostile not to be able to have this option, also asking permission before putting something in my Finder sidebar would be nice, useful though it may be!)
* Not sure if there's a technical reason for this, but it would be nice to be able to link accounts via OAUTH or similar without having to make a public post for all my e.g. Facebook contacts to see.
The whole point of Keybase is we don't have to trust Keybase (as a company). The proofs have to be independently verifiable, and an oAuth login wouldn't be.
I'd personally prefer maybe a badge which was showed either publicly or privately verified, and then people can make their own judgement, but I appreciate there's a loss in simplicity then.
Great work, thanks!
Nice to have a truly encrypted, secure chat application where I control the keys.
- Doesn't need a phone number
- Has good multi-device support
There's also other fun stuff like Kbfs: https://keybase.io/docs/kbfs
It also provides crypto for files, both signing (public sharing, https://keybase.pub/azag0/) and encrypting (private sharing).
EDIT: And this short description doesn't really make Keybase justice. The whole project is much grander.
Support for the PGP portion that is available on the web would be great as well, maybe with a "Copy to Clipboard" after encrypting so I can drop the ciphertext straight into an email? Or (with a few more permissions), using a Share feature to write the email/chat in the app of my choosing, and I just have to choose the sender.
If this catches on like I hope, I can see a grand future where Keybase is how I can contact almost anyone I know through almost any means (FB, Twitter, etc.), but until then, it would be cool to have support for "legacy" addressing such as email, but still with strong encryption.
But if keybase is sending the recipient my public key, then doesn't keybase have the ability to decrypt my messages, too? And if keybase can do that, than can't everyone else that is watching the public key go over the wire decrypt my messages, too?
It seems like this is really only good for proving that the sender of a message is who they say they are, but not really good for privacy.
Please correct me if I'm wrong. How is this supposed to work?
This is the general idea of how public/private key crypto works. The actual Keybase implementation is a bit more complicated because a person doesn't have exactly one public/private keypair, but rather keys for each device.
They basically provide the public key exchange and verification services with an appealing UI akin to your modern chat application.
Let's say you hook up your reddit account or HN account to your Keybase account, and we want to chat. One of us simply has to look for the other on Keybase, start up a chat like Twitter DMs -- but it's PGP encrypted and seemingly as flawless as exchanging PGP emails without the hassle of exchanging our public keys through a key-server. This is arguably the hardest thing for non-tech savvy's to grasp.
This is one of those teams that I legitimately get excited when I see new announcements.
Kudos on the launch!
Command: `keybase paperkey` will generate a new paper key, then enter that key onto your device.