Hacker News Reader

Comment by skrebbel | Hacker News Reader

Any tldr? I have a very hard time getting through this, but as the founder of a Europe-based messaging company (https://talkjs.com), I wonder whether this is trouble.

En-to-end encryption is great but it also kills quite a number of use cases. For example, our group conversations couldn't be e2e encrypted because then users can't see the message history from before they joined it. In whatsapp this is indeed the case, but for our platform it is a core feature. Same for Slack, I suppose. Similarly, Slack search would be totally out of the door. (unless, again, you make it only search the stuff sent to you)

View on HN

"The providers of electronic communications services shall ensure that there is sufficient protection in place against unauthorised access or alterations to the electronic communications data, and that the confidentiality and safety of the transmission are also guaranteed by the nature of the means of transmission used or by state-of-the-art end-to-end encryption of the electronic communications data. Furthermore, when encryption of electronic communications data is used, decryption, reverse engineering or monitoring of such communications shall be prohibited. Member States shall not impose any obligations on electronic communications service providers that would result in the weakening of the security and encryption of their networks and services"

I interpret this as the following clauses:

* "sufficient protection in place against unauthorised access or alterations" [through]

* "guaranteed by the nature of the means of transmission used "

* "OR"

* "state-of-the-art end-to-end encryption of the electronic communications data"

aka:

- HTTPS, non-ETE: fine

- HTTP, non-ETE: not fine

- HTTP, ETE: fine

> our group conversations couldn't be e2e encrypted because then users can't see the message history from before they joined it.

Why not? Can't one of the other clients in the group send the history of the chat when a new member joins?

And when somebody steals your private key they have access to everything? Yeah, no...

Isn't that how encryption works? (Asking as noob)

Not necessarily https://en.wikipedia.org/wiki/Forward_secrecy

I think ubiquitous end-to-end encryption is the inevitable future of 1:1 and group communication. The momentum is in that direction. In your case, supporting the browser as a platform rules it out right now, but hopefully that will change when browsers provide an environment for doing serious crypto, where the server can't just quietly push down some new JS that leaks messages back to itself.

I'm in the alpha stage of building an end-to-end encrypted social network (https://sharewithsup.com, invite code: eff, currently iPhone only). Under the hood, it establishes E2E group channels between friends and uses those for everything (posts, comments, photos, events, etc). History is relayed between friends and search uses a local index, but the UX is still similar to Facebook. My point is - in addition to namedropping my app - that it's possible to find ways to implement features that at first seem hard with E2E. Just not on the web, yet.

Couldn't group chats be encrypted with a shared key that is provided to the new user by whoever invites them to the chat? The messages would still be encrypted and decrypted only at the ends.

What about removing a user from chat? What if the shared key is leaked? How do you deliver the key to the new user? Who provisions new keys if a shared key is leaked? There are a variety of problems (all solvable/already solved, yes) with the shared secret strategy, and addressing them costs money and time.

So? There does not need to be a way to get rich quick. I don't see a problem with forcing chat providers to include proper end to end encryption as a matter of consumer protection. Because we all know that otherwise, security will not be part of the minimum viable product, and the consumer can't tell the difference.

(Obviously, the state of the art answer to your technical questions is the double ratchet algorithm.)

In all honesty if you keep the key on a server you might as well not encrypt the messages to begin with (except in transmission ofc, but hey, https).

Storing the key right next to the encrypted messages makes it no more secure than ROT13'ing the messages.

The key doesn't have to be shared with the server.

Ahyes, good point.

Reply on news.ycombinator.com