Signal Server code on GitHub is up to date again • Hacker News Board

Re: Signal Server code on GitHub is up to date again

#131

Post by unhammer » Wed, Apr 07, 2021, 7:33 PM UTC

woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

> The security rests only upon the open source client code. The server is completely orthogonal to security.

For Android at least, builds are reproducible https://signal.org/blog/reproducible-android/ (would be neat if there was one or more third party CI's that also checked that the CI-built app reproduces the one on Google Play Store – or maybe there already are?)

Re: Signal Server code on GitHub is up to date again

#132

Post by codethief » Wed, Apr 07, 2021, 7:38 PM UTC

codethief wrote: post #126

woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

> Whether or not Signal's server is open source has nothing to do with security This true only when you are exclusively concerned about your messages' content but not about the metadata. As we all know, though, the metadata is the valuable stuff. There is a second reason it is wrong, though: These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Si…

Addendum: Out of pure interest I just went into a deep dive into the Signal-Android repository and tried to figure out where exactly the SGX remote attestation happens. I figured that somewhere in the app there should be hash or something of the code running on the servers.

Unfortunately, `rg -i SGX` only yielded the following two pieces of code:

https://github.com/signalapp/Signal-Android/blob/master/libs...

No immediate sign of a fixed hash. Instead, it looks like the code only verifies the certificate chain of some signature? How does this help if we want to verify the server is running a specific version of the code and we cannot trust the certificate issuer (whether it's Intel or Signal)?

I'm probably (hopefully) wrong here, so maybe someone else who's more familiar with the code could chime in here and explain this to me? :)

Re: Signal Server code on GitHub is up to date again

#133

Post by iudqnolq » Wed, Apr 07, 2021, 7:43 PM UTC

woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

Focussing on whether the changes directly make things insecure is missing the point. Fundamentally this sort of security is about trust.

While it's nice to try to have Signal be resilient to attacks by the core team, there just aren't enough community-minded independent volunteer code reviewers to reliably catch them up. I doubt the signal foundation gets any significant volunteer efforts, even by programmers who aren't security experts.

That means I need to decide if I trust the Signal Foundation. Shilling sketchy cryptocurrencies is indicative of loose morals, which makes me think I was wrong to trust them in the past.

Re: Signal Server code on GitHub is up to date again

#134

Post by iudqnolq » Wed, Apr 07, 2021, 7:49 PM UTC

mindslight wrote: post #110

_dibly wrote: post #88

Earlier quoted context omitted.

Reading the other article on HN definitely helped me understand more. I think really it comes down to me not understanding why they had so much trustworthiness to begin with. They've been obscuring their code for about a year and even then, it's not like Signal has always come out and said "we love the passion our fellow developers have for our commitment to privacy and security". They just let people sell their rela…

Signal's choices never really felt right, as their justifications tended towards authoritarian paternalism - eg willfull reliance on Play services, keeping it out of F-Droid (which while flawed as Signal pointed out, seems to be the best we currently have), bottleneck centralized servers, and phone numbers as primary identifiers (?!). But the standard Free Software development/distribution model does lack in some are…

I don't agree with adding cryptocurrencies, but I was very sympathetic to the play services argument. Android is very difficult to program for, and it's even more difficult without play services.

For notifications the alternatives are noticably worse (higher battery usage because you can't coordinate request timings with other apps, an annoying permanent notification), and the leakage is minimal. If you protect your encrypted packets from Google the NSA will see them anyway.

Your custom implementation will be quite complicated, and if you only enable it for a small subset of your users it'll be a pain to debug.

Re: Signal Server code on GitHub is up to date again

#135

Post by codethief » Wed, Apr 07, 2021, 7:49 PM UTC

red_trumpet wrote: post #2

Is there any mechanism to validate that the code running on Signal's servers is the same as on Github?

As others have already mentioned there is Intel SGX and the Signal developers indeed say they use it, see

https://news.ycombinator.com/item?id=26729786

Re: Signal Server code on GitHub is up to date again

#136

Post by iudqnolq » Wed, Apr 07, 2021, 7:55 PM UTC

cortesoft wrote: post #90

danpalmer wrote: post #9

Earlier quoted context omitted.

I think the argument would be that with end-to-end encryption this is unnecessary, which is good because it's impossible. There's a counter-argument that there is still useful metadata a server can glean from its users, but it's certainly minimised with a good protocol... like the Signal protocol.

Wait, how would end-to-end encryption help this problem at all? I agree that it is impossible (currently), but not sure how E2E helps anything? E2E encryption only helps you verify WHO you are connecting to, not what they are doing with your connection once it is established.

Because the other end in E2E is your friend's phone, not a server. We call end-to-server encryption "in-flight" encryption.

Re: Signal Server code on GitHub is up to date again

#137

Post by emptysongglass » Wed, Apr 07, 2021, 8:14 PM UTC

woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

You're apologizing for a project that has repeatedly damaged user trust with excuses.

These are "valid" reasons for keeping the source code private for a year? By whose book? Yours? Certainly not by mine. I wouldn't let any other business abscond from its promise to keep open source open source in spirit and practice, why would I let Signal?

This is some underhanded, sneaky maneuvering I'm more used to seeing from the Amazons and the Facebooks of the world. These are not the actions of an ethically Good organization. And as has already been demonstrated by Moxie in his lust to power, he's more than capable of deviance. On Wire vs Signal: "He claimed that we had copied his work and demanded that we either recreate it without looking at his code, or take a license from him and add his copyright header to our code. We explained that we have not copied his work. His behavior was concerning and went beyond a reasonable business exchange — he claimed to have recorded a phone call with me without my knowledge or consent, and he threatened to go public with information about alleged vulnerabilities in Wire’s implementation that he refused to identify." [1]

These are not the machinations of the crypto-idealist, scrappy underdog for justice we are painted by such publications as the New Yorker. This is some straight up cartoon villain twirling their moustache plotting.

So now I'm being sold on a business vision that was just so hot the public's eyes couldn't bear it? We're talking about a pre-mined cryptocurrency that its inventors are laughing themselves to the bank with.

At least Pavel Durov of Telegram is honest with his users. At least we have Element doing their work in the open for all to see with the Matrix protocol. There are better, more ethical, less shady organizations out there who we can and ought to be putting our trust in, not this freakshow of a morally-compromised shamble.

[1] https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

Re: Signal Server code on GitHub is up to date again

#138

Post by exolymph » Wed, Apr 07, 2021, 8:15 PM UTC

subsubsub wrote: post #70

Given that you have said... "the bulk of users is either too stupid or unwilling to invest even the tiniest amount of effort into their privacy." I don't feel the need to pull my punches. This is the most deluded, idiotic response I've seen on hacker news in a long time. It seems unlikely that the average person (or even a non-techie person of above average intelligence - e.g. a doctor) will be able to set up matrix…

On the one hand, you're absolutely right about usability. On the other hand...

> "the bulk of users is either too stupid or unwilling to invest even the tiniest amount of effort into their privacy."

Based on my interactions with users writ large, this assessment is on the money. Normies do not care and will never care.

Re: Signal Server code on GitHub is up to date again

#139

Post by wolverine876 » Wed, Apr 07, 2021, 8:16 PM UTC

codethief wrote: post #126

woah wrote: post #96

A lot of these comments are just manifestations of the kneejerk HN "crypto bad" reflex. Here's the deal: - Whether or not Signal's server is open source has nothing to do with security. Signal's security rests on the user's knowledge that the open source client is encrypting messages end to end. With that knowledge, the server code could be anything, and Signal inc. would still not be able to read your messages. In f…

> Whether or not Signal's server is open source has nothing to do with security This true only when you are exclusively concerned about your messages' content but not about the metadata. As we all know, though, the metadata is the valuable stuff. There is a second reason it is wrong, though: These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Si…

> These days, lots of actual user data (i.e. != metadata) gets uploaded to the Signal servers[0] and encrypted with the user's Signal PIN (modulo some key derivation function). Unfortunately, many users choose an insecure PIN, not a passphrase with lots of entropy, so the derived encryption key isn't particularly strong.

If I understand what you are saying and what Signal says, Signal anticipates this problem and provides a solution that is arguably optimal:

https://signal.org/blog/secure-value-recovery/

My (limited) understanding is that the master key consists of the user PIN plus c2, a 256 bit code generated by a secure RNG, and that the Signal client uses a key derivation function to maximize the master key's entropy. c2 is stored in SGX on Signal's servers. If the user PIN is sufficiently secure, c2's security won't matter - an attacker with c2 still can't bypass the PIN. If the PIN is not sufficiently secure, as often happens, c2 stored in SGX might be the most secure way to augment it while still making the the data recoverable.

I'd love to hear from a security specialist regarding this scheme. I'm not one and I had only limited time to study the link above.

Re: Signal Server code on GitHub is up to date again

#140

Post by exolymph » Wed, Apr 07, 2021, 8:18 PM UTC

dtx1 wrote: post #79

ForHackernews wrote: post #60

Earlier quoted context omitted.

This is an unhelpful attitude, IMHO. Your best chance, as a privacy-conscious, tech-savvy individual is to push for mass-market adoption of strong encryption and good government privacy regulations that will help everyone. Lacking those, you will stand out like a sore thumb as one of a tiny number of "weirdos" using Matrix, or Brave, or Tor or GrapheneOS or whatever other hardcore self-hosted, federated niche tools y…

> This is an unhelpful attitude, IMHO. I agree. I gave up fighting for privacy for other people because they don't care. I'm now fighting for my privacy because it's a war that the normies don't care to fight. They never did. Give them a shiny app and they'll sign away their firstborn. > Your best chance, as a privacy-conscious, tech-savvy individual is to push for mass-market adoption of strong encryption and good g…

Cheers for fighting the good fight. Quixotic idealists almost never get anything done... and yet they're still the only ones who do manage it ;P

With high-variance results, but heck, that's nature.