←back to thread

544 points josh2600 | 3 comments | | HN request time: 0.62s | source
Show context
bilal4hmed ◴[] No.26715700[source]
With Signal not releasing their server code and now this, I regret using and asking a good chunk of my base to move to Signal.
replies(8): >>26717453 #>>26717696 #>>26717707 #>>26717779 #>>26718534 #>>26719231 #>>26719566 #>>26720799 #
codethief ◴[] No.26717453[source]
I haven't made up my mind regarding the payments feature yet but yeah, what's up with the server code? Why hasn't it been updated in over a year?[0]

Also, why do the Signal developers trust SGX so much and have stayed completely silent about SGX vulnerabilities – even when the cryptographers whose quotes they used to put on the signal.org home page[1] are increasingly critical?[2]

Finally, why is there no open communication about major events like the Signal PIN UI fuckup last year or the server issues earlier this year? Foundation or not, if no communication is happening and they're not demonstrating that they're capable of openly admitting mistakes and learning, they're not gaining the trust of anyone.

Don't get me wrong, I've been a die-hard fan of Signal since the early TextSecure days and have convinced > 100 people to switch but I'm starting to have a bad aftertaste and some of my friends (equally big Signal fans) are, too.

EDIT: Looks like the Signal server repo[3] was updated today, as this article[4] (in German) attests to. I had last checked the repo this past weekend. I suppose the repo hadn't been updated to keep the MobileCoin thing secret but I do wonder: Why not simply create a private branch instead of risking one's reputation for openness?

[0]: http://web.archive.org/web/20210311053716/https://github.com...

[1]: http://web.archive.org/web/20200201112751/https://signal.org...

[2]: https://blog.cryptographyengineering.com/2020/07/10/a-few-th...

[3]: https://github.com/signalapp/Signal-Server

[4]: https://www.golem.de/news/crypto-messenger-signal-server-nic...

replies(2): >>26719173 #>>26723243 #
1. Ar-Curunir ◴[] No.26723243[source]
the usage of SGX here is to protect against a fairly benign adversary: Signal themselves. The alternative to using SGX in these situations is to hand over the data in the clear to Signal servers.
replies(1): >>26729266 #
2. codethief ◴[] No.26729266[source]
> a fairly benign adversary

Given the Snowden leaks and everyone's experience with what Facebook etc. do with our data, I wouldn't call that a "benign" adversary at all. Besides, even if Signal itself is benign, someone who manages to hack the Signal infrastructure might not be.

> The alternative to using SGX in these situations is to hand over the data in the clear to Signal servers.

This is not correct. The alternative would be to tell users to choose a passphrase with enough entropy. In that case, SGX wouldn't be necessary. Unfortunately, they didn't do that, so now a lot of users have chosen a short PIN and their data will be compromised should SGX ever fail to live up to its promises. (This is what I meant by "Signal PIN UI fuckup" – the word "PIN" alone suggests choosing a short number over a long passphrase.)

replies(1): >>26731814 #
3. Ar-Curunir ◴[] No.26731814[source]
Sorry, the use case I had in mind was contact discovery. Existing cryptographic protocols for private contact discovery do not scale to Signal’s numbers.