3 ms·

Dunno about that. XMPP and Matrix seem to have solved this issue. Plus implementing TLS is much more difficult than implementing e2ee so I do not get the argume

Dunno about that. XMPP and Matrix seem to have solved this issue. Plus implementing TLS is much more difficult than implementing e2ee so I do not get the argument.

betterunix2 5y ago
TLS is widely supported with dozens of available implementations ready-to-use in many different programming languages and on many different platforms, and it basically comes free for any browser-based implementation. Those implementations also receive a lot of attention, and because of that library support it is much easier to update an application that uses TLS than some purpose-built chat protocol. For example, let's say a new EC attack is discovered and we have to move everyone to a different set of curves (e.g. maybe P256 is found to be insecure and we all have to switch to P521). An OpenSSL update will be pushed out a lot sooner, and will be used by far more client applications, than the updates to all of the hundreds of chat clients that need whatever chat-specific e2ee protocol updated. At the end of the day, even with all problems that exist in TLS implementations, I have a lot more faith in TLS than I do in some college student's hacked together web chat client's e2ee implementation. As for XMPP, just how widely available is OMEMO in XMPP client software? The last time I tried to deal with XMPP and e2ee I was constantly confronted with clients that did not support this or that protocol. I can't speak for Matrix, maybe it "solved" the problem, but as I said if e2ee was not part of the standard from the beginning it is going to be hard to push it out as an afterthought.
- ttybird 5y ago
  Solution: use a library for the e2ee, multiple clients and even the group that makes the standard could contribute. This is what matrix did. On the other hand Dino (xmpp) uses vala bindings for the official "libsignal-protocol-c". Your favorite curve is suddenly vulnerable? Use a library like libsodium which has a solid track record and will be updated to replace the default algorithm if there is a need. I will take signal's "hacked together" e2ee implementation over openssl. As for clients without omemo support, I did not have any issue so far.

Dunno about that. XMPP and Matrix seem to have solved this issue. Plus implementing TLS is much more difficult than implementing e2ee so I do not get the argument.

betterunix2 5y ago

TLS is widely supported with dozens of available implementations ready-to-use in many different programming languages and on many different platforms, and it basically comes free for any browser-based implementation. Those implementations also receive a lot of attention, and because of that library support it is much easier to update an application that uses TLS than some purpose-built chat protocol. For example, let's say a new EC attack is discovered and we have to move everyone to a different set of curves (e.g. maybe P256 is found to be insecure and we all have to switch to P521). An OpenSSL update will be pushed out a lot sooner, and will be used by far more client applications, than the updates to all of the hundreds of chat clients that need whatever chat-specific e2ee protocol updated. At the end of the day, even with all problems that exist in TLS implementations, I have a lot more faith in TLS than I do in some college student's hacked together web chat client's e2ee implementation. As for XMPP, just how widely available is OMEMO in XMPP client software? The last time I tried to deal with XMPP and e2ee I was constantly confronted with clients that did not support this or that protocol. I can't speak for Matrix, maybe it "solved" the problem, but as I said if e2ee was not part of the standard from the beginning it is going to be hard to push it out as an afterthought.

ttybird 5y ago
Solution: use a library for the e2ee, multiple clients and even the group that makes the standard could contribute. This is what matrix did. On the other hand Dino (xmpp) uses vala bindings for the official "libsignal-protocol-c". Your favorite curve is suddenly vulnerable? Use a library like libsodium which has a solid track record and will be updated to replace the default algorithm if there is a need. I will take signal's "hacked together" e2ee implementation over openssl. As for clients without omemo support, I did not have any issue so far.