22 ms·

Keybase is not softer than TOFU

614 points by malgorithms 8y ago

grenoire 8y ago
I don't know how much weight such warnings will hold, given how well we know people ignore cookie warnings and the rest...
- dannyw 8y ago
  The Keybase warning is particularly scary. I don’t think it’s fair to compare it against a cookie warning.
- walrus01 8y ago
  Look at the number of non technical end users who will determinedly download .EXE files, or run them from their mail client, and click through all of the Windows 10 "do you really want to run this untrusted software?" warnings in order to successfully install cryptolocker type malware on their computers. If you give people a way to click "yes/accept/run" and they are determined to accomplish what they think is their intended task, they will just blow through any warnings.
  - ummonk 8y ago
    There are ways to do it properly, e.g. how Chrome lets you bypass HSTS by typing "badidea".
  - foepys 8y ago
    You don't even need to observe the average end user. Just look at software developers aka "technical experts" using npm, NuGet, Maven, and all the other package managers. Digital signatures? Nope, just run the code on your machine, please. Bonus points for allowing code execution in user context to "configure" the package and placing executables in $PATH. npm here being exceptionally secretive on what it will install as dependencies as it can reach tens of thousands packages very quickly.
ReptileMan 8y ago
Use threema. It has this problem (and the phone number one) solved.
- rapsey 8y ago
  How?
- cypherpunks01 8y ago
  I would argue that the benefit of solving this problem mentioned is far outweighed by the large downsides of using proprietary software.
orblivion 8y ago
The argument is that people don't bother to keep their verified connections up to date. But come on, how often to MITM attacks happen? For those rare cases where people are doing stuff important enough that it becomes a possibility, I would guess the security conscious individuals would become more diligent. For the rest of us, it seems that doing it on occasion is still worth it. As I understand, Signal is designed to never indicate over the wire who has checked safety numbers. Thus, a MITM anywhere on the network creates a risk of becoming discovered, which is a cost in itself.
- hopler 8y ago
  What's the point of using an encrypted chat at all if you don't care if it's hacked?
  - orblivion 8y ago
    It's not care vs not care, it's a cost-benefit analysis.
    - atonse 8y ago
      This is a great point, however as many security researchers will tell you, the cost of an exploit goes down exponentially over time. Yesterday's hash attack that required $100m supercomputer will require a $10k GPU, which is 5 years will require a $100 GPU. (Not talking about the math changing, but it's been more about weaknesses in S-boxes and other parts of older hash functions that get slowly chipped away) Similarly, yesterday's system that takes an attacker 3 days to MITM your machine, will take 3 hours, and then will be somebody's python script that installs and aggregates millions of exploits. So in general, the cost and benefit variables are constantly changing under us.
      - orblivion 8y ago
        Actually I was referring to the cost to the user who wishes to protect themself. Signal is designed to be fairly low "cost" i.e. easy to use. If they can find a way to make it more secure without making it harder to use they should and probably will do it. For most cases, the benefit of privacy probably doesn't warrant going through more trouble than this. For those cases where somebody needs more protection, there's a way to go through a little more trouble to use Signal more diligently (agree with important parties not to change keys for a period of time). To your point though: the cost of executing MITM doesn't just include the equipment, it includes showing ones hand by being discovered.
sdenton4 8y ago
(A very tiny fwiw): you /can/ create a backup in signal and use it to transfer seamlessly to a new device, without triggering new safety number checks. The user flow sucks, but it is possible.
- metildaa 8y ago
  Backups are only possible on Android, and the most recent Signal non-beta builds have had this feature broken, making backups you had useless. Unless your willing to open a bug and be a pest for 2 weeks (and still have access to your old phone/leave it registered) I wouldn't plan on retaining your messages or keys across phones. Its a huge weak point of Signal.
  - aibara 8y ago
    Hmm, that's odd. I very recently had to cycle through using four different phones (one was dying, two ended up being defective, finally got a decent one), and each time I successfully transferred all my messages to the next. I thought that just transferred your messages though, not your keys (I could be wrong there). But it is a bit silly that you need to manually move the file from the old phone/backup location to the new one without some in-app option to do so.
    - metildaa 8y ago
      This was circa 1 month ago that I had this issue, and it was fixed in the beta build of Signal Android after a few days. Moving to the beta channel doesn't really help if the old device is not avaliable anymore, as the backup is still not usable.
  - izacus 8y ago
    Even in that case, you could only backup on device storage, had to write down (!) a huge set of numbers and manually copy files around. The whole flow is awfully terrible to any user - at least WhatsApp can sync your profile over Google Drive. Last time my phone died, I lost all of my Signal group memberships, because the app is incapable of transfering those to a new phone without backup... and it's also incapable of doing the backup automatically. Those UX choices continiously baffle me - it's like authors didn't learn anything from the failure of PGP.
i_am_proteus 8y ago
Their solution seems reasonable, but why not allow export of an (encrypted) private key for use on other devices?
- eridius 8y ago
  Keybase allows you (nay, encourages you) to set up a "paper key", which is a private key that you store offline (e.g. print it out and stick it in a safe). You can then use this paper key to provision new devices. This way if you lose all of your devices simultaneously (or just have one device to begin with) you don't need to go through an account reset to add a new device. Note that even with this, any new device added using the paper key still generates its own independent private key. Having per-device private keys is important to be able to revoke devices, and to be able to track which devices were responsible for any given action.
  - i_am_proteus 8y ago
    To quote Kanye Omari West[0], "I like this." [0]https://youtu.be/PsO6ZnUZI0g?t=95 https://youtu.be/PsO6ZnUZI0g?t=95
- deleted 8y ago
  [deleted]
hopler 8y ago
Keybase's UI is still bad. It prominently highlights the "Let them (the eavesdropper) in" button, and the warning has so much red that it's hard to read the text.
hprotagonist 8y ago
I actually _do_ reverify safety numbers out-of-band every time they change.
- threwawasy1228 8y ago
  I would actually like to see some numbers or a survey on how many people actually do this. Anecdotally I don't think I know a single person who ever verifies safety numbers out of band. Of the approximately 50 people I use to talk on signal with regularly not including large group chats of people I don't know as well, not a single person has ever tried to reverify me nor have I tried to reverify any of them. Would be cool to see what the numbers are for reverifications.
  - rabidrat 8y ago
    At some point, continued conversation is verification enough. The MITM isn't a catfish, and they are going to have a hard time keeping up the charade acting like someone you chat with regularly.
    - ryukafalz 8y ago
      It doesn’t have to be a human in the middle though - if you’re in a position to MITM, it’s much more scalable to put a bot in between that relays messages between one person and the person they intend to communicate with.
      - faho 8y ago
        In that case you can just ask if they got a new phone.
  - hprotagonist 8y ago
    I normally don't do this in-person, but some kind of out of the loop approach is something i do every time. One time i got a postcard from a friend with their safety number on it and nothing else. I recognized their handwriting to complete the loop.
Pxtl 8y ago
I'm not a security guy, but wouldn't the most seamless approach be to encrypt the key collection with a master password and store the encrypted key collection on the server? So on a new device you'd download the encrypted key collection and then decrypt it locally? If they forget their password, they can re-upload it from a validated device with a new master password.
- syn0byte 8y ago
  Biggest issue is single point of failure for total access to all devices. Get\guess\beat out the master password and its game over on all connected devices.
  - IshKebab 8y ago
    The way it works now is with SMS authentication which is not really secure at all.
    - eridius 8y ago
      Where does Keybase use SMS authentication?
      - chupasaurus 8y ago
        Nowhere, IIRC you have to add new device from an already trusted ones. GP probably thought about other messengers.
  - eridius 8y ago
    Not only that but this also enables offline attacking of the password. If you can compromise the Keybase server and grab the encrypted passwords, you can then attack it at your leisure with whatever computing power you can scrounge up, over whatever time duration you want. And when you break it, as long as any of the included devices are still on the account, you'd have complete access to everything. Requiring existing devices to be actively involved in provisioning a new device prevents all of this.
fiatjaf 8y ago
Very reasonable criticism. I'm now happy for never having used Signal.
DoubleMalt 8y ago
I love Keybase. Actually I tried to install the app a couple of days ago. But there is no version on F-Droid and the version on Play Store has Firebase Analytics baked in Is there a plan for a clean F-Droid version?
- jxcl 8y ago
  They also have no (as far as I could find) way of installing Keybase without root permissions on Linux. I tried looking for a way to install keybase without "sudo dpkg -i keybase.deb" but had no luck. In the end, since the people I'm working with use it, I had to spin up a VM to install it in so that keybase wouldn't mess up my Debian installation.
  - giancarlostoro 8y ago
    Are there many apt packages that don't require root / sudo privileges to install something?
    - xrisk 8y ago
      There should be a way to just `make install` it to whatever location you want, IMO.
      - giancarlostoro 8y ago
        You can also extract the files from a .deb file and place them wherever you so desire as well though if you really want to be that extreme about it. I see no issue with installing things as root, it's running random software as root that's the real issue. If you verify what the post-install script for a Debian package is doing (ie not running anything not already on the system) you should be fine to install KeyBase and any other package as root. Packages don't run the software they install unless it installs a daemon or something.
        jxcl 8y ago
        My concern isn't that I don't trust Keybase to not be malicious, it's that I don't trust their packaging to not conflict with other packages. Debian has a very strict packaging process and it effectively guarantees a stable system, but installing packages that don't follow the standards that their packagers have could cause problems on upgrades. I don't know enough about Linux to verify that the Keybase package does everything right; I delegate that to the Debian packagers and don't install anything as root unless it's from the Debian package repositories. Any software that I need that isn't in the distro is installed to a folder inside my home folder, where it might conflict with other custom installed software, but at least it won't break the entire system.
dcbadacd 8y ago
The thing I find about this article the nicest is that they published the audit result document. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...
idlewords 8y ago
Much of the criticism of how gently WhatsApp and Signal handle key resets misses the mark. Widespread adoption of end-to-end encrypted messaging is an effective countermeasure to passive collection and blanket surveillance. In order to get that widespread adoption, you can't be showing people skull-and-crossbones warnings every time they swap out a SIM card. Speaking from my experience getting journalists and political campaigns set up with signal in 2017-2018, the early scary key change warnings were off-putting to people and made them reluctant to continue with the messenger. At the time, I was in contact with 100-150 people via signal and quickly ran out of patience with anyone who insisted on a safety number check. But the UI at the time encouraged that level of paranoia. I continue to believe that making key changes as painless as possible for users is the correct approach as long as there are ways to harden this behavior in the settings, for the benefit of the far smaller set of people to whom MITM attacks are a credible threat.
- BostonEnginerd 8y ago
  I agree with your assessment about key change management. With that said, I do like the device history trail that Keybase uses. Keybase has a better multi-device story - in that it has a multi-device story at all. I understand what they're trying to do preserving message history - I do prefer my conversations to be ephemeral by default. I'm OK with the compromise that Signal has made with key management -- there are people that I really care to have private communication with, and people who I prefer to have private communication with. I verify the former, and don't bother with the latter unless we happen to be bored together in the same room. On a side note, thanks for your efforts over the last two years!
  - idlewords 8y ago
    The user base for Keybase and Signal is so different that it makes sense to have such different behaviors. Thanks very much for the kind words!
    - chb 8y ago
      I would have thought that these two groups would have more in common than not. Who do you think constitutes these disparate user bases and how are their perceived expectations different?
abhinai 8y ago
In an ideal world, I would love to use a really secure app for communication. However, my choices are limited when most of my friends are on WhatsApp or Signal. That is just the unfortunate reality of the way social networks work.
- idlewords 8y ago
  Both WhatsApp and Signal are secure apps for communication, and your friends are right to use them.
tosh 8y ago
If there was an iPad app that works in landscape mode I’d be able to switch most of my groups from other apps to keybase.
josh2600 8y ago
Show us the server: https://github.com/keybase/client/issues/6374 https://github.com/keybase/client/issues/6374
- giancarlostoro 8y ago
  Why I like Wire in this regard, they seem to have their front-end and back-end open sourced. I believe their servers AGPL licensed, but it still allows you to run your own instance. Sadly people are highly more likely to use either Signal or KeyBase than Wire, which I think is my favorite since it doesn't tie you to a phone number (tip: register from the desktop first), and you can delete all your account information.
  - kerouanton 8y ago
    I also use and like Wire for the same reasons.
    - giancarlostoro 8y ago
      I use all I have listed, I like the UI for KeyBase the most personally especially the way it handles social proofs where you need to verify yourself through a crypto key or another device. I wish Signal would just do this, but it's too married to phone numbers that it's suspicious in that simple regard. I use Signal with my wife, so for us to verify our keys it's very easy and simple.
- icelancer 8y ago
  "Open source project"
- 99052882514569 8y ago
  It's on their roadmap, guys.
  - Arkanosis 8y ago
    Is it? In the aforementioned issue, keybase-travis says “it still isn't”.
unsignedint 8y ago
Requirements to use phone number, let alone, as an identifier is major complaints I have for many of messaging apps. It really limits usable cases as I have plenty of people I would love to interact but not necessarily want provide my phone numbers. I love Keybase for this aspect, but something I don't like about it is its device name handling. They don't allow decommissioning old device names, so I end up having 'MyLaptop' 'MyLaptop 1' 'MyLaptop 2'...
- regnerba 8y ago
  A few months ago I deleted Facebook and part of doing that looked into what messaging app to move to. I needed something easy to use as I wanted to get my family on it but also really didn't want to link my phone number. I ended up landing on Wire and so far have found it to be really good. You can register with phone number but it is not required and you can register with an email instead.
- malgorithms 8y ago
  Oh interesting. I don't think we've talked about this decision publicly, so I can write about it for a second. Not letting people re-use a device name is an inconvenience, I admit, but arguably it's not like other cryptography inconveniences, where people are confused, troubled, etc. We figured people would say "huh, weird requirement" and pick a different name and move on. The goal is a 1-1 mapping between devices (keys) and these names. So whenever we need our UX to talk about a key, it can talk, safely, about it in terms of device names. Once committed to your chain of signatures, "Laptop-Warhol" means a specific device key, and it can't be used again. So, for example, if one of your Keybase installs wants to tell you "oh, Laptop-Warhol just added a new device, iPhone-Vangogh" then it doesn't need to look like this: "Key 34858234589234895897234598734 added key 90123845890230948234234324." If Laptop-Warhold could mean multiple devices (keys), well then we'd need to start talking about the keys. Which is a nightmare for usability. A lot of this decision was driven by something we've seen with apple devices. Every now and then I'd get a popup on my computer - say when updating iOS - that said something like "you just started using iMessage on a new device, 'chris's iphone'. if you don't know what this you should freak your shit out." well - it has basically said that so many times with the same names over again, that I can safely assume that it's a near-useless warning. Note I mean unique to you; 2 different users on keybase can name their devices the same. Generally speaking...it's been a goal from the beginning that names on keybase are meaningful. Similarly if you look up "chris" in in our merkle tree (which is pinned to bitcoin) that leads to a deterministic chain of signatures. inside that chain, where I mention "work-imac-warhol", you're guaranteed to see the same answer as I am. So "chris" is as good as a key fingerprint or safety number. And so is my device name.
cyphar 8y ago
Matrix handles this by exposing the device keys to the user so they can make decisions about whether to trust new devices (and I believe identity key changes mean you wouldn't be in your rooms anymore -- but in order to change identity keys you would have to delete you entire Matrix account on the homeserver). If a new device has shown up, your messages will be blocked from being sent until you verify the new device. To be fair, it is too easy to blaze past the warning -- and it can happen often in large rooms. As a result, it's a little bit cumbersome at the moment, but with device cross-signing coming down the pipe and the new verification system (which is much better than Signal's IMHO -- you just check both devices have the same string of 7 emoji on their screen) it's getting a lot better.
- IshKebab 8y ago
  Yeah that sounds like it doesn't really solve it at all (yet).
  - cyphar 8y ago
    It does partially solve the issue of continuing to send messages without any sort of warning -- new devices mean your messages won't send unless you hit the "send anyway" button (and in your settings you can disable the send anyway option). It also solves a problem that Keybase has which is that all new devices are automatically trusted (so a compromised device can just register more devices to avoid being blocked). To be fair, this makes for a pretty bad UX -- and the Matrix folks are working on cross-signing to make this easier -- but it is very useful for a user to be able to detect new devices to be detected (especially their own).
- ajvs 8y ago
  Yeah usability-wise it's not the greatest right now until those features get added, but security-wise it's better than Signal/WhatsApp in warning you about detected new keys.
- UncleMeat 8y ago
  This works great for incredibly tech savvy people who have an offline way of verifying public keys. This is completely and utterly useless for 99.9% of whatsapp's 1b+ users. Heck, how many times have security-aware software engineers blazed through the "THIS KEY IS NOT TRUSTED" warning from ssh?
inetknght 8y ago
> Similarly, in SSH, if a remote host's key changes, it doesn't "just work," it gets downright belligerent: Funny enough, I have ranted to friends/coworkers about sysadmins completely replacing machines and not telling anyone. How do I know it happens? BECAUSE OF THIS EXACT WARNING.
xrd 8y ago
Smart stuff and fun: "Did you though, or did you just scroll down here?"
miopa 8y ago
I'm wondering why the article fails to mention that there is a sufficiently good and easy mechanism to compare and verify the new safety numbers. You just talk to your peer and read the numbers - and the peer can verify them. This will fail when AI software gets really good at imitating voice in real-time during casual talk, but we're not there yet (or - if that is my threat model, I'll find an out of band way to verify)
- zaroth 8y ago
  A sufficiently good mechanism from a cryptographic standpoint, but which from a usability perspective totally falls down because people never do it. It’s a very worthy goal to make these events rare and scary so that users might actually bother reading those numbers out loud to each other.
broahmed 8y ago
Let's not forget what Signal and the Signal Protocol (used by WhatsApp) have achieved: making end-to-end encrypted chat EASY and accessible for the masses, for many of whom "security" is password123. It's important in our post-Snowden world.
- godelski 8y ago
  I'm not sure why this is downvoted. The reason WA has so much popularity is that it is easy to use and you could use wifi. Signal is not as easy to use (less features) but more secure and so privacy conscious people like it. But people don't like switching to Signal because "it is hard". Making a more secure app is good, but we have to question "do we want people using pretty good e2e or do we want to make the perfect app first?"
  - mikekchar 8y ago
    I don't think your question is as easy to answer as you might be implying. I certainly don't know the answer. My main concern is: what is the downside to "pretty good e2e"? Without understanding what that means, we can't evaluate the situation. "Good" is better than "best" if "best" is not available seems obvious, but it certainly isn't true in a lot of cases. If I tell you that X secure and you trust it to be secure, when it actually has problems -- that might be worse than me telling you that X is not secure. People are bad at evaluating risk. If I want to pass notes in class and don't want my teacher to know what the note says if I get caught, then rot-13 is probably "good enough". But if I'm a whistle-blower for a government agency, my security needs are quite a bit higher. We can never make a perfect app, but I'm not sure I could define what "good enough" looks like for the general populous. It's completely reasonable to me that different groups have different opinions on the matter -- and I think that's a good thing.
    - godelski 8y ago
      > If I tell you that X secure and ... Is Signal or WA in that regime? Literally the only reason I don't use WA is because it is owned by FB. But as far as I'm aware both are cryptographically secure. Yes, I'm aware WA has a metadata problem. So what's good enough? I'd say that if you need a state actor to crack it, I'll call it good enough. At least for the general populous. Any more difficulty that can be made is a bonus imo. Clearly we can't get a perfect e2e app. So at what point in time do we say "we also need other features that people want so that they'll use our app". That doesn't mean "stop working on encryption" (you can never stop that) but "we're at a good enough point to start targeting a larger market." I think something like Signal is there. Stop focusing on the security geeks and bring in the general public.
el_cujo 8y ago
"How often do resets happen? Answer: if you're using WhatsApp or Signal, all the freaking time. With those apps, you throw away the crypto and just start trusting the server: (1) whenever you switch to a new phone; (2) whenever any partner switches to a new phone; (3) when you factory-reset a phone; (4) when any partner factory-resets a phone, (5) whenever you uninstall and reinstall the app, or (6) when any partner uninstalls and reinstalls. If you have just dozens of contacts, resets will affect you every few days." I guess I don't have "dozens of contacts", but getting a new phone/resetting a phone isn't really that common of a thing in my circle. I feel like for the average user, they wouldn't do this with their phone more than like once every year or two. So I guess if you have like 600 people you talk to on these apps regularly then that works out to daily, but for me at least this isn't that big of a deal and was pretty much understood from the outset.
- mhluongo 8y ago
  I've had to do it 4-5 times myself (busted phone, water, upgrade). I think it's possible to export the keys (at very least the message history) to avoid this, but if I need to verify with someone I actually fall back on... Keybase :)
- idlewords 8y ago
  Also (I believe) when you swap out SIM cards, which is routine behavior in parts of the world.
  - viraptor 8y ago
    That's not the case. You don't even need a sim card for WhatsApp.
    - icebraining 8y ago
      Can confirm, I used to run it on a WiFi-only tablet, having confirmed the number of my featurephone (which didn't have WhatsApp at all).
    - OJFord 8y ago
ex3ndr 8y ago
Having encrypted backups means that you are throwing away PFS.
foxhop 8y ago
Keybase is awesome. I wish they would take my money as a customer. I don't want to see them to away.
z3t4 8y ago
Key rotation is a hard problem. One idea is to host the public key in a txt domain record. For example yourname.com that you can also use for your email and blog.
deleted 8y ago
[deleted]
wDcBKgt66V8WDs 8y ago
Kind of OT but the belligerent SSH message example they used is good comedy
arendtio 8y ago
Actually, I think it is wrong to call it TOFU as it simply doesn't require the user to opt-in to anything. Instead, it seems more like the thing the XMPP people call 'blind trust before verification' [1]. I am not quite sure if it is exactly the same as 'blind trust before verification' changes its behavior as soon as you explicitly verified the keys. That way everybody can use somehow e2e encrypted messages, but if you really care about the security you validate your keys and get a real trusted e2e encryption. [1] https://gultsch.de/trust.html https://gultsch.de/trust.html
throwawaymath 8y ago
There are a few claims made here which I'd like to see clarified. In the spirit of transparency, let me declare upfront that I use Signal but I am not affiliated with them, and I don't really have a dog in the race here. I'll reference the published NCC security review[1] for this comment. Overall I'm happy to see a published cryptographic review of this protocol. First, under "The Full Security Picture" heading in this article, it's claimed that forward secrecy is supported via time-based exploding messages. Pages 19 and 20 of the NCC report explain that, "The default chat protocol does not allow for forward secrecy since the same keys can retain indefinitely on a users device." So forward secrecy is not assured by default under this chat protocol, is that correct? The NCC report goes on to say that, "Exploding messages introduce mechanisms for message deletion and forward secrecy; however, it is not clear to the user that keys and messages could remain on their device beyond the period specified during message creation." I interpret this to mean that there is a way to assure forward secrecy - which is exploding messages - but you're not making that explicit in this announcement. This seems a little disingenuous to me because in your FAQ, the first answer criticizes Whatsapp for compromising forward secrecy using the backup feature, but you don't have forward secrecy enabled by default in your chat protocol. Likewise, this announcement makes a point of mentioning how other apps require you to trust the server due to resets, and why trusting the server is bad. But page 20 of the NCC report explains that, "While the default Chat encryption protocol does provide for message confidentiality and integrity, it does not provide for security in the face of device and server compromise, as keys and ciphertext are stored for a potentially indefinite period of time." So is it correct to say that unless users specifically enable exploding messages for their conversation (which is not the default), they actually do need to trust the server? There are also a few drawbacks to the ephemeral messaging scheme NCC found that I think should be explicitly disclosed, because they don't require too much technical detail: 1. There is no deniable authentication on the default chat protocol. While exploding messages provide deniable authentication, this property fails in a group with more than 100 participants. It's fair to question whether that's a realistic place to expect deniable authentication, but it should probably be called out. 2. Exploding messages are based on the local client's system clock. Therefore it's possible for an exploding message to be indefinitely retained on another device by e.g. manipulating the local time. ___________________ 1. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...
malgorithms 8y ago
I don't know the moderation policy on title changes at HN, but I just changed the title of the post. Internally at Keybase - and thanks to a conversation with a peer - we've been feeling pretty guilty about calling out a specific project that we think is basically the gold standard outside Keybase. We'd rather focus on the positive solution to the problem (which Keybase has implemented), rather than just pointing a giant finger at any other services which have the problem we're trying to address. I think I personally will sleep better tonight this way. Still we want this conversation to continue.
- sctb 8y ago
  Sleep well! We've updated the headline here.
  - malgorithms 8y ago
    <3
- acrispino 8y ago
  From the updated FAQ: How DARE you attack Project XYZ? This still reads as unnecessarily acidic to me, given the update notice at the top of the article.
h4t 8y ago
I've been using keybase for quite some time now and I absolutely love it. I suggest everyone give it a seriously try and check out some of the popular public teams chats before finalizing your opinion of it. I'm glad I did.
- diaz 8y ago
  Best thing for me besides chat working with some friends regularly is the amazing file sharing option between multiple parties easily.
chr1xzy 8y ago
I can never get keybase to address this article about them: "Keybase, we have a problem." https://freehuman.fr/posts/20238f40da8b01357816236af097d2ae https://freehuman.fr/posts/20238f40da8b01357816236af097d2ae Maybe user /kbModalduality can
- chupasaurus 8y ago
  A happy KB user, let's bring that article down: 1. A server runs KBFS which syncs data with the server. No one could stop you from disabling it on startup and running wherever you need it. 2. Any app running without AppArmour/SELinux or outside of network namespace could get your real address. Latter is relatively easy to set up, I'm running VPN by default and all the apps inside are running only in the namespace with VPN tunnel device. 3. Last time I checked I could make my own package. 4. I don't have time to check it atm. 5. Link for audit results is somewhere in the comments on this post. 6. Works with uBlock on. 7. Some paranoia rant without looking how KB works: it's push/pull mode, all messages are stored as files you could sync. 8. Based on previous points. 9. Each connection is under TLS. Plaintext messages could be read via RAM, and if someone could read it, KB would be the last problem. 10. You could make your own. 11. Fixed. #ls -l /keybase would show you the symlink KBFS_NOT_RUNNING to /dev/null, but shows correct directories under user running the app. 12. Hello GDPR. 13. Like everyone in the world does. 14. Bad outro.
DINKDINK 8y ago
If a single party in a chat has their keys reset that's not a MITM attack because a MITM would need to rekey to both parties. If the two clients communicate via at least one uncompromised service to communicate that their counterparty's keys have been reset, they might be able to detect a MITM Keybase's example Cozy Street is not a MITM attack (i.e. an attacker has inserted themselves between two parties and can get the plaintext), it's just impersonation. If it was a real MITM attack both Alice and Bob would get rekey notifications, unless they both confirm whenever they get a rekey notification a MITM attack is possible. I also think that crypto is stuck in the early 90s by thinking real world meetups are the only way to authenticate keys. If you know what your chat friend sounds and looks like, willing to submit a video, and don't think your adversary can fake such a proof, a simple video of you reading your pubkey/safety number is sufficient. Is that scalably practical? no but it is possible. That said: keybase is doing cool novel work, I commend them for advancing the state of the art.
peterwwillis 8y ago
I like it! They should apply this to the problem of TOFU in HSTS. For many HTTPS sites it's trivial to hijack them by getting a user to switch to a different device, as the devices' apps often don't synchronize HSTS databases.
solatic 8y ago
Why can't we just have government certificate authorities for the average Joe? Ultimately, while people may have very little trust for the government in general, the one thing that people do trust the government for is establishing identity. We use government ID papers to establish our right to work, to open bank accounts, to enter legal agreements, and to cross borders. Why should communications be any different? We don't need to trust the government with the content of the communications (and we shouldn't), by not providing the government with the private keys. But why can't I get the government to sign a public key for me? The issue it raises is whether people will eventually get locked out of society if the government decides to get antagonistic with somebody by revoking their public key and refusing to issue a new one, given a society where such a scheme is popular. But we don't have any sort of such protection today - the government can seize your passport, seize your driving license, freeze your bank accounts. A society in which the government solves identity issues for the digital age is only a net improvement over the status quo.
- feanaro 8y ago
  Not only that, but the government will inevitably stay requiring you use a key pair which they will supply. Citizens won't know the difference and won't fight it back hard enough. Hello government-sanctioned cryptographic surveillance. Best not to open that particular can of worms.
- dannyw 8y ago
  Because not everyone wants to communicate under a singular identity.
- Couto 8y ago
  Certain countries like Portugal, Estonia and so on, already emit digital certificates stored inside the chip of every citizen's ID card. I believe these cards are made by Gemalto[1] [1] https://www.gemalto.com/govt/identity https://www.gemalto.com/govt/identity

614 points by malgorithms 8y ago

I don't know how much weight such warnings will hold, given how well we know people ignore cookie warnings and the rest...

dannyw 8y ago
The Keybase warning is particularly scary. I don’t think it’s fair to compare it against a cookie warning.
walrus01 8y ago
Look at the number of non technical end users who will determinedly download .EXE files, or run them from their mail client, and click through all of the Windows 10 "do you really want to run this untrusted software?" warnings in order to successfully install cryptolocker type malware on their computers. If you give people a way to click "yes/accept/run" and they are determined to accomplish what they think is their intended task, they will just blow through any warnings.
- ummonk 8y ago
  There are ways to do it properly, e.g. how Chrome lets you bypass HSTS by typing "badidea".
- foepys 8y ago
  You don't even need to observe the average end user. Just look at software developers aka "technical experts" using npm, NuGet, Maven, and all the other package managers. Digital signatures? Nope, just run the code on your machine, please. Bonus points for allowing code execution in user context to "configure" the package and placing executables in $PATH. npm here being exceptionally secretive on what it will install as dependencies as it can reach tens of thousands packages very quickly.

ReptileMan 8y ago

Use threema. It has this problem (and the phone number one) solved.

rapsey 8y ago
How?
cypherpunks01 8y ago
I would argue that the benefit of solving this problem mentioned is far outweighed by the large downsides of using proprietary software.

orblivion 8y ago

The argument is that people don't bother to keep their verified connections up to date. But come on, how often to MITM attacks happen? For those rare cases where people are doing stuff important enough that it becomes a possibility, I would guess the security conscious individuals would become more diligent. For the rest of us, it seems that doing it on occasion is still worth it. As I understand, Signal is designed to never indicate over the wire who has checked safety numbers. Thus, a MITM anywhere on the network creates a risk of becoming discovered, which is a cost in itself.

hopler 8y ago
What's the point of using an encrypted chat at all if you don't care if it's hacked?
- orblivion 8y ago
  It's not care vs not care, it's a cost-benefit analysis.
  - atonse 8y ago
    This is a great point, however as many security researchers will tell you, the cost of an exploit goes down exponentially over time. Yesterday's hash attack that required $100m supercomputer will require a $10k GPU, which is 5 years will require a $100 GPU. (Not talking about the math changing, but it's been more about weaknesses in S-boxes and other parts of older hash functions that get slowly chipped away) Similarly, yesterday's system that takes an attacker 3 days to MITM your machine, will take 3 hours, and then will be somebody's python script that installs and aggregates millions of exploits. So in general, the cost and benefit variables are constantly changing under us.
    - orblivion 8y ago
      Actually I was referring to the cost to the user who wishes to protect themself. Signal is designed to be fairly low "cost" i.e. easy to use. If they can find a way to make it more secure without making it harder to use they should and probably will do it. For most cases, the benefit of privacy probably doesn't warrant going through more trouble than this. For those cases where somebody needs more protection, there's a way to go through a little more trouble to use Signal more diligently (agree with important parties not to change keys for a period of time). To your point though: the cost of executing MITM doesn't just include the equipment, it includes showing ones hand by being discovered.

sdenton4 8y ago

(A very tiny fwiw): you /can/ create a backup in signal and use it to transfer seamlessly to a new device, without triggering new safety number checks. The user flow sucks, but it is possible.

metildaa 8y ago
Backups are only possible on Android, and the most recent Signal non-beta builds have had this feature broken, making backups you had useless. Unless your willing to open a bug and be a pest for 2 weeks (and still have access to your old phone/leave it registered) I wouldn't plan on retaining your messages or keys across phones. Its a huge weak point of Signal.
- aibara 8y ago
  Hmm, that's odd. I very recently had to cycle through using four different phones (one was dying, two ended up being defective, finally got a decent one), and each time I successfully transferred all my messages to the next. I thought that just transferred your messages though, not your keys (I could be wrong there). But it is a bit silly that you need to manually move the file from the old phone/backup location to the new one without some in-app option to do so.
  - metildaa 8y ago
    This was circa 1 month ago that I had this issue, and it was fixed in the beta build of Signal Android after a few days. Moving to the beta channel doesn't really help if the old device is not avaliable anymore, as the backup is still not usable.
- izacus 8y ago
  Even in that case, you could only backup on device storage, had to write down (!) a huge set of numbers and manually copy files around. The whole flow is awfully terrible to any user - at least WhatsApp can sync your profile over Google Drive. Last time my phone died, I lost all of my Signal group memberships, because the app is incapable of transfering those to a new phone without backup... and it's also incapable of doing the backup automatically. Those UX choices continiously baffle me - it's like authors didn't learn anything from the failure of PGP.

i_am_proteus 8y ago

Their solution seems reasonable, but why not allow export of an (encrypted) private key for use on other devices?

eridius 8y ago
Keybase allows you (nay, encourages you) to set up a "paper key", which is a private key that you store offline (e.g. print it out and stick it in a safe). You can then use this paper key to provision new devices. This way if you lose all of your devices simultaneously (or just have one device to begin with) you don't need to go through an account reset to add a new device. Note that even with this, any new device added using the paper key still generates its own independent private key. Having per-device private keys is important to be able to revoke devices, and to be able to track which devices were responsible for any given action.
- i_am_proteus 8y ago
  To quote Kanye Omari West[0], "I like this." [0]https://youtu.be/PsO6ZnUZI0g?t=95 https://youtu.be/PsO6ZnUZI0g?t=95
deleted 8y ago
[deleted]

hopler 8y ago

Keybase's UI is still bad. It prominently highlights the "Let them (the eavesdropper) in" button, and the warning has so much red that it's hard to read the text.

hprotagonist 8y ago

I actually _do_ reverify safety numbers out-of-band every time they change.

threwawasy1228 8y ago
I would actually like to see some numbers or a survey on how many people actually do this. Anecdotally I don't think I know a single person who ever verifies safety numbers out of band. Of the approximately 50 people I use to talk on signal with regularly not including large group chats of people I don't know as well, not a single person has ever tried to reverify me nor have I tried to reverify any of them. Would be cool to see what the numbers are for reverifications.
- rabidrat 8y ago
  At some point, continued conversation is verification enough. The MITM isn't a catfish, and they are going to have a hard time keeping up the charade acting like someone you chat with regularly.
  - ryukafalz 8y ago
    It doesn’t have to be a human in the middle though - if you’re in a position to MITM, it’s much more scalable to put a bot in between that relays messages between one person and the person they intend to communicate with.
    - faho 8y ago
      In that case you can just ask if they got a new phone.
- hprotagonist 8y ago
  I normally don't do this in-person, but some kind of out of the loop approach is something i do every time. One time i got a postcard from a friend with their safety number on it and nothing else. I recognized their handwriting to complete the loop.

Pxtl 8y ago

I'm not a security guy, but wouldn't the most seamless approach be to encrypt the key collection with a master password and store the encrypted key collection on the server? So on a new device you'd download the encrypted key collection and then decrypt it locally? If they forget their password, they can re-upload it from a validated device with a new master password.

syn0byte 8y ago
Biggest issue is single point of failure for total access to all devices. Get\guess\beat out the master password and its game over on all connected devices.
- IshKebab 8y ago
  The way it works now is with SMS authentication which is not really secure at all.
  - eridius 8y ago
    Where does Keybase use SMS authentication?
    - chupasaurus 8y ago
      Nowhere, IIRC you have to add new device from an already trusted ones. GP probably thought about other messengers.
- eridius 8y ago
  Not only that but this also enables offline attacking of the password. If you can compromise the Keybase server and grab the encrypted passwords, you can then attack it at your leisure with whatever computing power you can scrounge up, over whatever time duration you want. And when you break it, as long as any of the included devices are still on the account, you'd have complete access to everything. Requiring existing devices to be actively involved in provisioning a new device prevents all of this.

fiatjaf 8y ago

Very reasonable criticism. I'm now happy for never having used Signal.

DoubleMalt 8y ago

I love Keybase. Actually I tried to install the app a couple of days ago. But there is no version on F-Droid and the version on Play Store has Firebase Analytics baked in Is there a plan for a clean F-Droid version?

jxcl 8y ago
They also have no (as far as I could find) way of installing Keybase without root permissions on Linux. I tried looking for a way to install keybase without "sudo dpkg -i keybase.deb" but had no luck. In the end, since the people I'm working with use it, I had to spin up a VM to install it in so that keybase wouldn't mess up my Debian installation.
- giancarlostoro 8y ago
  Are there many apt packages that don't require root / sudo privileges to install something?
  - xrisk 8y ago
    There should be a way to just `make install` it to whatever location you want, IMO.
    - giancarlostoro 8y ago
      You can also extract the files from a .deb file and place them wherever you so desire as well though if you really want to be that extreme about it. I see no issue with installing things as root, it's running random software as root that's the real issue. If you verify what the post-install script for a Debian package is doing (ie not running anything not already on the system) you should be fine to install KeyBase and any other package as root. Packages don't run the software they install unless it installs a daemon or something.
      - jxcl 8y ago
        My concern isn't that I don't trust Keybase to not be malicious, it's that I don't trust their packaging to not conflict with other packages. Debian has a very strict packaging process and it effectively guarantees a stable system, but installing packages that don't follow the standards that their packagers have could cause problems on upgrades. I don't know enough about Linux to verify that the Keybase package does everything right; I delegate that to the Debian packagers and don't install anything as root unless it's from the Debian package repositories. Any software that I need that isn't in the distro is installed to a folder inside my home folder, where it might conflict with other custom installed software, but at least it won't break the entire system.

dcbadacd 8y ago

The thing I find about this article the nicest is that they published the audit result document. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...

idlewords 8y ago

Much of the criticism of how gently WhatsApp and Signal handle key resets misses the mark. Widespread adoption of end-to-end encrypted messaging is an effective countermeasure to passive collection and blanket surveillance. In order to get that widespread adoption, you can't be showing people skull-and-crossbones warnings every time they swap out a SIM card. Speaking from my experience getting journalists and political campaigns set up with signal in 2017-2018, the early scary key change warnings were off-putting to people and made them reluctant to continue with the messenger. At the time, I was in contact with 100-150 people via signal and quickly ran out of patience with anyone who insisted on a safety number check. But the UI at the time encouraged that level of paranoia. I continue to believe that making key changes as painless as possible for users is the correct approach as long as there are ways to harden this behavior in the settings, for the benefit of the far smaller set of people to whom MITM attacks are a credible threat.

BostonEnginerd 8y ago
I agree with your assessment about key change management. With that said, I do like the device history trail that Keybase uses. Keybase has a better multi-device story - in that it has a multi-device story at all. I understand what they're trying to do preserving message history - I do prefer my conversations to be ephemeral by default. I'm OK with the compromise that Signal has made with key management -- there are people that I really care to have private communication with, and people who I prefer to have private communication with. I verify the former, and don't bother with the latter unless we happen to be bored together in the same room. On a side note, thanks for your efforts over the last two years!
- idlewords 8y ago
  The user base for Keybase and Signal is so different that it makes sense to have such different behaviors. Thanks very much for the kind words!
  - chb 8y ago
    I would have thought that these two groups would have more in common than not. Who do you think constitutes these disparate user bases and how are their perceived expectations different?

abhinai 8y ago

In an ideal world, I would love to use a really secure app for communication. However, my choices are limited when most of my friends are on WhatsApp or Signal. That is just the unfortunate reality of the way social networks work.

idlewords 8y ago
Both WhatsApp and Signal are secure apps for communication, and your friends are right to use them.

tosh 8y ago

If there was an iPad app that works in landscape mode I’d be able to switch most of my groups from other apps to keybase.

josh2600 8y ago

Show us the server: https://github.com/keybase/client/issues/6374 https://github.com/keybase/client/issues/6374

giancarlostoro 8y ago
Why I like Wire in this regard, they seem to have their front-end and back-end open sourced. I believe their servers AGPL licensed, but it still allows you to run your own instance. Sadly people are highly more likely to use either Signal or KeyBase than Wire, which I think is my favorite since it doesn't tie you to a phone number (tip: register from the desktop first), and you can delete all your account information.
- kerouanton 8y ago
  I also use and like Wire for the same reasons.
  - giancarlostoro 8y ago
    I use all I have listed, I like the UI for KeyBase the most personally especially the way it handles social proofs where you need to verify yourself through a crypto key or another device. I wish Signal would just do this, but it's too married to phone numbers that it's suspicious in that simple regard. I use Signal with my wife, so for us to verify our keys it's very easy and simple.
icelancer 8y ago
"Open source project"
99052882514569 8y ago
It's on their roadmap, guys.
- Arkanosis 8y ago
  Is it? In the aforementioned issue, keybase-travis says “it still isn't”.

unsignedint 8y ago

Requirements to use phone number, let alone, as an identifier is major complaints I have for many of messaging apps. It really limits usable cases as I have plenty of people I would love to interact but not necessarily want provide my phone numbers. I love Keybase for this aspect, but something I don't like about it is its device name handling. They don't allow decommissioning old device names, so I end up having 'MyLaptop' 'MyLaptop 1' 'MyLaptop 2'...

regnerba 8y ago
A few months ago I deleted Facebook and part of doing that looked into what messaging app to move to. I needed something easy to use as I wanted to get my family on it but also really didn't want to link my phone number. I ended up landing on Wire and so far have found it to be really good. You can register with phone number but it is not required and you can register with an email instead.
malgorithms 8y ago
Oh interesting. I don't think we've talked about this decision publicly, so I can write about it for a second. Not letting people re-use a device name is an inconvenience, I admit, but arguably it's not like other cryptography inconveniences, where people are confused, troubled, etc. We figured people would say "huh, weird requirement" and pick a different name and move on. The goal is a 1-1 mapping between devices (keys) and these names. So whenever we need our UX to talk about a key, it can talk, safely, about it in terms of device names. Once committed to your chain of signatures, "Laptop-Warhol" means a specific device key, and it can't be used again. So, for example, if one of your Keybase installs wants to tell you "oh, Laptop-Warhol just added a new device, iPhone-Vangogh" then it doesn't need to look like this: "Key 34858234589234895897234598734 added key 90123845890230948234234324." If Laptop-Warhold could mean multiple devices (keys), well then we'd need to start talking about the keys. Which is a nightmare for usability. A lot of this decision was driven by something we've seen with apple devices. Every now and then I'd get a popup on my computer - say when updating iOS - that said something like "you just started using iMessage on a new device, 'chris's iphone'. if you don't know what this you should freak your shit out." well - it has basically said that so many times with the same names over again, that I can safely assume that it's a near-useless warning. Note I mean unique to you; 2 different users on keybase can name their devices the same. Generally speaking...it's been a goal from the beginning that names on keybase are meaningful. Similarly if you look up "chris" in in our merkle tree (which is pinned to bitcoin) that leads to a deterministic chain of signatures. inside that chain, where I mention "work-imac-warhol", you're guaranteed to see the same answer as I am. So "chris" is as good as a key fingerprint or safety number. And so is my device name.

cyphar 8y ago

Matrix handles this by exposing the device keys to the user so they can make decisions about whether to trust new devices (and I believe identity key changes mean you wouldn't be in your rooms anymore -- but in order to change identity keys you would have to delete you entire Matrix account on the homeserver). If a new device has shown up, your messages will be blocked from being sent until you verify the new device. To be fair, it is too easy to blaze past the warning -- and it can happen often in large rooms. As a result, it's a little bit cumbersome at the moment, but with device cross-signing coming down the pipe and the new verification system (which is much better than Signal's IMHO -- you just check both devices have the same string of 7 emoji on their screen) it's getting a lot better.

IshKebab 8y ago
Yeah that sounds like it doesn't really solve it at all (yet).
- cyphar 8y ago
  It does partially solve the issue of continuing to send messages without any sort of warning -- new devices mean your messages won't send unless you hit the "send anyway" button (and in your settings you can disable the send anyway option). It also solves a problem that Keybase has which is that all new devices are automatically trusted (so a compromised device can just register more devices to avoid being blocked). To be fair, this makes for a pretty bad UX -- and the Matrix folks are working on cross-signing to make this easier -- but it is very useful for a user to be able to detect new devices to be detected (especially their own).
ajvs 8y ago
Yeah usability-wise it's not the greatest right now until those features get added, but security-wise it's better than Signal/WhatsApp in warning you about detected new keys.
UncleMeat 8y ago
This works great for incredibly tech savvy people who have an offline way of verifying public keys. This is completely and utterly useless for 99.9% of whatsapp's 1b+ users. Heck, how many times have security-aware software engineers blazed through the "THIS KEY IS NOT TRUSTED" warning from ssh?

inetknght 8y ago

> Similarly, in SSH, if a remote host's key changes, it doesn't "just work," it gets downright belligerent: Funny enough, I have ranted to friends/coworkers about sysadmins completely replacing machines and not telling anyone. How do I know it happens? BECAUSE OF THIS EXACT WARNING.

xrd 8y ago

Smart stuff and fun: "Did you though, or did you just scroll down here?"

miopa 8y ago

I'm wondering why the article fails to mention that there is a sufficiently good and easy mechanism to compare and verify the new safety numbers. You just talk to your peer and read the numbers - and the peer can verify them. This will fail when AI software gets really good at imitating voice in real-time during casual talk, but we're not there yet (or - if that is my threat model, I'll find an out of band way to verify)

zaroth 8y ago
A sufficiently good mechanism from a cryptographic standpoint, but which from a usability perspective totally falls down because people never do it. It’s a very worthy goal to make these events rare and scary so that users might actually bother reading those numbers out loud to each other.

broahmed 8y ago

Let's not forget what Signal and the Signal Protocol (used by WhatsApp) have achieved: making end-to-end encrypted chat EASY and accessible for the masses, for many of whom "security" is password123. It's important in our post-Snowden world.

godelski 8y ago
I'm not sure why this is downvoted. The reason WA has so much popularity is that it is easy to use and you could use wifi. Signal is not as easy to use (less features) but more secure and so privacy conscious people like it. But people don't like switching to Signal because "it is hard". Making a more secure app is good, but we have to question "do we want people using pretty good e2e or do we want to make the perfect app first?"
- mikekchar 8y ago
  I don't think your question is as easy to answer as you might be implying. I certainly don't know the answer. My main concern is: what is the downside to "pretty good e2e"? Without understanding what that means, we can't evaluate the situation. "Good" is better than "best" if "best" is not available seems obvious, but it certainly isn't true in a lot of cases. If I tell you that X secure and you trust it to be secure, when it actually has problems -- that might be worse than me telling you that X is not secure. People are bad at evaluating risk. If I want to pass notes in class and don't want my teacher to know what the note says if I get caught, then rot-13 is probably "good enough". But if I'm a whistle-blower for a government agency, my security needs are quite a bit higher. We can never make a perfect app, but I'm not sure I could define what "good enough" looks like for the general populous. It's completely reasonable to me that different groups have different opinions on the matter -- and I think that's a good thing.
  - godelski 8y ago
    > If I tell you that X secure and ... Is Signal or WA in that regime? Literally the only reason I don't use WA is because it is owned by FB. But as far as I'm aware both are cryptographically secure. Yes, I'm aware WA has a metadata problem. So what's good enough? I'd say that if you need a state actor to crack it, I'll call it good enough. At least for the general populous. Any more difficulty that can be made is a bonus imo. Clearly we can't get a perfect e2e app. So at what point in time do we say "we also need other features that people want so that they'll use our app". That doesn't mean "stop working on encryption" (you can never stop that) but "we're at a good enough point to start targeting a larger market." I think something like Signal is there. Stop focusing on the security geeks and bring in the general public.

el_cujo 8y ago

"How often do resets happen? Answer: if you're using WhatsApp or Signal, all the freaking time. With those apps, you throw away the crypto and just start trusting the server: (1) whenever you switch to a new phone; (2) whenever any partner switches to a new phone; (3) when you factory-reset a phone; (4) when any partner factory-resets a phone, (5) whenever you uninstall and reinstall the app, or (6) when any partner uninstalls and reinstalls. If you have just dozens of contacts, resets will affect you every few days." I guess I don't have "dozens of contacts", but getting a new phone/resetting a phone isn't really that common of a thing in my circle. I feel like for the average user, they wouldn't do this with their phone more than like once every year or two. So I guess if you have like 600 people you talk to on these apps regularly then that works out to daily, but for me at least this isn't that big of a deal and was pretty much understood from the outset.

mhluongo 8y ago
I've had to do it 4-5 times myself (busted phone, water, upgrade). I think it's possible to export the keys (at very least the message history) to avoid this, but if I need to verify with someone I actually fall back on... Keybase :)
idlewords 8y ago
Also (I believe) when you swap out SIM cards, which is routine behavior in parts of the world.
- viraptor 8y ago
  That's not the case. You don't even need a sim card for WhatsApp.
  - icebraining 8y ago
    Can confirm, I used to run it on a WiFi-only tablet, having confirmed the number of my featurephone (which didn't have WhatsApp at all).
  - OJFord 8y ago

ex3ndr 8y ago

Having encrypted backups means that you are throwing away PFS.

foxhop 8y ago

Keybase is awesome. I wish they would take my money as a customer. I don't want to see them to away.

z3t4 8y ago

Key rotation is a hard problem. One idea is to host the public key in a txt domain record. For example yourname.com that you can also use for your email and blog.

deleted 8y ago

[deleted]

wDcBKgt66V8WDs 8y ago

Kind of OT but the belligerent SSH message example they used is good comedy

arendtio 8y ago

Actually, I think it is wrong to call it TOFU as it simply doesn't require the user to opt-in to anything. Instead, it seems more like the thing the XMPP people call 'blind trust before verification' [1]. I am not quite sure if it is exactly the same as 'blind trust before verification' changes its behavior as soon as you explicitly verified the keys. That way everybody can use somehow e2e encrypted messages, but if you really care about the security you validate your keys and get a real trusted e2e encryption. [1] https://gultsch.de/trust.html https://gultsch.de/trust.html

throwawaymath 8y ago

There are a few claims made here which I'd like to see clarified. In the spirit of transparency, let me declare upfront that I use Signal but I am not affiliated with them, and I don't really have a dog in the race here. I'll reference the published NCC security review[1] for this comment. Overall I'm happy to see a published cryptographic review of this protocol. First, under "The Full Security Picture" heading in this article, it's claimed that forward secrecy is supported via time-based exploding messages. Pages 19 and 20 of the NCC report explain that, "The default chat protocol does not allow for forward secrecy since the same keys can retain indefinitely on a users device." So forward secrecy is not assured by default under this chat protocol, is that correct? The NCC report goes on to say that, "Exploding messages introduce mechanisms for message deletion and forward secrecy; however, it is not clear to the user that keys and messages could remain on their device beyond the period specified during message creation." I interpret this to mean that there is a way to assure forward secrecy - which is exploding messages - but you're not making that explicit in this announcement. This seems a little disingenuous to me because in your FAQ, the first answer criticizes Whatsapp for compromising forward secrecy using the backup feature, but you don't have forward secrecy enabled by default in your chat protocol. Likewise, this announcement makes a point of mentioning how other apps require you to trust the server due to resets, and why trusting the server is bad. But page 20 of the NCC report explains that, "While the default Chat encryption protocol does provide for message confidentiality and integrity, it does not provide for security in the face of device and server compromise, as keys and ciphertext are stored for a potentially indefinite period of time." So is it correct to say that unless users specifically enable exploding messages for their conversation (which is not the default), they actually do need to trust the server? There are also a few drawbacks to the ephemeral messaging scheme NCC found that I think should be explicitly disclosed, because they don't require too much technical detail: 1. There is no deniable authentication on the default chat protocol. While exploding messages provide deniable authentication, this property fails in a group with more than 100 participants. It's fair to question whether that's a realistic place to expect deniable authentication, but it should probably be called out. 2. Exploding messages are based on the local client's system clock. Therefore it's possible for an exploding message to be indefinitely retained on another device by e.g. manipulating the local time. ___________________ 1. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018_Public_Report_2019-02-27_v1.3.pdf https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...

malgorithms 8y ago

I don't know the moderation policy on title changes at HN, but I just changed the title of the post. Internally at Keybase - and thanks to a conversation with a peer - we've been feeling pretty guilty about calling out a specific project that we think is basically the gold standard outside Keybase. We'd rather focus on the positive solution to the problem (which Keybase has implemented), rather than just pointing a giant finger at any other services which have the problem we're trying to address. I think I personally will sleep better tonight this way. Still we want this conversation to continue.

sctb 8y ago
Sleep well! We've updated the headline here.
- malgorithms 8y ago
  <3
acrispino 8y ago
From the updated FAQ: How DARE you attack Project XYZ? This still reads as unnecessarily acidic to me, given the update notice at the top of the article.

h4t 8y ago

I've been using keybase for quite some time now and I absolutely love it. I suggest everyone give it a seriously try and check out some of the popular public teams chats before finalizing your opinion of it. I'm glad I did.

diaz 8y ago
Best thing for me besides chat working with some friends regularly is the amazing file sharing option between multiple parties easily.

chr1xzy 8y ago

I can never get keybase to address this article about them: "Keybase, we have a problem." https://freehuman.fr/posts/20238f40da8b01357816236af097d2ae https://freehuman.fr/posts/20238f40da8b01357816236af097d2ae Maybe user /kbModalduality can

chupasaurus 8y ago
A happy KB user, let's bring that article down: 1. A server runs KBFS which syncs data with the server. No one could stop you from disabling it on startup and running wherever you need it. 2. Any app running without AppArmour/SELinux or outside of network namespace could get your real address. Latter is relatively easy to set up, I'm running VPN by default and all the apps inside are running only in the namespace with VPN tunnel device. 3. Last time I checked I could make my own package. 4. I don't have time to check it atm. 5. Link for audit results is somewhere in the comments on this post. 6. Works with uBlock on. 7. Some paranoia rant without looking how KB works: it's push/pull mode, all messages are stored as files you could sync. 8. Based on previous points. 9. Each connection is under TLS. Plaintext messages could be read via RAM, and if someone could read it, KB would be the last problem. 10. You could make your own. 11. Fixed. #ls -l /keybase would show you the symlink KBFS_NOT_RUNNING to /dev/null, but shows correct directories under user running the app. 12. Hello GDPR. 13. Like everyone in the world does. 14. Bad outro.

DINKDINK 8y ago

If a single party in a chat has their keys reset that's not a MITM attack because a MITM would need to rekey to both parties. If the two clients communicate via at least one uncompromised service to communicate that their counterparty's keys have been reset, they might be able to detect a MITM Keybase's example Cozy Street is not a MITM attack (i.e. an attacker has inserted themselves between two parties and can get the plaintext), it's just impersonation. If it was a real MITM attack both Alice and Bob would get rekey notifications, unless they both confirm whenever they get a rekey notification a MITM attack is possible. I also think that crypto is stuck in the early 90s by thinking real world meetups are the only way to authenticate keys. If you know what your chat friend sounds and looks like, willing to submit a video, and don't think your adversary can fake such a proof, a simple video of you reading your pubkey/safety number is sufficient. Is that scalably practical? no but it is possible. That said: keybase is doing cool novel work, I commend them for advancing the state of the art.

peterwwillis 8y ago

I like it! They should apply this to the problem of TOFU in HSTS. For many HTTPS sites it's trivial to hijack them by getting a user to switch to a different device, as the devices' apps often don't synchronize HSTS databases.

solatic 8y ago

Why can't we just have government certificate authorities for the average Joe? Ultimately, while people may have very little trust for the government in general, the one thing that people do trust the government for is establishing identity. We use government ID papers to establish our right to work, to open bank accounts, to enter legal agreements, and to cross borders. Why should communications be any different? We don't need to trust the government with the content of the communications (and we shouldn't), by not providing the government with the private keys. But why can't I get the government to sign a public key for me? The issue it raises is whether people will eventually get locked out of society if the government decides to get antagonistic with somebody by revoking their public key and refusing to issue a new one, given a society where such a scheme is popular. But we don't have any sort of such protection today - the government can seize your passport, seize your driving license, freeze your bank accounts. A society in which the government solves identity issues for the digital age is only a net improvement over the status quo.

feanaro 8y ago
Not only that, but the government will inevitably stay requiring you use a key pair which they will supply. Citizens won't know the difference and won't fight it back hard enough. Hello government-sanctioned cryptographic surveillance. Best not to open that particular can of worms.
dannyw 8y ago
Because not everyone wants to communicate under a singular identity.
Couto 8y ago
Certain countries like Portugal, Estonia and so on, already emit digital certificates stored inside the chip of every citizen's ID card. I believe these cards are made by Gemalto[1] [1] https://www.gemalto.com/govt/identity https://www.gemalto.com/govt/identity