4 ms·
> An open-source server is certainly a step up from Signal https://github.com/signalapp/Signal-Server https://github.com/signalapp/Signal-Server. You are spre
by lorenzhs 8y ago
> An open-source server is certainly a step up from Signal
https://github.com/signalapp/Signal-Server https://github.com/signalapp/Signal-Server.
You are spreading a lot of incorrect or misleading information about Signal in this thread. That makes it difficult to assume that you're arguing in good faith here.
- ddevault 8y agoThe server might as well be closed source. We have no guarantees that Moxie is actually running this in production and he refuses to federate with third-party servers.
- lorenzhs 8y agoThis is addressed in https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/ – using Intel SGX, it's possible for the clients to verify that the server is running the code it should be running. I'm not sure whether this is already deployed, but it refutes any claim that Signal isn't serious about your concern. I don't see how federation is related to this at all. We know you're bummed about it, you don't need to inject it into every subthread.
- ddevault 8y agoSGX is not a magic bullet, it's only part of a secure system. It's also come under some fire, check out this paper: https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp.pdf https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX... SGX alone cannot solve this problem. Even in the idealized case, you can sniff traffic on the router to find out which user IPs are talking to each other and when.
- tptacek 8y agoDid you read that work? I did: I was on the review board that made the decision to accept it for Black Hat. Could you map Yogesh's research to something Signal is actually proposing to do and explain in any detail what the actual threat you're talking about is? Thanks.
- ddevault 8y agoI could, but I'm probably ill informed. I want to hear your specific rebuttal to this: >Even in the idealized case, you can sniff traffic on the router to find out which user IPs are talking to each other and when.
- tptacek 8y agoThat's a string that appears nowhere in Yogesh's research. Are you at this point conceding that the link you cited has nothing to do with this thread?
- Sir_Cmpwn 8y agoI concede that this: >I did: I was on the review board that made the decision to accept it for Black Hat. Probably makes you more qualified to talk about SGX than me, so yes, I concede that the paper may not be relevant because your understanding of it is probably better than mine. With that, I asked you a more fundamental question, given that you are knowledgeable about this and may be able to provide an answer.
- tptacek 8y agoWhat I'm asking is whether you had a coherent argument about weaknesses in SGX based on Yogesh's research that would keep it from functioning in Signal's contact discovery scheme, or whether you saw the letters "SGX" in a thread and posted the first link you could find about issues with SGX. Maybe you should find a better link? They're out there.
- Boulth 8y ago> This is addressed in https://signal.org/blog/private-contact-discovery/ https://signal.org/blog/private-contact-discovery/ – using Intel SGX, it's possible for the clients to verify that the server is running the code it should be running Just the code inside the enclave and that's a very small amount of code, definitely not the entire server.
- tptacek 8y agoIt's funny you put it that way. You're right: the server might as well be closed source. That is the point of end-to-end encryption.
- lmm 8y agoI stand corrected - though, as another reply said, it makes little difference if you can't actually use a forked server in practice. I don't know what I could say to convince you I'm just an ordinary person concerned about my privacy, but ultimately it doesn't matter: you should definitely consider the possibility that I'm a bad actor and take nothing on faith. Equally, you shouldn't trust that Marlinspike hasn't been compromised either. A little thought experiment: Put yourself in the NSA's position in 2013. GPG has been out there for years and, despite your best efforts, you can't break it directly when users follow proper security practices. (You have to compromise those users' computers instead, and that's vastly more expensive; every time you use one of your rootkits or exploits you run the risk of burning it, so they're reserved for high-value targets). The world is suddenly a lot more interested in privacy, and while popular culture doesn't grasp the intricacies of key exchange or forward secrecy, there are enough cryptography experts around that any obvious downgrade from GPG will be noticed and picked up on (this is just after the conclusive failure of your Dual_EC_DRBG efforts). What do you do? How do you get the public to accept something easier to compromise? My answer is: you find a different front to attack GPG from. You talk up different kinds of attackers. You dangle a new, desirable security property that GPG doesn't have, and a theoretically clean construction - and then you compromise the metadata subtly, down in the weeds of usability features, letting you identify the higher-value targets. You get people used to using a closed-source build that auto-updates, and have a canned exploit ready (a compromised PRNG or similar) to use on those targets. And you get people to enter their phone numbers so that you can always track their location and what hardware they're running if you do have to attack their device more directly. Maybe I'm being paranoid, but it seems distinctly odd that we see such a push behind an app that compromises so many features that were previously thought essential to security, just as the move for encryption is finally gaining momentum.
- jdietrich 8y agoGPG has an infinitesimally small user base. Many tech savvy users still struggle to use it correctly. Moxie has explicitly stated that his aim is not to build the perfect secure messenger app, but a messenger app that provides the greatest amount of security to the greatest number of users. He has explicitly stated that he has made some design decisions that slightly compromise the ultimate security of Signal, but are necessary to establish a wide user base and avoid traps that could drastically compromise the security model because of user error. Signal is not designed for you. Highly sophisticated, highly paranoid users already have a variety of options for securing their communications. Signal is designed to provide the greatest possible amount of security to the greatest possible number of users, which necessarily requires that some tradeoffs are made in the interests of ease-of-use.