Signal Protocol already supports multi-device. We've encouraged them to enable that for Secret Conversations.
Voice/video etc are obviously straightforward; hopefully they'll continue to iterate towards support for e2e by default.
Voice/video etc are obviously straightforward; hopefully they'll continue to iterate towards support for e2e by default.
This is what I thought. If one were starting a new messaging platform, how would you implement the Signal protocol from scratch I wonder? I'm assuming for people who don't have strong security backgrounds, this means dissecting the Signal source code from Github.
That's already a bad start.
You mean inventing Signal from scratch (which is rough) or incorporating the libsignal protocol into a new messaging app?
All of the libsignal repos have a good readme that explains init [1][2] , so you can start there. Browsing Signal source is helpful not so much to understand the protocol, but to see if any special precautions were taken against side-channel and other implementation pitfalls.
I mean, you could contract moxie (hey moxie, what's your price?)
EDIT: there's also this [3] independent implementation of libsignal in golang that tries to make some targeted modifications to fit their need. Can't vouch for its quality, but it's an interesting effort nonetheless.
[1] https://github.com/WhisperSystems/libsignal-protocol-java [2] https://github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal
I swear HN has become riddled with people who want to be contrarian for the sake of being so.
I believe it's a reasonable expectation that people who implement secure messaging be domain experts in crypto AND messaging.
[1] http://security.stackexchange.com/questions/18197/why-should...
There's a saying about sex: make one mistake and you have to support it for the rest of your life. Security and cryptography are orders of magnitude worse. It's bad enough that errors compound, but it doesn't end there. You can have subtle and counter-intuitive failure modes where a single step outside the happy path is enough to completely annihilate the security of your system.
I feel there is no analogy that could capture the absurd complexity and catastrophic failure potential.
To give some background - I've been working with applied crypto since 90's, and professionally (on and off) since early 2000's. That experience is still next to worthless: I know for a fact that I am not good enough to actually implement anything that could withstand the attacks of a motivated and well-funded adversary. (Or even that of a bored PhD student.)
The best I can do is find tools and components that have been battle hardened by the handful few exceptional professionals. At least that way my hubris shouldn't amount to too much damage.