221–230 of 312 posts
I've been wondering about this for a while. Now both whatsapp and Facebook have this, but surely they have the encryption keys too, or how else would they seamlessly fetch your messages and decrypt them when you get a new phone? If they do, then what's the point?
I've been wondering about this for a while. Now both whatsapp and Facebook have this, but surely they have the encryption keys too, or how else would they seamlessly fetch your messages and decrypt them when you get a new phone? If they do, then what's the point?
Earlier quoted context omitted.
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.
"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.
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
Earlier quoted context omitted.
You can't run your own signal server. All accounts use phone numbers in the same namespace as ID, and all messages go from the phone to opensystems.org, further on to google, and from google to the destination phone (with lots of encryption being added and removed at various points). This has advantages (it's difficult for the Man distinguish a received signal message from other android notifications) but also disadv…
You can totally run your own server for yourself and your friends: https://github.com/WhisperSystems/TextSecure-Server (you'll have to change the server's URL in the client's source as well and compile it yourself, but that's really easy) What you won't be able to do is federate with the official servers. Oh, and there's also a WebSocket transport (used by the Desktop client) that doesn't involve Google. That just do…
I'm sorry, but is this a joke? "To not use a centralized server that you can neither audit nor trust, you have to recompile the client, but that's easy?"
This smacks of "oh, PGP for email is fiiiiiine." To say nothing of the silliness of the inability to federate.
Earlier quoted context omitted.
"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.
> 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 pre…
I swear HN has become riddled with people who want to be contrarian for the sake of being so.
Earlier quoted context omitted.
What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up when discussing in-browser crypto and could never get a satisfactory answer.
For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications). Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate…
Facebook could afford a security team just as capable as Apples security team, and make sure the js server remains secure. And if they can't, their own signing procedure can get compromised before the app is uploaded to Apple for review.
I'm still not seeing the difference. Anyone?
Earlier quoted context omitted.
> 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 pre…
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.
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...
From what is written, I understand this to mean that users can select this feature for specific conversations. That not all messages are subject to this encryption. I am not usually one for paranoia, but is anyone else becoming more suspicious about Facebooks motivations and involvement with gov? This feature is a massive boost for intelligence services dealing with unsophisticated actors. This reduces the haystack s…
Reasons from @alexstamos (CSO @ Facebook): - FBM is multi-device, and we'd like to see E2E usability improve to support this. For now, pick one device and keys never leave it - Secret conversations don't currently support popular features like searching message history, switching devices, voice/video, etc - Hundreds of millions use Messenger from a web browser. No secure way to verify code or store keys without routi…
You don't say? (not you, Facebook) How about the dozens of times Facebook disrupted the user experience of the service for its own benefit? How about the dozen+ times it changed people's settings from private to public, after people previously manually enabled a certain setting to be private, or after having a setting by default as private initially and letting people believe that such action is private? Wasn't THAT disrupting to users' experience?
Of course it was. But it benefited Facebook, and that's the difference here. They just don't want to "disrupt" the experience in a way that also hurts the company's bottom line, even if it's better for users.
In other words, it's just a weak excuse for not doing it by default, or at least allowing people to always set it as default (although knowing Facebook, I'd probably worry that they'd revert it back to non-E2E without even making it obvious that it did that. Announcing a new privacy policy change doesn't really count).
Ya know, now that it won't be such a pain to support another protocol and all, since they're doing it anyway.