4 ms·

“Trivially easy” causes me to raise an eyebrow. Hubris and cryptography don’t mix well. Which libraries are you using?

johannes1234321 7y ago
Given any set of modern libraries encrypting the transporr end-to-end is trivial. Still hard are verfication processes, for distributing certs/public keys and some secure memory handling if you want to protect the unencrypted message on the local machine in some way.
- marcus_holmes 7y ago
  yeah, making sure the secret keys stay secret is harder than plumbing the encryption calls together
roblabla 7y ago
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?
- 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.

Given any set of modern libraries encrypting the transporr end-to-end is trivial. Still hard are verfication processes, for distributing certs/public keys and some secure memory handling if you want to protect the unencrypted message on the local machine in some way.

marcus_holmes 7y ago
yeah, making sure the secret keys stay secret is harder than plumbing the encryption calls together

roblabla 7y ago

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?
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.