Keybase is out for iPhone, Android
113 comments
Oh HN, so much for a soft-launch! (But thanks for all the positive comments on here.) We've been testing Keybase a lot with iOS and Android testers and we quietly released into the app stores last night. In many ways it's an MVP focusing on: (1) Keybase chat, and technically important (2) your phone acting as an additional device key, so you can easily provision new desktop computers.
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.
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.
> the ability to browse your encrypted files (KBFS)
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?'?
[Passbase]: https://github.com/OJFord/passbase
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?'?
[Passbase]: https://github.com/OJFord/passbase
>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.
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.
> 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.
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.
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.
Keybase is utterly unusable since you introduced the chat feature. I use a yubikey to store my gpg key so I get prompted every 5 minutes to enter my pin because for some reason keybase insists on requesting it over and over again even though I'm not even using the applcation.
Have you tried filing an issue against the client? https://github.com/keybase/client/issues
FWIW, I also use a Yubikey and don't have this problem with Keybase. I'm running Keybase on a combination of Ubuntu and Debian machines. My master key is completely offline, and my subkeys are all on my Yubikey.
I have the same setup. I was never able to make Keybase work with GPG on a Yubikey. Did you have to jump through hoops to make it happen?
> your phone acting as an additional device key
This means I have to wipe it when crossing borders.
Will doing so pollute my graph with lots and lots of device keys?
This means I have to wipe it when crossing borders.
Will doing so pollute my graph with lots and lots of device keys?
One thing that trips me up is the folder system; I can't quite figure out how to delete or hide folders, especially the ones with typos in them. As a result, I have a bunch of legacy folders that just clutter the interface, and the "Ignore Folder" button doesn't seem to be working.
Not the end of the world, but I take it this particular UX is a work on progress.
Not the end of the world, but I take it this particular UX is a work on progress.
How did you manage to get something written in Go into the iOS app store? I was under the impression that foreign binaries weren't allowed.
There was a brief period where they seemed to be insisting on Objective-C, but it didn't last long. Now they don't care what language you use as long as your functionality follows their guidelines.
This was brought up a couple days ago during discussion of a game built in Rust on the app store. A comment there[0] claims that the restriction on languages is no longer in the guidelines.
[0] https://news.ycombinator.com/item?id=14302931
[0] https://news.ycombinator.com/item?id=14302931
In fact, it was only in the guidelines for a few months back in 2010. I can only quote the response to the comment you linked:
> 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...
> 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...
Google has had a Go app, "Ivy," on the app store since 2015. I think it was just an experiment at getting Go to build for the App Store and getting it approved, but it was in fact approved.
https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
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.
https://itunes.apple.com/us/app/ivy-big-number-calculator/id...
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.
The bigger problem with go is if/when Apple requires bitcode on iOS.
For those who don't know what "bitcode" refers to and why the "if/when":
https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc...
https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc...
I hope never ...
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.
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.
> exists on all 5 platforms (iOS, Android, macOS, Linux, and Windows)
Last night I was pleasantly surprised to discover it is in the FreeBSD repository as well. I really like what you all are doing.
Last night I was pleasantly surprised to discover it is in the FreeBSD repository as well. I really like what you all are doing.
They could better say "exists on 5 platforms", to avoid implying that other platforms don't exist, even if they are considered unworthy in some way.
I've had the hardest time with keybase because on my Mac I have multiple user accounts (one for each client I have) and I started experiencing all kinds of permissions conflicts - and then I had trouble uninstalling. Have you tried testing it out for these kinds of environments?
Is there a way to mount the filesystem not on /keybase?
> one of the only large apps we know of which exists on all 5 platforms (iOS, Android, macOS, Linux, and Windows)
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.
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.
Any chance to be able to prove also my own Google+ profile?
Any plans for a Universal/iPad app? Chat would be awesome there, I use Slack on my iPad to keep chat away from my main screeen...
[deleted]
Clickable links:
iPhone: https://itunes.apple.com/us/app/keybase-crypto-for-everyone/... (original link in post was: https://keybase.io/_/download/keybase-for-ios)
Android: https://play.google.com/store/apps/details?id=io.keybase.oss...
iPhone: https://itunes.apple.com/us/app/keybase-crypto-for-everyone/... (original link in post was: https://keybase.io/_/download/keybase-for-ios)
Android: https://play.google.com/store/apps/details?id=io.keybase.oss...
thanks @techsupporter
> By using the Keybase app you agree to the following terms: you'll be a nice Internet person.
Unfortunately, Keybase cannot be considered free software because of this clause.
Unfortunately, Keybase cannot be considered free software because of this clause.
Not necessarily. The clause only seems to apply to the binaries provided on the iTunes or Google Play store, and not to the actual source code, which is BSD licensed [1], or any binaries you might build yourself.
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.
[1] https://github.com/keybase/client/blob/master/LICENSE
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.
[1] https://github.com/keybase/client/blob/master/LICENSE
I am really tiring of these cute, but vague clauses.
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.
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.
I'm pretty sure it's just a joke. There's no way such a thing would be enforceable.
Sure but this is the type of thing that shies corporate lawyers from approving usage of something.
"We can't guarantee we'll be nice ..."
"We can't guarantee we'll be nice ..."
See also "don't use for evil" clause in JSON library by Douglas Crockford and a special exemption for IBM: "I give permission for IBM, its customers, partners, and minions, to use JSLint for evil." [0].
[0]: http://dev.hasenj.org/post/3272592502/ibm-and-its-minions
[0]: http://dev.hasenj.org/post/3272592502/ibm-and-its-minions
More specifically "define 'nice'"
It is a joke but a stupid one that harms adoption of the product. It's conceivable the author could decide say, eating meat isn't "nice" and sue an organization using it that packages meat products for consumption. A judge may find it unenforceable but having to potentially get tied up in a legal battle in the first place already makes it unpalatable to many organizations. See one of the replies here about a similarly juvenile clause where organizations got written permission to use a product "for evil". Not sure a few giggles is worth harming the adoption of technology many people have worked hard to deliver.
[deleted]
You can bring up sad and negative topics without being an asshole. That means you are being 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)
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)
Certainly, in decades of commenting you'll never find a comment where I call someone a foul name.
...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".
...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 know what you mean.
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.
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.
I think the broader point is that (pseudo-)legislating politeness is bad policy.
If I give Keybase a not nice review will they revoke my license?
On eBay I stopped giving neutral reviews because if it wasn't 5 star then I'd get negative reviews back on my own account. Neutral = Negative to some people.
I think its more to do with the community you're interacting with. Five stars means that the product meets reasonable expectations, anything less means there's something wrong.
Keybase has succeeded in making crypto and user verification user-friendly enough for day to day use. (Even though it's probably not easy enough to use in day to day e-mail.)
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.)
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.)
Keybase is amazing, and I'll be installing it on my mobile device. It really makes crypto a lot more approachable for average users. Their chat is great, and I'd been looking forward to the mobile app.
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.
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.
I just tried to use chat on FreeBSD (helpfully mentioned in another comment) but it fails with "error unboxing chat message: KBFS client wasn't found" so they might be more tightly linked than you hope.
The paper key process after the initial login is broken.
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.
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.
If you lose the device key on your computer (perhaps there is a hardware error or it is stolen), you can use the paper key to add a new device key to your account - and not lose any data.
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.
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.
If for some reason in the future you lose access to the devices you have already logged into Keybase with then you'll permanently lose access to that account with absolutely no way to recover any of the files, messages, etc... it contains. It may be unlikely you'd lose access to multiple devices at once but seems risky to even continue using that account without the paper key. Luckily you can generate a new one from the app.
Oh great... the application is not available in France (!).
GooglePlay refuses to let me download the app.
And the website does not provide a direct link to the apk (only direct links to desktop apps).
Will I have to download the app from dubious third-party stores ? :-(
Will I have to download the app from dubious third-party stores ? :-(
As I read France set very troublesome restrictions for any software which uses cryptography. As I remember it requires some kind of approval from government, assignment of special code based on documents you provide via mail. And it takes up to 4 month.
Signal, Telegram, WhatsApp, PGP, RetroShare and other are freely available in France.
Most notably PGP has been available in France for decade and has never received any form of approval as far as I know.
Most notably PGP has been available in France for decade and has never received any form of approval as far as I know.
It's not about being available on the internet, it's about being available on the AppStore or Google Play Market which make you comply with French laws.
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.
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.
Source ? I'm french, and I've never heard of this. US used to have silly export laws way back when, but that's been over since 2000.
http://www.ssi.gouv.fr/en/regulation/cryptology/
Big app stores like AppStore or Google Play Market make you comply with the law every time you submit an app with cryptography inside.
Big app stores like AppStore or Google Play Market make you comply with the law every time you submit an app with cryptography inside.
And Keybase desktop apps are freely downloadable from French IPs, so... ?
Keybase desktop apps are not distributed through AppStore or Google Play Market, so there is no one to make them follow French law at that point. While stores should comply and make developers follow all the procedures.
France has removed those restrictions, since 2004.
https://en.wikipedia.org/wiki/Cryptography_law#France
https://en.wikipedia.org/wiki/Cryptography_law#France
Just check out 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 authorisation of cryptology equipment and services in accordance with French and European Community legislation. "
"...
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 authorisation of cryptology equipment and services in accordance with French and European Community legislation. "
Just installed on my OnePlus One. Is very laggy to switch between options by touching the buttons at the bottom of the screen. In particular, pressing the chat button seems to do nothing for over a second before it switches to the chat page. I've had this phone for a few years, and this is definitely the lagiest app I've used on it.
[edit] /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.
[edit] /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.
Could someone explain how the underlying keys are managed for Keybase mobile? I'm guessing as part of sign up you generate a unique key just for your mobile device, and if your mobile device is lost, you'll need to generate a new key? How does this dovetail with your desktop key? Does resetting any active key trigger a re-proof of each your identity services (i.e. Twitter, GitHub, etc.)
Looks very cool overall!
Looks very cool overall!
They have a blog post of their key model. [0] If you lose your device you shouldn't have to re-prove your identity on all services just any that you proved using that particular key.
[0] https://keybase.io/blog/keybase-new-key-model
[0] https://keybase.io/blog/keybase-new-key-model
Almost 100% correct :-)
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!
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!
Re the final point: Was it like this from the beginning? I still have some identities signed by my original PGP key with which I signed up to Keybase https://keybase.io/azag0/graph
yes, but to be clear: an identity proven by your PGP key is still considered "you" for chat/KBFS, as your device keys have transitively said that PGP key is you. So (1) PGP proved twitter (or whatever), then (2) PGP signed in a device key (which counter-signed), and therefore (3) device key can read KBFS/chat that is sent to you by your Twitter name.
Can I confirm my understanding? In my graph https://keybase.io/nickrw/graph if I lost the key "panya" I would still be able to use either of my other two device keys to add another device, even though they are child nodes?
yup!
any chance of getting this added to the F-Droid project? I'd like to be able to get the APK without having to install gapps first.
I can't get my friends to use Telegram or anything remotely better than sms or Google hangouts. I hope keybase finds the critical mass that's needed to make these things work.
Congratulations on the release! Been waiting for this one :)
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.
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.
Just FYI - the purpose of the public posts is (I believe) to leave yourself verifiable by others at any future time. So then nobody has to take Keybase's word for it that Keybase account X is linked to Facebook account Y, because I can just verify it myself with your public post!
Not affiliated with Keybase:
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.
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 definitely get that motivation. Doesn't change the fact that people who might want to use Keybase are more likely to be privacy-minded, and therefore less likely to have public Facebook, Twitter accounts (like myself).
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.
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.
Very cool. Would be great to eventually see support for the file picker UI similar to Resilio or Working Copy so files can be saved directly into KeyBase's encrypted areas.
Keybase is great, makes the whole process of PGP significantly nicer to use, lowers the barrier and hopefully encourages more people to participate.
Great work, thanks!
Great work, thanks!
Woohoo! Great to get notifications and chat on my phone.
Nice to have a truly encrypted, secure chat application where I control the keys.
Nice to have a truly encrypted, secure chat application where I control the keys.
This doesn't sound too different from Signal to me other than the public directory of people thing. Is that it?
It also:
- Doesn't need a phone number
- Has good multi-device support
There's also other fun stuff like Kbfs: https://keybase.io/docs/kbfs
- Doesn't need a phone number
- Has good multi-device support
There's also other fun stuff like Kbfs: https://keybase.io/docs/kbfs
I think of Keybase more as a cryptographic platform which can bundle devices and identities into a single package, see my "tree" for an example https://keybase.io/azag0/graph
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.
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.
The chat is largely incidental to the actual use of keybase which is more of a convenient wrapper around key management and identity proofs. Signal doesn't allow you to take your key and sign or encrypt files without sending them through signal and doesn't interact with any other services.
The app is up and running great here, not experiencing any of the referenced performance issues (so far).
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.
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.
So how exactly does it open a truly secure chat with someone else? If it is encrypting messages, then the recipient would have to have my public key to decrypt the message, right?
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?
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?
When you send a message, you encrypt it with their public key, so that only they can decrypt it. Additionally, you sign the message with your private key, so the person who receives the message can verify that you signed it, by using your public key.
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.
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.
Oooohhh ok, I get it now. Thanks for the explanation!
You need the private key for decryption. Private keys sit locally on each device and don't go anywhere. Messages are encrypted with all public keys of the recipient and yourself, so every party can read the conversation on any device.
I've never heard about Keybase before this post. Can someone explain what the "you can write securely to any twitter, reddit, facebook, github, and hacker news user" is about? If you write to them do they need the app to view it or does it go into their inbox (does github even have an inbox?). And if they open it on a browser it would no longer be encrypted, right?
It's like WhatsApp; but with PGP and you're in complete control of your keys.
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.
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.
afaik, it's pgp/gpg under the covers with a nicer UX and registry for public keys... so, technically they wouldn't need the software to send/receive messages from you, but it makes it easier.
Nice! This feels like a huge leap forward for Keybase in terms of broad, daily usability. The onboarding onto the app felt pretty smooth overall, always nice when I can feel comfortable logging into a mobile app without pulling up my password manager.
This is one of those teams that I legitimately get excited when I see new announcements.
This is one of those teams that I legitimately get excited when I see new announcements.
Hmm. Could I use the file storage feature of this to store small text files containing passwords and other confidential data? Would that fit well with its security model?
Awesome, looking forward to seeing Keybase grow through mobile.
Is adding 2FA somewhere on the horizon? I'd prefer something like U2F or possibly the upcoming SQRL, but I'll take anything robust that isn't SMS.
Installation and logging in was very smooth on the iPhone version at least: just typed my username, scanned a QRCode (wow!) and I was ready to go.
Kudos on the launch!
Kudos on the launch!
I'm so glad this arrived. Thanks Keybase! Finally we have proper identity backed secure chat! (Which is going to be my main use case.)
What UI library did you use on iOS and Android?
Not a contributor, but it look like they're using react-native https://github.com/keybase/client/tree/master/shared/react-n...
I can't figure out how to log in on this. I use the CLI client which seems to have no way to auth the new device.
Doesn't the CLI client allow you to generate a new paper key? Then you can use that paper key to authorize the new device.
Command: `keybase paperkey` will generate a new paper key, then enter that key onto your device.
Command: `keybase paperkey` will generate a new paper key, then enter that key onto your device.
Huzzah and congratulations! I've been eagerly awaiting this. Congrats on the release!
holy molasses batman. Great app but you have to be hella patient!
Hope this helps get wider adoption for distributed trust models
does your messages only get stored on the senders and recivers device or even on a keybase server?
Oops we had a problem... :/
Definitely looking into this!
How'd you guys build this? Are these native apps, or Cordova/Ionic?
The UI is React / Reactive Native, the rest is Go
Written in Go!
https://github.com/keybase/client
https://github.com/keybase/client
Android: https://play.google.com/store/apps/details?id=io.keybase.ossifrage