Hacker News Reader

Comment by jraph | Hacker News Reader

Signal is e2ee. The point of e2ee is that you can not trust the backend code (except for clear data it actually manipulates - which is still an issue indeed - Message contents are encrypted though)

This is the case for any e2ee solutions. For instance my company develops CryptPad [1], which is a full open source office suite with e2ee. The server admins can't access your content and you don't need to trust the backend, which just passes messages and store encrypted messages. This is the whole point. e2ee has drawbacks: it's very difficult, if not impossible, to provide indexed search for encrypted content on the server, the client needs to do it which might be impractical.

[1] https://cryptpad.org/

View on HN

I really like cryptpad. Thank you for developing it.

I have used it a few times in a professional setting even when there is no need for end-to-end encryption, and it is a good experience so far.

I encourage others to try it .

> Signal is e2ee.

That still does not change anything though. The backend is unverifiable, that's a fact. Why talk about E2EE, I wasn't really talking about that.

Signal for a whole year was running a different server code and nobody even could tell that they added some cryptocoin stuff. On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner.

> On top of that, metadata, server connection and anything other than the message content is all at the mercy of the server owner.

Except to the extent that the client is explicitly designed to minimize what metadata is exposed to the server.

Yes but that still does not take care of the API logging problem.

The server can log your IP, origin of request, client details and everything related to an API call. That's what I'm mainly talking about.

But due to sealed sender it doesn't know who is sending the message, only who is receiving messages.

It has your IP, but of course it needs that, as well as every piece of network gear along the route. If you want to hide that you'd need Tor or a VPN.

> That still does not change anything though.

Of course it does. Just like PGP works fine over untrusted channels - like if I posted a gnupg ascii-armored message here.

e2ee makes all the difference - if two trusted and mutually authenticated clients are communicating with proper e2ee - the best an attacker can do is traffic analysis and denial of service...?

"the best an attacker can do is traffic analysis and denial of service...? "

That's already a lot. If the evil secret police knows when and with whom you texted, then they don't even need to know the text of the messages, to link you to the opposition. And then just extract you and then the password with force to get the rest.

Relevant: https://xkcd.com/538/

It is, but encryption is still useful, as not everyone on this planet is in reach of evil secret police and their goons and wrenches are limited.

It certainly is a lot. It's enough for a drone strike.

But almost by definition, if you have a back-end, there will be meta-data.

There's been a few attempts at getting around it, with "one-to-many" (eg opaque PGP posts to Usenet groups), Mixmasters (remailers) or onion routing. None are AFAIK truly practical with a state-level adversary.

e2ee is a good start, that doesn't mean you don't need to analyse the risks.

If, as we are saying, the client code is public and one can theoretically analyze the code and prove that messages that go out are indeed only going out encrypted, then that must change something here? At that point at least, you can only be suspicious of the cryptography itself, but I believe that is public too.

I was talking about the relevant data points other than the message content, mainly metadata.

The server can not only log IPs, but also locations, client details and a lot more. The API calls aren't proxied, they're more or less direct.

First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point.

Second, some sensitive parts of Signal backend are verifiable, assuming Intel is not compromised, because they use Intel SGX.

> First, it doesn't matter a lot if the backend is verifiable with E2E, that's the point.

E2EE is only useful for content that is encrypted. Not the API calls themselves.

That's the interesting thing about being E2EE. You don't need to verify the backend. This is a private key and ETH wallet with a separator that is obvious on decryption: YSBwcml2YXRlIGtleSBhbmQgRVRIIHdhbGxldCB3aXRoIGEgc2VwYXJhdG9yIHRoYXQgaXMgb2J2aW91cyBvbiBkZWNyeXB0aW9uCg==

Use whatever backend you want to store that.

Completely agree.

For a while I did run a fork of the Signal Server. Beyond the sheer difficulty getting it to run without the server being updated for a year during the mobilecoin launch, it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information.

While it is quite possible that they had some non-default log configuration (and hopefully the metadata leaking in the logs is fixed), if you can't run the server you can't check what data is being leaked.

Take the E2EE claim with a grain of salt if it is difficult to run a server.

> ...it was extremely disconcerting to see PHONE NUMBERS spread throughout the log messages. It doesn't take much imagination to see how you can build a network of who you are talking to (etc.) from this log information.

The intent of Signal is to provide confidentiality of message content, not any sort of anonymity. This covers like 90+% of user's threat models and it's focusing on one problem makes it very effective at solving that problem. If one also needs anonymity then communication should happen over something like Tor or I2P.

Reply on news.ycombinator.com