6 ms·

I think there are a bunch of scenarios in the real world that complicate this (we spent a lot of time working around these at Keybase): People get new phones a

I think there are a bunch of scenarios in the real world that complicate this (we spent a lot of time working around these at Keybase): People get new phones all the time. If I've done a secure key exchange with you, and then you get a new phone, how do I know you're the same person after? Do you move key material between phones? Or do you get your old phone to sign the public key of the new phone? What if I got a new phone because I lost my previous phone? Do I just repeat the handshake from scratch with everyone? This is very important, because people losing their phone is pretty common. If there's an "it looks like so-and-so got a new phone" dialog, any user with enough friends will see it pretty frequently. People will get used to tapping "ok". And then an active adversary can attack them, by pretending to be a new phone. In the other direction, say I do use my old phone to sign my new phone's key, and then later my old phone is stolen. How do I tell people that my old phone isn't me anymore? Do I publish another signature of some kind? How do I make sure that all my contacts receive that signature? Does this part require trusting the server to send messages faithfully?

tialaramex 7y ago
I was mostly thinking about the generic out-of-box capabilities you'd get these days, which include Forward Secrecy, rather than compromises made in the name of usability for software like Keybase. But since you're a Keybase person let's consider Keybase's compromises in particular, do they mean Jenny's bomb gets found? What can I determine: Who Jenny sent the message to? The contents of the message? Don't you consider that a pretty bad screw-up considering what your users expect?
- oconnor663 7y ago
  I'm not super keen on your chosen example of helping terrorists, since some folks (like my dear AG) act like that's all crypto is good for, and sometimes these things get taken out of context. But that said, I'll run with it. > do they mean Jenny's bomb gets found? No, private messages are private like you expect. > What can I determine: Who Jenny sent the message to? Yes, as with all end-to-end encrypted chat apps, the server knows who is talking to whom, because it's responsible for routing. Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing. > The contents of the message? No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps. > Don't you consider that a pretty bad screw-up considering what your users expect? You might be misunderstanding how Keybase works. You're right that Keybase messages are not forward-secret by default. (Forward secrecy is available, however. Keybase calls these "exploding messages".) In part, you could call this a usability decision. But it's also related to the fact that Keybase lets you have multiple devices on your account. When you sign on a new device, it would be kind of weird to be in all these conversations where you have no view of the message history. On one device, you can scroll back, but on the other device, you can't? Most users wouldn't understand why, and they'd consider it broken. (You could implement a history transfer protocol, but it's easy to imagine how you could wind up in a partially-transferred state by losing WiFi at the wrong time. Also there's no way for adding a new device from a paper key to transfer chat history.) Forward secrecy also gets more complicated when you consider multiple devices. The typical Signal ratchet setup is designed for each user having a single device. You can treat multiple devices as separate participants in a conversation, but that doesn't work well if one of my devices is "in the drawer". If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key? Do we still have forward secrecy in that case? At what point do we evict it from the conversation? Exploding messages are a better solution for this problem, but they're also not a great default for most users. (For typical messages, you generally want them to still be there if I don't read them for X hours.) Anyway, enough about forward secrecy. You were asking about security. Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key. There is no TOFU. And because there is no TOFU, there are also no routine dialogs telling the user "oops, this person lost their phone, we need to renegotiate keys." Instead, a full account reset is a big deal, and it breaks lots of things. As it should! Otherwise, adversaries in the middle can pretend to be me and act like I've reset my account. All end-to-end apps are vulnerable to this absolutely practical attack, except (to my knowledge) Keybase. Forgive the wall of text :)
  - tialaramex 7y ago
    > I'm not super keen on your chosen example of helping terrorists It's a motivating example. You don't want to help Jenny and neither do I, but if the technology actually works that shouldn't matter, we have no discretion. If we have discretion in protecting Jenny, you can be assured that the governments sending these open letters will lean on that discretion for everybody, not just Jenny. > No, private messages are private like you expect. That's very confident considering the later caveats you introduce. > Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing. Do you think humans (this is a service for humans) need sub-second delivery accuracy? No? So, why would you ensure this when as you realise this just helps an adversary? By throwing away everything better than second precision you make essentially no difference to the user experience but you mix everything up into 3600 events per hour that all have lots of indistinguishable participants. > No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps. Again this is a service for humans. You can _choose_ to send exactly 1326 bytes over the wire out of some desire for brevity, but for humans padding everything to the nearest whole packet (~1500 bytes) greatly improves their privacy at essentially zero cost. > If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key? Well do you? My understanding is that in the Keybase design the answer is "Yes" and so most likely your confident "No" earlier will be wrong. Somewhere I can probably find keys that let me read Jenny's message and I am motivated to search for them. > Exploding messages are a better solution for this problem, but they're also not a great default for most users. Keybase's exploding messages are greatly fictionalized for the user experience. It reminds me of Mission Impossible. What the user sees is the message vanish instantly after a short timer, like a tape seemingly consumed in flame before their eyes on the TV show https://www.youtube.com/watch?v=8VQfhyDP6vw https://www.youtube.com/watch?v=8VQfhyDP6vw The reality is more like making Mission Impossible, the visual effect is achieved in a separate shot and pasted on, you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two later the message is gone largely because nobody cares any more, not because it really "exploded" as depicted after just a few minutes. > Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key. So, given my involvement with the Ten Blessed Methods (the means by which a Certificate Authority decides that ycombinator.com is really ycombinator.com in the Web PKI) you might expect me to be very sympathetic to this approach. But I'm not. It ends up as a very woolly "Web-of-trust" type system and we know humans don't reason about those well. The technical argument may be "You can be confident that this Keybase account is controlled by someone who also controls the oconnor663 account on Hacker News or by someone who controls Hacker News itself or by someone at Keybase" but the human understanding is invariably just "This is Jack O'Connor" which is... misleading if I'm generous. Forcing humans to do in person verification if they care, and allowing them to just not care is, in my not at all humble opinion, a better choice. I am very confident that messages from Al are really from Al having verified that our Signal numbers match, and not in the least bit confident that messages saying they're from Carol are really from Carol, and all the clever work at Keybase can't make a dent in that anyway because Carol leaves her phone unlocked on her desk. > Forgive the wall of text I'm the very last person who should criticise anybody on that front.

tialaramex 7y ago

I was mostly thinking about the generic out-of-box capabilities you'd get these days, which include Forward Secrecy, rather than compromises made in the name of usability for software like Keybase. But since you're a Keybase person let's consider Keybase's compromises in particular, do they mean Jenny's bomb gets found? What can I determine: Who Jenny sent the message to? The contents of the message? Don't you consider that a pretty bad screw-up considering what your users expect?

oconnor663 7y ago
I'm not super keen on your chosen example of helping terrorists, since some folks (like my dear AG) act like that's all crypto is good for, and sometimes these things get taken out of context. But that said, I'll run with it. > do they mean Jenny's bomb gets found? No, private messages are private like you expect. > What can I determine: Who Jenny sent the message to? Yes, as with all end-to-end encrypted chat apps, the server knows who is talking to whom, because it's responsible for routing. Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing. > The contents of the message? No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps. > Don't you consider that a pretty bad screw-up considering what your users expect? You might be misunderstanding how Keybase works. You're right that Keybase messages are not forward-secret by default. (Forward secrecy is available, however. Keybase calls these "exploding messages".) In part, you could call this a usability decision. But it's also related to the fact that Keybase lets you have multiple devices on your account. When you sign on a new device, it would be kind of weird to be in all these conversations where you have no view of the message history. On one device, you can scroll back, but on the other device, you can't? Most users wouldn't understand why, and they'd consider it broken. (You could implement a history transfer protocol, but it's easy to imagine how you could wind up in a partially-transferred state by losing WiFi at the wrong time. Also there's no way for adding a new device from a paper key to transfer chat history.) Forward secrecy also gets more complicated when you consider multiple devices. The typical Signal ratchet setup is designed for each user having a single device. You can treat multiple devices as separate participants in a conversation, but that doesn't work well if one of my devices is "in the drawer". If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key? Do we still have forward secrecy in that case? At what point do we evict it from the conversation? Exploding messages are a better solution for this problem, but they're also not a great default for most users. (For typical messages, you generally want them to still be there if I don't read them for X hours.) Anyway, enough about forward secrecy. You were asking about security. Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key. There is no TOFU. And because there is no TOFU, there are also no routine dialogs telling the user "oops, this person lost their phone, we need to renegotiate keys." Instead, a full account reset is a big deal, and it breaks lots of things. As it should! Otherwise, adversaries in the middle can pretend to be me and act like I've reset my account. All end-to-end apps are vulnerable to this absolutely practical attack, except (to my knowledge) Keybase. Forgive the wall of text :)
- tialaramex 7y ago
  > I'm not super keen on your chosen example of helping terrorists It's a motivating example. You don't want to help Jenny and neither do I, but if the technology actually works that shouldn't matter, we have no discretion. If we have discretion in protecting Jenny, you can be assured that the governments sending these open letters will lean on that discretion for everybody, not just Jenny. > No, private messages are private like you expect. That's very confident considering the later caveats you introduce. > Even if you consider a message service based on Tor, an attacker who controls the entire network can often figure things out by looking at sender and receiver timing. Do you think humans (this is a service for humans) need sub-second delivery accuracy? No? So, why would you ensure this when as you realise this just helps an adversary? By throwing away everything better than second precision you make essentially no difference to the user experience but you mix everything up into 3600 events per hour that all have lots of indistinguishable participants. > No, but you can see the length. Again this is true of all all end-to-end encrypted chat apps. Again this is a service for humans. You can _choose_ to send exactly 1326 bytes over the wire out of some desire for brevity, but for humans padding everything to the nearest whole packet (~1500 bytes) greatly improves their privacy at essentially zero cost. > If I never turn on that old laptop for months at a time, do we keep encrypting every message for its current key? Well do you? My understanding is that in the Keybase design the answer is "Yes" and so most likely your confident "No" earlier will be wrong. Somewhere I can probably find keys that let me read Jenny's message and I am motivated to search for them. > Exploding messages are a better solution for this problem, but they're also not a great default for most users. Keybase's exploding messages are greatly fictionalized for the user experience. It reminds me of Mission Impossible. What the user sees is the message vanish instantly after a short timer, like a tape seemingly consumed in flame before their eyes on the TV show https://www.youtube.com/watch?v=8VQfhyDP6vw https://www.youtube.com/watch?v=8VQfhyDP6vw The reality is more like making Mission Impossible, the visual effect is achieved in a separate shot and pasted on, you could actually trivially recover the message for some time after it "explodes" across a variety of devices which each have their own keys. A month or two later the message is gone largely because nobody cares any more, not because it really "exploded" as depicted after just a few minutes. > Keybase solves the key distribution problem in a totally different way from other end-to-end apps, by having you use social media to prove you own your key. So, given my involvement with the Ten Blessed Methods (the means by which a Certificate Authority decides that ycombinator.com is really ycombinator.com in the Web PKI) you might expect me to be very sympathetic to this approach. But I'm not. It ends up as a very woolly "Web-of-trust" type system and we know humans don't reason about those well. The technical argument may be "You can be confident that this Keybase account is controlled by someone who also controls the oconnor663 account on Hacker News or by someone who controls Hacker News itself or by someone at Keybase" but the human understanding is invariably just "This is Jack O'Connor" which is... misleading if I'm generous. Forcing humans to do in person verification if they care, and allowing them to just not care is, in my not at all humble opinion, a better choice. I am very confident that messages from Al are really from Al having verified that our Signal numbers match, and not in the least bit confident that messages saying they're from Carol are really from Carol, and all the clever work at Keybase can't make a dent in that anyway because Carol leaves her phone unlocked on her desk. > Forgive the wall of text I'm the very last person who should criticise anybody on that front.