OP here! I had to trim the post down for brevity, but I thought the HN community in particular might be interested in the API side of things.
Undocumented in the post: you can invent channels for app-to-app communication from the JSON API. For example, it's possible with Keybase chat to have a program posting encrypted messages for another person or program, without cluttering up the visual chat interface.
Also - to test chat we've cut the invitation requirement. You should be able to try the app without anyone inviting you.
Secondly, I think this is incredibly important moving forward with the proliferation of messaging channels. I want to be able to use one program for all of my different chat sessions. Whether that be adium or pidgin or mIRC or even weechat/bitlebee in a docker container. It would be great if there would be common plugins for common chat clients provided off the shelf. :D
We didn't design Keybase's chat API to match any messaging standard, but the number of calls into it are very few and flexible, and we're open to change.
As it is right now, I imagine it would be very easy to write a library that acts as a bridge to other interfaces, if that's of interest.
There are calls to see into your "inbox" which is the set of conversations, read messages, even peek at unread messages. And of course send messages, too.
This is cool. One thing that keeps me from using Slack, &c is that I don't trust my information to be stored on their servers. Keybase's combination of private keys and open source tools and protocols makes me comfortable with your server-side storage.
Your post does a good job describing what is stored in a readable format on your servers. One thing I didn't understand is where the data sent to users not yet on Keybase is stored. It sounds like my client is responsible for storing this unsent message, either locally or on Keybase's server encrypted for myself, and occasionally querying the DB to see if the target user exists and re-encrypting it. Is that right?
Finally, any thoughts on spam prevention for this protocol?
oh, great question! I wish I'd been clearer in the post.
Encrypted messages waiting for others are stored on Keybase servers. But they're encrypted only for the sender. The important requirement of this protocol is the removal of extra human steps, especially the ones before composing a message. The only thing a person should have to do is (a) write a message and (b) maybe tell the recipient it's waiting for them on keybase.
It's the worst to ask someone for their number or email before you get to compose a message.
There are still computer steps, however, and Keybae hides them from you. If you post an encrypted message for foo@reddit, then you sign a statement to yourself that foo@reddit is an intended recipient. When foo@reddit proves herself by announcing a key, your own client verifies the announcement and rekeys the content for her, assuming her key proof matches your signed assertion. This is no work for you, although it does require that one of your devices comes online. If they try to get to the content and all of your devices are off, they'll see a message that the original sender needs to come online before it's available for the first time.
The story with phones will be even better, as they're easier to reach through push notifications.
As with most large data encryption, this is performed by rekeying a symmetric key. So you can leave a huge attachment for foo@reddit and you don't have to download/upload the data all over again just to make it available.
As for spam prevention...we're still discussing. We obviously don't have the ability to study message contents. At the very least, we will need to have easy/clear blocking features
Thanks for expanding, and I wish you luck on the spam prevention. We often have conversations in the office about implementing a cost-based anti-spam system[1] for email, but I think a lack of universal usage kills that idea before it can begin. Keybase may be in a position to implement it before the protocol and user interfaces have ossified. Something to think about.
I find this stuff fascinating. Deciding not to interview with you guys because I didn't want to move remains one of the biggest "what if"s of my career so far :)
As for spam prevention...we're still discussing. We obviously don't have the ability to study message contents. At the very least, we will need to have easy/clear blocking features
This immediately jumped out at me as a potential problem with the system. I think you had better get jumping on it quickly. Preventing abusive messages is much easier if mitigation is built in from the start.
What prevents hundreds of spam messages hitting a new user as soon as they sign up? An automated system could create a spam message for every github user account (just as a way to get likely signup identities) and keep a client running and they would be delivered to new users as soon as someone verifies themselves. A group of people could target one individual so that they are flooded with unwanted messages upon joining.
I just installed the app but still get asked for an invitation code.
The chat sounds great, looking forward to try it out!
edit:
Nevermind, on the website I wasn't asked.
This is really cool. Question: right now, I have a [deep link to Keybase's encrypt page][1] on my website as "Create encrypted message." Will there be a way to do something similar, but using Keybase Chat(tm)? ("build it yourself" is an acceptable answer in this instance)
Considering that HN does not preserve envelope formatting, that more than one person reads HN, and that scrolling through this on my phone was really fun, perhaps PGP messages are not a good idea regardless of how on-topic or clever they are.
Q: group chats? Seems like it could be done by encrypting (and sending) the message to all recipients, so it's not particularly efficient, but it's a valuable UI thing.
Thank you and the Keybase team for this. Unlike other services, I think KB has solved the online identity authentication issue.
There's one hurdle I need to work through to get going on chat. Thus far I've avoided uploading my private GPG key to my Keybase profile, or even copying it to other devices (call me paranoid). Unfortunately this apparently means I can't authorize any other devices (see error message: http://imgur.com/a/UOftN). I assumed device keys were meant to solve this problem, but maybe not. Is there a supported way to make a subkey (GPG or otherwise) of my primary private GPG keypair, so other devices can securely authenticate against my KB profile?
EDIT: I haven't yet started using device keys. Maybe they would work?
This is answered in the FAQ at the bottom of the post.
You'll see this policy in action when you install Keybase on a 2nd computer. It'll make you either (a) type something on your first computer, or (b) enter a paper key. This isn't just two-factor auth with server trust. The old key is signing a statement about the new key, and the new key is countersigning.
It could be formatted better: it's telling you you have three different options, one of which is,
Install Keybase on a different machine that has your PGP key
I was in the same boat as you, I didn't want to import my private key onto this mac laptop because I don't know how the "Keychain.app" works and don't trust apple to not do something super helpful like store my GPG private key forever and always. I did the login flow on the machine I do trust, and was then able to use that machine to authorize the mac laptop, without moving any GPG keys anywhere.
I interpreted that option as Keybase needing a local copy of the PGP key. Thanks for helping me understand that's not the case.
I've set up Keybase on my trusted machine with my GPG keypair, and now have a device key on that machine. When I go to Devices -> Add new... -> New Computer in the GUI I'm told to "Type in text code" (along with the note "In the Keybase app on your computer, go to Devices > Add a new device"). I find this confusing because I'm already there. I tried using the only paper key I have, the one corresponding to my first device key, but there's no response when I click Continue. This is the Linux client, by the way. I'm guessing this is a bug, but I'm not sure. Can you confirm this is the same process you went through to generate your second device key?
When I try to log in on the secondary computer, which doesn't have the GPG keypair or a device key, I'm brought to the same error shown in the screenshot.
on my trusted computer with my GPG key, I ran 'keybase device add', selected option 1 ("desktop or laptop") and it asked me to enter the "verification code" from the other device. It also said, "to get a verification code, run 'keybase login' on your other device", but I'm certain that I just clicked some buttons in the GUI instead of running that command.
Wondering if you can clarify a bit—what parameters cause a chat to/not to show up in the GUI? Different topics? Different channel names? I have a use for this immediately and am excited to give it a shot!
For program-to-program talking, use the "dev" channel, in a topic of your choice. (By default --topic-type=chat and changing it to dev keeps it out of the GUI)
For example:
keybase chat send friend1,friend2\
--topic-type=dev\
--topic-name=KEYBASE-SYSOPS\
"server-restart [reason:hot and bothered]"
I'll never see this in the GUI but you and your friend1 and friend2, can access the messages through the chat API. The topic-name can be whatever you want, and it allows you to structure messages into channels.
----
If you're using the JSON api - which makes more sense if you're programming it - take a look at `keybase chat help api` to see some examples of how to structure the JSON going in. Anywhere you see a `channel` object, you can add `topic_type` and `topic_name` to them. Both should be strings.
Why is non-PFS the default? You wrote that somewhere in the documentation.
You said something about violating expectations when you sync PFS'd chat contents, but I don't see why that's relevant unless people were promised otherwise.
There's nothing about the encryption algorithm itself that dictates how data going over it should be handled at the endpoints.
Just let users have a regular mode and an off-the-record mode where nothing is kept. Both PFS protected.
I was wondering about that very thing when playing with it; encrypted app-to-app comm via the chat. Maybe something similar for the file system with a pair of pipe files.
"it's possible with Keybase chat to have a program posting encrypted messages for another person or program, without cluttering up the visual chat interface."
Nice. I'll be looking at what source of tools that use this style of communication on github.
One thing I've noticed so far is that with the Keybase desktop client on Windows 10, the "Reddit Form" button for submitting a proof didn't work for me. It just fails silently and doesn't open a browser window or whatever it's supposed to do.
Additionally I am curious why on Reddit people have to post a wall of text, while on Twitter you only have to post a small tweet? Is there some reason people can't just paste the tweet version onto Reddit too?
I'm entirely unconvinced by your argument regarding backing up a perfect forward secrecy chat. PFS is about preventing any listener of the messages in-transit from ever effectively decrypting those messages - it says nothing about security guarantees once the message is received.
It'd be like arguing that by enabling PFS also creates a social contract that the receiver guarantees that their device isn't compromised. Or that webservers that use PFS in TLS don't log most/all of the details for the requests they receive. I don't believe either of these to be true.
You seem to have extrapolated some social properties from a purely technical property and assumed everyone must think about it in the same way as you. But in doing so, you've made your protocol weaker against realistic attacks.
Oh, and the likelihood of an attacker stealing a device with WhatsApp installed and only being able to extract the identity keys and not the cached messages seems absurdly improbable.
Personally, I wish you'd either tried to work with OWS/WhatsApp/whoever to integrate in what makes keybase.io great (providing identity verification - something that all these could use) and not gone about adding to the already crowded area of chat providers.
In fact, you could even flip it around and let a shared notepad connected to the chat represent what you want to remember permanently, while the chat could remain ephemeral.
This makes for more accurate expectations and less risk of user error.
Wow, this is awesome! A colleague and I were just recently discussing how badly we feel the need for "encryption-first" chat software is - not tools that sell it as a feature, but tools that make it _the_ feature.
Using all of the associated accounts across services to do user lookup is really quite cool, and the CLI integration and public broadcasts look very fun. Nice work there.
Multi-device key management is one of the hardest tasks for end-to-end, but that's been taken seriously from the beginning by keybase, and I'm leaning toward optimism. The UX decisions for forward secrecy seem pretty reasonable as well.
Is it technically possible for Signal/Whatsapp to use Keybase keys in lieu of phone numbers? If so, how practical would it be to add this as an option?
I wonder how that would work with key rotation. Those chat services do a lot of key management for you during a conversation, while Keybase is more focused on long-lived keys.
End-to-end encrypt all messages,
but only "exploding messages" (coming soon) will have FS.
Therefore, your history will survive, encrypted, except for the messages you choose.
No. And even if it were possible they wouldn't allow it. Their servers are designed to forbid anything different from what they already do. Forget about that.
It'll be interesting to see if I ever receive messages from my fellow HN users now that it's a bit easier to do so without navigating my website to find my email address. I doubt it, but still.
I'll give it a run when I get home today. Since few of my contacts use Keybase, or would have any interest in Keybase, this is less "Wow! Awesome!" for me than the release of KBFS was - but it's still pretty cool.
I love how Keybase is expanding to be more than just a collection of "internet personas verified by a PGP signature" and am interested in what else you guys may have in the works.
E: Updated my profile info to make mention of Keybase Chat. And I don't even have it yet. ;)
Hey malgorithms, this is great! I check the Keybase website every month or so for updates and discovered yesterday that there's a new logo, replacing the old thieving dog/ferret/raccoon with what appears to be a person's head with their hair in a bun holding a key. Can you give some background on the thinking behind this logo redesign? (Sorry it's not a question about chat, per say)
Not only that - but a "thieving raccoon" helps reinforce the mistaken belief that crypto is only for criminals. While I don't think that had a "serious" effect or that people would read so heavily into a logo - it never sat well with me. While I didn't notice the logo change until the GP post pointed it out, I like the new one better.
we knew we needed a logo redesign no matter what; the old didn't scale well. The new one looks good at small sizes - say in a menubar or as a small icon. Of course that's just an opinion, but our team is happy with it. In old displays (think 72dpi), our new one isn't perfect, but most devices in the future will be high dpi.
As for brand messaging: the thieving kangarooster was suggestive of spy-like activity, which was playful but many people thought it sent the wrong message.
I personally like the message of the key in the hair...I mean I haven't thought it through in some deep way, but it's sort of like seeing a pencil in someone's hair: it's suggestive about their personality, and a pencil is an easy-to-use tool. A key in there feels good like that, like you can just grab it and use it easily. But that's just my own personal, previously unshared, take on why I like it.
That looks spectacular, can't wait to try it tonight. Hope this software can overcome the network effects of existing systems. End-to-end encryption is really, really important, but I feel like the real game changer is being able to instantly chat with anybody online by just typing in their username.
Good on them! The rest of this comment is not actually applicable anymore and you should give Keybase Chat a try :)
Original comment:
-----------------
My biggest concern with it, however, is that the Keybase client is now frequently verifying all my contacts' proofs. Many of these verifications are for personal websites and are done over port 80 or involve DNS lookups that my contacts control.
This leaks a great deal of metadata over the network about who my contacts are, and makes it easy for a hostile network to determine who I am if I'm running the Keybase app.
I hope they decide on some sort of fix for this. They could at least not do verifications over insecure connections and arbitrary 3rd party DNS lookups without my explicit approval.
They can't install anything on their computer, so no pidgin. Is it possible to use the web interface with Gtalk without having your personal email open?
This is fantastic! I've been playing with it for a bit, and I'm loving it.
Question: since (encrypted) chat history is stored on keybase servers, does my chat history count against my KBFS quota? If so, how do I clear it out? If not, how do you mitigate against someone building a pseudo-FS on top of chat messages for free unlimited storage?
No. The whole point of the app is to have a verifiable chat with people whom you have also verified the identity of. Without an account, this verification is not possible.
When providing Keybase or the Service with content, such as your name, username, photos, social media names, data or files, or causing content to be posted, stored or transmitted using or through the Service (“Your Content”), including but not limited to the Registration Data and any other personal identification information that you provide, you hereby grant to us a non-exclusive, worldwide, perpetual, irrevocable, royalty-free, transferable (in whole or in part), fully-paid and sublicensable right, subject to the Privacy Policy, to use, reproduce, modify, transmit, display and distribute Your Content in any media known now or developed in the future, in connection with our provision of the Service. Further, to the fullest extent permitted under applicable law, you waive your moral rights and promise not to assert such rights or any other intellectual property or publicity rights against us, our sublicensees, or our assignees.
That's a bridge too far, and someone needs to dial this back.
there are key additional phrases that subtly make it different, like the fact, that this is transferable.
And though not uncommon, using the term "provision of service" leaves the door wide open to your contents usage, because the lisc. is non-revocable, and perpetual.
If say, in 3 years from now as a provision of their service they offer analytics, or direct marketing. they can use any of your content for that.
I get this is probably just a wide net they are casting to not box themselves in, but it's something that is super restrictive to the user. And being as they also have a section require arbitration, and barring class action suits.
If they are acquired by, or decided become a bad actor, then you are pretty much SOL.
Note the "in connection with our provision of the Service". This largely looks to me like a standard set of terms that they require in order to not get sued for shuffling around your content just to provide the service you're signing up for.
While the rest of the paragraph looks standard to me, I'm not completely sure about that last sentence. Is that what you're wondering about?
> in connection with our provision of the Service.
This is pretty much boilerplate legalese that's generally intended to mean "you can't upload a file to your public folder, then sue us for copyright infringement because that file is in a public folder".
Lawyers seem like to cover their clients' asses as much as possible, but for a service like this that's designed for privacy-conscious people it'd do them well to step back and think about how the license comes across to privacy-conscious laypeople.
From what I've seen of Keybase, from back when they were just an alternative to the PGP Web of Trust to now, I don't think they're genuinely planning anything nefarious (but they'd still do well to have a ToS that reflects that).
What you're describing is "for the sole purpose of proving the service to you". The "in connection with" language is much broader. Whether the license is intended to give them more leeway or not is a different question.
No, from what I can tell it is them asking not to be sued to for providing the service they signed up for. That is, looking at your social media profiles to verify your identity across profiles.
Even if it did mean that, it would be of 0 use to them because they are fully end-to-end encrypted
I'm not really sure about Keybase accumulating more and more services instead of focusing on integrating to existing ones. One of the initial attractions of Keybase (to me at least) was how the system was very simple, transparent, and not really dependent on keybase.io.
Keybase is a VC-funded startup, and this is part of the standard playbook for such companies. Expect more of it from Keybase, and expect it for any other company whose investors are still looking to get a payout on their millions of dollars.
But I can still rekey everything using my master password and the encrypted private key is still stored on keybase's servers, right? (or something like that)
I'm going to lose the paper key just like I lost my 5 BTC wallet just before the great Bitcoin boom of 2013.
Depends on how you set up the key initially. I don't know if it's still possible, but at some point in the past you could specify your own master key that isn't stored on their servers. My account was one of those, so once I lost access to my computers/paper key, I also had lost access to the PHP key and therefore had to essentially start fresh.
The only pain is that you have to re-verify all your services.
I've been using the riot.im client over the matrix protocol, and while not yet the most mature comms stack, I appreciate that it is not based on a centralized server (i.e. i can and do self-host). My hope is that keybase can be made to be decentralized and that i can self-host. ..Or that its good features can be merged somehow with the best features of the matrix protocol.
i'm wondering which features would ideally make it over to Matrix? it feels there is parity already (other than perhaps defining PFS messages as 'exploding'?)
Good question/point...I guess I should have dived into the features of both and seen for myself (instead of assuming that the shiny new thing has better features)! ;-)
* A big part of my motivation to do it was as a toy thing to learn some Rust, so it has all the hall marks of someone kludging around trying to learn something new. Critiques/"WTH ARE YOU DOING"/PRs with style improvements also welcome :)
While I didn't try it myself (I just run my own git server), symlinking the directory of that to kbfs (or maybe just create a git repo there and make some magic to locally push stuff) should work.
I saw that recently, after the post on here about the 'pass compatible password management for teams', I forget what it was called.
It's actually more along the lines of the latter I wanted to do with Passbase - seeing as it's already using KBFS it would be (relatively) easy to do password sharing, just throw it in a shared private folder.
I was thinking more of the shared pizza-order password with room-mates, or groceries, bill-paying - whatever - than professional teams, though.
I digress, yes, I'd definitely recommend using Pass over anything I've cobbled together!
200 comments
[ 5.0 ms ] story [ 309 ms ] threadUndocumented in the post: you can invent channels for app-to-app communication from the JSON API. For example, it's possible with Keybase chat to have a program posting encrypted messages for another person or program, without cluttering up the visual chat interface.
Also - to test chat we've cut the invitation requirement. You should be able to try the app without anyone inviting you.
Secondly, I think this is incredibly important moving forward with the proliferation of messaging channels. I want to be able to use one program for all of my different chat sessions. Whether that be adium or pidgin or mIRC or even weechat/bitlebee in a docker container. It would be great if there would be common plugins for common chat clients provided off the shelf. :D
As it is right now, I imagine it would be very easy to write a library that acts as a bridge to other interfaces, if that's of interest.
There are calls to see into your "inbox" which is the set of conversations, read messages, even peek at unread messages. And of course send messages, too.
• a Matrix gateway server
• a libpurple plugin
Your post does a good job describing what is stored in a readable format on your servers. One thing I didn't understand is where the data sent to users not yet on Keybase is stored. It sounds like my client is responsible for storing this unsent message, either locally or on Keybase's server encrypted for myself, and occasionally querying the DB to see if the target user exists and re-encrypting it. Is that right?
Finally, any thoughts on spam prevention for this protocol?
Encrypted messages waiting for others are stored on Keybase servers. But they're encrypted only for the sender. The important requirement of this protocol is the removal of extra human steps, especially the ones before composing a message. The only thing a person should have to do is (a) write a message and (b) maybe tell the recipient it's waiting for them on keybase.
It's the worst to ask someone for their number or email before you get to compose a message.
There are still computer steps, however, and Keybae hides them from you. If you post an encrypted message for foo@reddit, then you sign a statement to yourself that foo@reddit is an intended recipient. When foo@reddit proves herself by announcing a key, your own client verifies the announcement and rekeys the content for her, assuming her key proof matches your signed assertion. This is no work for you, although it does require that one of your devices comes online. If they try to get to the content and all of your devices are off, they'll see a message that the original sender needs to come online before it's available for the first time.
The story with phones will be even better, as they're easier to reach through push notifications.
As with most large data encryption, this is performed by rekeying a symmetric key. So you can leave a huge attachment for foo@reddit and you don't have to download/upload the data all over again just to make it available.
As for spam prevention...we're still discussing. We obviously don't have the ability to study message contents. At the very least, we will need to have easy/clear blocking features
I hope this is an internal nickname ;)
Thanks for expanding, and I wish you luck on the spam prevention. We often have conversations in the office about implementing a cost-based anti-spam system[1] for email, but I think a lack of universal usage kills that idea before it can begin. Keybase may be in a position to implement it before the protocol and user interfaces have ossified. Something to think about.
I find this stuff fascinating. Deciding not to interview with you guys because I didn't want to move remains one of the biggest "what if"s of my career so far :)
[1] https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
This immediately jumped out at me as a potential problem with the system. I think you had better get jumping on it quickly. Preventing abusive messages is much easier if mitigation is built in from the start.
What prevents hundreds of spam messages hitting a new user as soon as they sign up? An automated system could create a spam message for every github user account (just as a way to get likely signup identities) and keep a client running and they would be delivered to new users as soon as someone verifies themselves. A group of people could target one individual so that they are flooded with unwanted messages upon joining.
[1]: https://keybase.io/encrypt#oddevan
wcBMA+CNQSDgk7JsAQf/bOJdpfJ6Uzt2/dwlQrgYnOOEFVDoFnMYpLDU3R41U4EI vG5CuW3BtpUZyQI+W/sgVXJoaj/HHtc4H+Kj3lqDizdUBansIYBbjtMZaJ/hN/cm zNIa6NlUZqmGKOYt0CKJhINnTp0dQJeVlKJQHjOBwvaqpPw0jfYLqLwfkR5y55RO ++WwyHSLXHQYTd6vX/CYtVAYIEU8NiP3s/FraLtYSF1OWMDITV22vyw5NSg9BLiK SI2vL74hKT5W8AvMBWdMIbFvlC6ef5e8BXABPLVXUtxuHg9t/uCM5ZQ6gnegn54R K39EA4bOwWuCE5XJK1h2RfCB6k8FG7nl9SpjTU6GW8HBTAMv22o+4yM4xAEQAIVZ Szs2mKfbkMKoR1jr6lTvfjm3wpd95ykOMZtKNd1YPPjqbGpAVii/SPqlTMwsgaj3 uuGSZlIQMcjUB/QixaeJowddBQxZzJHS04Cg0t+44MlaVczMe0gE3dyEY8swmKbM OFBq3nPDPuEyFV1LckFUuQwnwfoexvAgzEbW6m6qWt7DR+xKOW6DwkBL2aztWtJc A2s+JBRFw58PY9aeUIku6L0v3+tHLMKAQoXnmwFVA277CpG2OH7sk6rLq85y5JrW fXJ4SuHyIW7mLjYKm9PX6+PhQLH9KzqYlWM+08p/IoXR7DHYSWHRvk7zSruJgHqi I8WJTDdRghfUcbeedQRH8fx7MZiBwLQeHg0kBEEn6ajGr8trbKzdgw82FqPwXIfL 09Df0pcfXhJimfQ8XRVeNPK4+DVHUCEWc4cavm8ZaNSA8r1vRTytNtI3h4eOtM9G FZh/eaxl7hX8KxNGuK0clY+oMshUiNRIVScEUtsgpH8actXSdP16Wv/+H+51Tg9G 8rdNyeRMMBqKn+fDAAQFKbSe7n4GyNcg+dbHFuVzaF1fNq2LbGPOtnKb+Xbfwg0O WMLCui3TXNre30Jv5iorSTNLu3xP9X0LEDWLsgBeqgYW/YFhtwBLjeFUV5lmB4YS UVCDxepIb+yGDHESm9rwb/1Na0kslNPh9/18ngZ40sHBAerxcxFVGav1JBqpModE usf64H3xiBzIyxHbCzPhiSKZjuP2WXNV5k153rCG8bbreTfUXxpO6nIBHT2ie6sA xo7tN66AmN2fouxMIFYERIbL7S5S8fBkO1tsaF+VSveBx2heTQ84k+P4TCVD7PQB IU+TPXg+Vrz15tiVSoSI+Ep+rV2pzKOFQXl0adOUisV8tMMFJD3YSwbUoTreM8tq 7CAyWhCxjnbgiedG1qF/J55WYdNyc9PorK7Kjx6wTRHLVQhF1W80OT8X5gvFbUoe PnzNTp2zi/4hKZfl/8G2tN0VZqhEynCT+iaDO0hG7VVz8DJfDz+9699KpoSVbiad pHiRORulU3/gYKLAYYpOo1fx6AP1utcmDfwEiJEROfZqkMI+CW5HTXGZavr3eImq JhZFsrtSvitXGwcGW6bYDoR56NaV9+A2PUlVt9PrlAonus06tuj2/o47jrdxmX1K aEp3uWVh0ZFSjc2YazmaN/zJyECP7b5Ig2wvhjDh39QqlYPocSZnNnZkWlUi6x3r OQ7ffkqepcFD+Zafm8vU95xs8ehFY+Jivdbbj4P3kff1LBv8NQ6KDKA4eiliDrnO Ml/B1TwipND2PVg8qEq2n64cYJpeGD/Hrcr8PlAvH+v8Xc9VJaerB8yeg9FqyJS7 7dAAkJsgWXBx1bfK6BUkJ/CefNjOYjtizwhVa1uQFOZjpg057WEo0m+dw7nCEG5M 3VexMu/Kx96dI5+hqs6SWSf6rC+Jj74J5cyvtoZZ2XdHl8GzrKt4mHf+XFpqTefG TjwNkYPnofKXfXe/R14wifThs2thVmM6tY5TJBtGdqOVVhJ2wbsbByQ2ivVYBCW3 hAA= =1dpX -----END PGP MESSAGE-----
https://saltpack.org/in-the-wild
There's one hurdle I need to work through to get going on chat. Thus far I've avoided uploading my private GPG key to my Keybase profile, or even copying it to other devices (call me paranoid). Unfortunately this apparently means I can't authorize any other devices (see error message: http://imgur.com/a/UOftN). I assumed device keys were meant to solve this problem, but maybe not. Is there a supported way to make a subkey (GPG or otherwise) of my primary private GPG keypair, so other devices can securely authenticate against my KB profile?
EDIT: I haven't yet started using device keys. Maybe they would work?
You'll see this policy in action when you install Keybase on a 2nd computer. It'll make you either (a) type something on your first computer, or (b) enter a paper key. This isn't just two-factor auth with server trust. The old key is signing a statement about the new key, and the new key is countersigning.
I've set up Keybase on my trusted machine with my GPG keypair, and now have a device key on that machine. When I go to Devices -> Add new... -> New Computer in the GUI I'm told to "Type in text code" (along with the note "In the Keybase app on your computer, go to Devices > Add a new device"). I find this confusing because I'm already there. I tried using the only paper key I have, the one corresponding to my first device key, but there's no response when I click Continue. This is the Linux client, by the way. I'm guessing this is a bug, but I'm not sure. Can you confirm this is the same process you went through to generate your second device key?
When I try to log in on the secondary computer, which doesn't have the GPG keypair or a device key, I'm brought to the same error shown in the screenshot.
Wondering if you can clarify a bit—what parameters cause a chat to/not to show up in the GUI? Different topics? Different channel names? I have a use for this immediately and am excited to give it a shot!
For example:
I'll never see this in the GUI but you and your friend1 and friend2, can access the messages through the chat API. The topic-name can be whatever you want, and it allows you to structure messages into channels.----
If you're using the JSON api - which makes more sense if you're programming it - take a look at `keybase chat help api` to see some examples of how to structure the JSON going in. Anywhere you see a `channel` object, you can add `topic_type` and `topic_name` to them. Both should be strings.
You said something about violating expectations when you sync PFS'd chat contents, but I don't see why that's relevant unless people were promised otherwise.
There's nothing about the encryption algorithm itself that dictates how data going over it should be handled at the endpoints.
Just let users have a regular mode and an off-the-record mode where nothing is kept. Both PFS protected.
Nice. I'll be looking at what source of tools that use this style of communication on github.
Additionally I am curious why on Reddit people have to post a wall of text, while on Twitter you only have to post a small tweet? Is there some reason people can't just paste the tweet version onto Reddit too?
It'd be like arguing that by enabling PFS also creates a social contract that the receiver guarantees that their device isn't compromised. Or that webservers that use PFS in TLS don't log most/all of the details for the requests they receive. I don't believe either of these to be true.
You seem to have extrapolated some social properties from a purely technical property and assumed everyone must think about it in the same way as you. But in doing so, you've made your protocol weaker against realistic attacks.
Oh, and the likelihood of an attacker stealing a device with WhatsApp installed and only being able to extract the identity keys and not the cached messages seems absurdly improbable.
Personally, I wish you'd either tried to work with OWS/WhatsApp/whoever to integrate in what makes keybase.io great (providing identity verification - something that all these could use) and not gone about adding to the already crowded area of chat providers.
https://news.ycombinator.com/item?id=13605873
Nothing stops you from going full PFS.
In fact, you could even flip it around and let a shared notepad connected to the chat represent what you want to remember permanently, while the chat could remain ephemeral.
This makes for more accurate expectations and less risk of user error.
Great work KB team!
Using all of the associated accounts across services to do user lookup is really quite cool, and the CLI integration and public broadcasts look very fun. Nice work there.
Multi-device key management is one of the hardest tasks for end-to-end, but that's been taken seriously from the beginning by keybase, and I'm leaning toward optimism. The UX decisions for forward secrecy seem pretty reasonable as well.
How Keybase solves this problem:
End-to-end encrypt all messages, but only "exploding messages" (coming soon) will have FS. Therefore, your history will survive, encrypted, except for the messages you choose.
I'll give it a run when I get home today. Since few of my contacts use Keybase, or would have any interest in Keybase, this is less "Wow! Awesome!" for me than the release of KBFS was - but it's still pretty cool.
I love how Keybase is expanding to be more than just a collection of "internet personas verified by a PGP signature" and am interested in what else you guys may have in the works.
E: Updated my profile info to make mention of Keybase Chat. And I don't even have it yet. ;)
Huh.
[0] https://en.wikipedia.org/wiki/Alice_and_Bob
http://capello.nu/wp-content/uploads/lilla-my.jpg
As for brand messaging: the thieving kangarooster was suggestive of spy-like activity, which was playful but many people thought it sent the wrong message.
I personally like the message of the key in the hair...I mean I haven't thought it through in some deep way, but it's sort of like seeing a pencil in someone's hair: it's suggestive about their personality, and a pencil is an easy-to-use tool. A key in there feels good like that, like you can just grab it and use it easily. But that's just my own personal, previously unshared, take on why I like it.
Edit: since I haven't been running Keybase for the past 2 weeks, I missed the fact that they disabled continuous background proof verification due to my concerns: https://github.com/keybase/keybase-issues/issues/2782#issuec...
Good on them! The rest of this comment is not actually applicable anymore and you should give Keybase Chat a try :)
Original comment:
-----------------
My biggest concern with it, however, is that the Keybase client is now frequently verifying all my contacts' proofs. Many of these verifications are for personal websites and are done over port 80 or involve DNS lookups that my contacts control.
This leaks a great deal of metadata over the network about who my contacts are, and makes it easy for a hostile network to determine who I am if I'm running the Keybase app.
I reported this on GitHub when I noticed it and have unfortunately not been regularly running the Keybase app since: https://github.com/keybase/keybase-issues/issues/2782
I hope they decide on some sort of fix for this. They could at least not do verifications over insecure connections and arbitrary 3rd party DNS lookups without my explicit approval.
Question: since (encrypted) chat history is stored on keybase servers, does my chat history count against my KBFS quota? If so, how do I clear it out? If not, how do you mitigate against someone building a pseudo-FS on top of chat messages for free unlimited storage?
Apparently it is coming.
https://keybase.io/docs/terms
When providing Keybase or the Service with content, such as your name, username, photos, social media names, data or files, or causing content to be posted, stored or transmitted using or through the Service (“Your Content”), including but not limited to the Registration Data and any other personal identification information that you provide, you hereby grant to us a non-exclusive, worldwide, perpetual, irrevocable, royalty-free, transferable (in whole or in part), fully-paid and sublicensable right, subject to the Privacy Policy, to use, reproduce, modify, transmit, display and distribute Your Content in any media known now or developed in the future, in connection with our provision of the Service. Further, to the fullest extent permitted under applicable law, you waive your moral rights and promise not to assert such rights or any other intellectual property or publicity rights against us, our sublicensees, or our assignees.
That's a bridge too far, and someone needs to dial this back.
If say, in 3 years from now as a provision of their service they offer analytics, or direct marketing. they can use any of your content for that.
I get this is probably just a wide net they are casting to not box themselves in, but it's something that is super restrictive to the user. And being as they also have a section require arbitration, and barring class action suits.
If they are acquired by, or decided become a bad actor, then you are pretty much SOL.
While the rest of the paragraph looks standard to me, I'm not completely sure about that last sentence. Is that what you're wondering about?
This is pretty much boilerplate legalese that's generally intended to mean "you can't upload a file to your public folder, then sue us for copyright infringement because that file is in a public folder".
Lawyers seem like to cover their clients' asses as much as possible, but for a service like this that's designed for privacy-conscious people it'd do them well to step back and think about how the license comes across to privacy-conscious laypeople.
From what I've seen of Keybase, from back when they were just an alternative to the PGP Web of Trust to now, I don't think they're genuinely planning anything nefarious (but they'd still do well to have a ToS that reflects that).
Even if it did mean that, it would be of 0 use to them because they are fully end-to-end encrypted
Now that I know about the JSON API for chatting, I'll have to add it to my unofficial Ruby interface[1].
[1]: https://github.com/woodruffw/keybase-unofficial
Works like a charm today.
This should be very nice for ad-hoc secret exchange.
That way, you don't have to rekey all your services if you lose it and access to all your devices, like I did.
Protip: Use the paper key. Keep it safe. You never know when you'll have to use it.
I'm going to lose the paper key just like I lost my 5 BTC wallet just before the great Bitcoin boom of 2013.
The only pain is that you have to re-verify all your services.
I've been using the riot.im client over the matrix protocol, and while not yet the most mature comms stack, I appreciate that it is not based on a centralized server (i.e. i can and do self-host). My hope is that keybase can be made to be decentralized and that i can self-host. ..Or that its good features can be merged somehow with the best features of the matrix protocol.
ahahah, that's great!
But I'd agree, a good UI provided by keybase would be lovely.
Well, not the UI part. And it's probably buggy as hell* - be warned - but It Works For Me ^TM. (And issues/PRs more than welcome!)
[0] - https://github.com/OJFord/passbase
* A big part of my motivation to do it was as a toy thing to learn some Rust, so it has all the hall marks of someone kludging around trying to learn something new. Critiques/"WTH ARE YOU DOING"/PRs with style improvements also welcome :)
While I didn't try it myself (I just run my own git server), symlinking the directory of that to kbfs (or maybe just create a git repo there and make some magic to locally push stuff) should work.
It's actually more along the lines of the latter I wanted to do with Passbase - seeing as it's already using KBFS it would be (relatively) easy to do password sharing, just throw it in a shared private folder.
I was thinking more of the shared pizza-order password with room-mates, or groceries, bill-paying - whatever - than professional teams, though.
I digress, yes, I'd definitely recommend using Pass over anything I've cobbled together!