Comment by baash05 | Hacker News Reader

Comment by baash05 | Hacker News Reader

Parent Full thread

Lets play here for a bit..

Whats App (a currently end to end encrypted message system) will have to be able to send messages to other messaging platforms.

Complications.

1. The api's of these systems (as well as the user authentication) will have to become public.

- That's really a problem for these companies, if they don't have a SingleSignOn solution.

- That's not really a problem if they use a third party SingleSignOn solution (Many use facebook or google)

2. Text that gets sent to "the other platforms" will have to be decrypted inside those platforms.

- This is a problem because they'll have to use the same (IP protected) algorithm.

OR. Whats app can decrypt the message in the cloud, and send it decrypted. Thus breaking their entire reason for being, and killing E2E coms.

BOTH these complexities open the users up for security violations.

For a group that want to allow its people to own their data, and not be tracked by cookies, this seems like a huge step into insecure coms.

I don't see a fundamental problem here - obviously the API has to be made public and free for others to implement inside the EU.

Allow users to bring their own client. Depending on particulars in resulting regulation, could also mean federation (where S2S means passing on encrypted messages, the content of which is of course encrypted).

Maybe not everyone here are aware that WhatsApp, FB Messenger and Google Talk/Hangouts/whatever were all speaking XMPP before they eventually went closed. There was a time when you could connect to all of them from the same client speaking the same protocol, and talk to people on different servers. WhatsApp's server side started as a fork of ejabberd.

The most straightforward way (assuming non-malicious compliance, which TBF may be far-fetched) for this would probably be XMPP with a well-defined set of extensions. This would not require compromising user security, nor would it require SSO.

WhatsApp still uses XMPP, but has never federated with other servers.

I think it's a stretch to make that claim unless you have evidence to back it up. The last time I saw WhatsApp protocol stuff it was certainly recognisable as something derived from XMPP, but very far from simply a non-federated standard XMPP service.

Let me preface this with a disclaimer that I’m not crypto expert so if I am saying something dumb here I would appreciate it that someone pointed it out and hopefully I’ll learn something in the process.

But I don’t get why would any of that have to be true? I don’t understand the technical requirement that would break E2EE here?

Of course you can make interoperable E2EE between platforms.

You will have to use the same open protocols which I think is the actual goal we are going for here. We already have good options in place for exactly that like https://en.m.wikipedia.org/wiki/Signal_Protocol

If that became the new standard for interoperability I would consider it a great outcome.

Why so pesimisstic. In a sane world (and probably in the world where they want to say "just use WhatsApp, we're better!") they'll say "This user is using an unencrypted app. [Paragraph about how all your nudes and contents of bank account will be stolen]. Are you sure you want to send them a message?".

In a better world, something like https://otr.cypherpunks.ca could be implemented, where the user has control of their own e2e...

Assume that.. where does the decryption take place? If not on the client app?

Now WhatsApp builds in server side decryption.

Next law: Turn on server side decryption for messages sent from user X. No need to tell them, their user agreement allows for it.

I'm pessimistic, because if a government can mess up tech, they will.

Those are not the only options. You can still do TOFU (which is effectively what WA does) as long as you share the keys and encoding - only the wrappers need to be translated. (and the message contents need to be adapted to the client of course) This doesn't break E2E unless the companies involved really want to do that.

E2E does not depend on SSO between the networks.

> will have to be decrypted inside those platforms.

Only on the client.

> (IP protected) algorithm.

I hope that they do not use some secret IP protected crypto algo...

Well perhaps not a super secret algo. But perhaps not something standard either. Something strong than a norm. Might have interesting SALTS, or something like that.

This is quite simply not something you can expect. If any part of it needs to remain secret, it is not strong.

Reply on news.ycombinator.com