5 ms·

It isn't hubris. I've written a toy E2E encrypted messaging as well. I haven't had to write a single line of actual crypto - libraries like libsodium ensure I j

It isn't hubris. I've written a toy E2E encrypted messaging as well. I haven't had to write a single line of actual crypto - libraries like libsodium ensure I just have to tell it the kind of security I want, and it handles all the dirty work for me. The hard part then shifts to the logic: 1. Ensuring the protocol doesn't allow accidentally leaking the data to an adversary somehow. 2. Ensuring the data is secured on the endpoints (the phone) - making sure the keys are secure and can't leak, and making sure the data is only decrypted when needed and for the time period it's needed. Not that this is easy to get right either. But with crypto being an essentially "solved" problem, we get to spend more time ensuring those bits work properly.

oconnor663 7y ago
Wouldn't you say the hard part is getting someone else's key reliably?
- tialaramex 7y ago
  Yes, identity verification is certainly the hard part of setup for any secure communications system. But in modern systems the cute thing is that this only really matters at the moment it happens. It's a big problem if there is an active adversary attacking you when you try to communicate, but a moment later it doesn't matter at all. Many governments are reluctant to just attack their own citizens 24/7. It's a bit too blatant. So they're obliged to try to attack most communications retrospectively. Suppose I am an intelligence analyst and I just figured out that murderous terrorist Jenny Smith sent instructions for planting a bomb to another member of her cell on Saturday at 11:42:05 precisely using let's say Signal. I have a copy of the IP packets sending the instructions. I have essentially unlimited resources to dedicate to the task. And Jenny didn't even have a reliable way to assure herself she was sending the instructions to the right person. Surely I can do something? Right? Nope. I'm screwed. Since I wasn't actively attacking Jenny back when it happened, she got the right keys, and I can no more decrypt these IP packets now than I could travel back in time and stop her sending them.
  - oconnor663 7y ago
    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 :)
SheinhardtWigCo 7y ago
The current state of the art in this space is Signal, which offers participant consistency, destination validation, forward secrecy, post-compromise security, causality preservation, message unlinkability, message repudiation, participation repudiation, asynchronicity, speaker consistency, out-of-order resilience, dropped message resilience, computational equality, trust equality, subgroup messaging, and contractible and expandable group membership. [1] Which of these properties do you get out-of-the-box from Go’s standard library and/or libsodium? Almost none of them. The gap is enormous and not at all “trivial”. So, yes, it is hubris for OP to state that they can build a competitive protocol in “about a day”, “without me needing to understand any of the maths”, by simply stringing together Go standard library calls. I think the engineers and cryptographers who work on Signal, Keybase, etc would have a good chuckle at the suggestion that this stuff is “pretty simple and hard to get wrong”. [1] https://en.m.wikipedia.org/wiki/Signal_Protocol#Properties https://en.m.wikipedia.org/wiki/Signal_Protocol#Properties
- marcus_holmes 7y ago
  few things: I'm not building a competitor to Signal, so most (if not all) of that list is completely irrelevant for my application. I'm also totally paranoid that I have, indeed, got some of this wrong. I'm trying to find people I can trust who know more about this than I do so they can look at my code and test my application. So far everyone I've approached to look at it has said it looks OK. I've come to accept that I'll never "know" completely for sure that this is bombproof, because there just isn't any single person out there that can verify that this is bombproof. And, as Bruce Schneider puts it; security is not absolute, it's about delaying the bad people for long enough so you can catch them. Bank vaults are rated in hours (the number of hours that a competent attacker will need to get into the vault). No software implementation is 100% secure, but it can be secure enough to be useful. But building a basic protocol out of Go's standard library building blocks is pretty simple, and hard to get wrong, for given values of "simple" and "wrong". These aren't absolute, and depending on your application, may be quite low.

oconnor663 7y ago

Wouldn't you say the hard part is getting someone else's key reliably?

tialaramex 7y ago
Yes, identity verification is certainly the hard part of setup for any secure communications system. But in modern systems the cute thing is that this only really matters at the moment it happens. It's a big problem if there is an active adversary attacking you when you try to communicate, but a moment later it doesn't matter at all. Many governments are reluctant to just attack their own citizens 24/7. It's a bit too blatant. So they're obliged to try to attack most communications retrospectively. Suppose I am an intelligence analyst and I just figured out that murderous terrorist Jenny Smith sent instructions for planting a bomb to another member of her cell on Saturday at 11:42:05 precisely using let's say Signal. I have a copy of the IP packets sending the instructions. I have essentially unlimited resources to dedicate to the task. And Jenny didn't even have a reliable way to assure herself she was sending the instructions to the right person. Surely I can do something? Right? Nope. I'm screwed. Since I wasn't actively attacking Jenny back when it happened, she got the right keys, and I can no more decrypt these IP packets now than I could travel back in time and stop her sending them.
- oconnor663 7y ago
  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 :)

SheinhardtWigCo 7y ago

The current state of the art in this space is Signal, which offers participant consistency, destination validation, forward secrecy, post-compromise security, causality preservation, message unlinkability, message repudiation, participation repudiation, asynchronicity, speaker consistency, out-of-order resilience, dropped message resilience, computational equality, trust equality, subgroup messaging, and contractible and expandable group membership. [1] Which of these properties do you get out-of-the-box from Go’s standard library and/or libsodium? Almost none of them. The gap is enormous and not at all “trivial”. So, yes, it is hubris for OP to state that they can build a competitive protocol in “about a day”, “without me needing to understand any of the maths”, by simply stringing together Go standard library calls. I think the engineers and cryptographers who work on Signal, Keybase, etc would have a good chuckle at the suggestion that this stuff is “pretty simple and hard to get wrong”. [1] https://en.m.wikipedia.org/wiki/Signal_Protocol#Properties https://en.m.wikipedia.org/wiki/Signal_Protocol#Properties

marcus_holmes 7y ago
few things: I'm not building a competitor to Signal, so most (if not all) of that list is completely irrelevant for my application. I'm also totally paranoid that I have, indeed, got some of this wrong. I'm trying to find people I can trust who know more about this than I do so they can look at my code and test my application. So far everyone I've approached to look at it has said it looks OK. I've come to accept that I'll never "know" completely for sure that this is bombproof, because there just isn't any single person out there that can verify that this is bombproof. And, as Bruce Schneider puts it; security is not absolute, it's about delaying the bad people for long enough so you can catch them. Bank vaults are rated in hours (the number of hours that a competent attacker will need to get into the vault). No software implementation is 100% secure, but it can be secure enough to be useful. But building a basic protocol out of Go's standard library building blocks is pretty simple, and hard to get wrong, for given values of "simple" and "wrong". These aren't absolute, and depending on your application, may be quite low.