3 ms·

Signal Protocol already supports multi-device. We've encouraged them to enable that for Secret Conversations. Voice/video etc are obviously straightforward; ho

by moxie 10y ago

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.

wmccullough 10y ago
"Signal Protocol already supports multi-device" 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.
- niftich 10y ago
  > I'm assuming for people who don't have strong security backgrounds 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 https://github.com/WhisperSystems/libsignal-protocol-java [2] https://github.com/WhisperSystems/libsignal-service-java https://github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal https://github.com/OpenBazaar/libsignal
  - wmccullough 10y ago
    It may be a bad start, but if we want to see this implemented in many products at a large scale, you'll have to expect that not everyone is a security expert. I swear HN has become riddled with people who want to be contrarian for the sake of being so.
    - niftich 10y ago
      No, I'm just repeating the oft-said maxim of 'Don't Roll Your Own Crypto' [1] (which applies in the form of know-what-you're-doing-while-implementing-someone-else's-crypto) while emphasizing that you should probably be a domain expert in the domain you're developing in. If I know nothing about High Frequency Trading or Oil Exploration, I wouldn't want to be coding for it at all, and nor would my employer. 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-shouldnt-we-roll-our-own http://security.stackexchange.com/questions/18197/why-should...
    - Ar-Curunir 10y ago
      You shouldn't have many different people implementing critical crypto code; that'll lead to horrible broken implementations and compromise of security.
    - bostik 10y ago
      Getting high-grade security right is exceptionally hard. 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.

by moxie 10y ago

wmccullough 10y ago

"Signal Protocol already supports multi-device" 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.

niftich 10y ago
> I'm assuming for people who don't have strong security backgrounds 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 https://github.com/WhisperSystems/libsignal-protocol-java [2] https://github.com/WhisperSystems/libsignal-service-java https://github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal https://github.com/OpenBazaar/libsignal
- wmccullough 10y ago
  It may be a bad start, but if we want to see this implemented in many products at a large scale, you'll have to expect that not everyone is a security expert. I swear HN has become riddled with people who want to be contrarian for the sake of being so.
  - niftich 10y ago
    No, I'm just repeating the oft-said maxim of 'Don't Roll Your Own Crypto' [1] (which applies in the form of know-what-you're-doing-while-implementing-someone-else's-crypto) while emphasizing that you should probably be a domain expert in the domain you're developing in. If I know nothing about High Frequency Trading or Oil Exploration, I wouldn't want to be coding for it at all, and nor would my employer. 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-shouldnt-we-roll-our-own http://security.stackexchange.com/questions/18197/why-should...
  - Ar-Curunir 10y ago
    You shouldn't have many different people implementing critical crypto code; that'll lead to horrible broken implementations and compromise of security.
  - bostik 10y ago
    Getting high-grade security right is exceptionally hard. 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.