4 ms·

The current state of the art in this space is Signal, which offers participant consistency, destination validation, forward secrecy, post-compromise security, c

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.

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.