[talk] Encrypted Chat Applications (aka not Signal)

[Miles Nordin]

>>>>> "il" == Isaac ( ike) Levy <ike at blackskyresearch.net> writes:

    il> end to end encryption communications software they like,

matrix.org / riot.im

 - fully open-source client and server.  If they pack up their tent
   and go, you can run your own netowrk without them, just like email
   and XMPP.

 - non-cartel federation.  Unlike irc or SMS, joining the mesh of
   servers doesn't require a higher level of trust than connecting a
   client, so there's no approval barrier to doing this.  You just
   register in DNS and go, just like email and XMPP.

 - modern features: encrypted rooms, scrollback from before you joined
   kept perfectly in sync, multiple devices per user presented to
   others as a single virtual identity and kept in sync (your messages
   and theirs).

 - the "identity server" is factored out.  There's a parallel system
   running under vector.im which attests that people own phone numbers
   or email addresses, which you call "centralized," but when it's
   factored out like that there are other ways to think about it.  In
   any case, I haven't explored it.  I'm chatting with people on
   Matrix and completely ignoring this.  We have the best-case here
   because anyone calling for such features is diverted to the
   existing system and prevented from compromising the core.

 - modern languages (for better or worse)

 - modern client platform.  It's just a web page that you go to.  The
   app on the page keeps working normally when Internet goes away,
   unless you press [Reload].

One thing to watch out for while exploring their ecosystem is that
encryption is "optional"---it has to be turned on in each room or each
1:1 conversation.  This is a reasonable feature because it allows them
to make bridges to irc, and it allowed them to develop incrementally
without which they couldn't sustain this much complexity (the
encryption is "v2" now and has been ripped out and rewritten once
already).  However they're not always honest in promoting it.  They
say they have support for 99 clients on qt and elisp and weechat Lua
plugins and Python libraries all this great stuff, but those clients
either don't support encryption or support now-useless v1 encryption.
If you want a list of clients that has feature parity with riot.im, I
do not have it.  There might be a few, or it might be none at all.

Another thing is more optimistic.  Currently the manual key
verification you are asking for exists, but it's device-to-device, not
user-to-user.  The behaviour of normal users is such that this just
doesn't work at all.  They are absolute spazzes, clearing cookies and
getting and discarding phones tablets and other gadgets constantly.
It doesn't even need to be that frequent to undermine usability.  In a
group text of five people if everyone does it twice a year that's
enough that most people including me will give up on being in the
verified state.  There's a project supposedly nearing completion to
improve the protocol so users verify other users, not devices, and
there's some workflow to add and remove devices that handles theft and
doesn't trust the server.  tl;dr devices share copies of the
overall-user key with each other, always wrapped by the user's login
password [wave hands] in some way that the server can't unwrap, maybe.
If it's not good enough for you run your own server, I guess.

The last thing is just a gotcha.  You need to set up key backup for
the system to act normally.  The idea here is that you have a "tier 2"
password besides your login password wihch undoes PFS.  Without this,
clearing cookies removes your access to scrollback because by
definition that's what PFS is supposed to do, and the protocol has
PFS.  The purpose of backup is not normally explained in this way and
is instead phrased as some emotional nonsense over how much you trust
the server.  That's not the issue, or it shouldn't be.  Key-wrapping
is accepted as a legit thing now.  The new discussion is about
retention limits and their effect on opsec, and the backup situation
is related to that but as currently Matrix doesn't have a good
retention/expire story it's not normally presented in that way.

They're currently running matrix.org on a single-threaded Twisted
Python server.  I don't understand how this can work.  There's a
project to rewrite the server, which is called Synapse, into a
distributed system based on Apache Kafka and several stateless Go
frontends.  However they are throwing most of their energy into the
client and AFAICT not making much progress on Dendrite.

    il> Remember when gpg over xmpp got hot?

no, I don't.

I remember GPG not being reasonable on XMPP because OTR has PFS,
authentication, and repudiation.  An online chat can offer all that
stuff while store and foward cannot, so it should be included.

I also remember them never solving the multi-device problem in the
protocol, so group chats were not possible, and many messages had to
be manually resent for reasons opaque to the user.  I remember it
being total garbage, frankly, and everyone walking away from it
because the programmers were unable to identify and fix the problems
that were obvious to normies.

      > SILC

I think the time for this stuff has passed because of security bugs.

It's ok to write programs in C++ even though "omg pointer safety."
Reasonable people can disagree on this.

It's not ok to write programs in C and write your own parser from
string arithmetic.  It's 9000x not ok to do the same thing when crypto
is involved because it leads to too many exploits.  You need to use
JSON or protobufs or something so that all the code serializing and
deserializing structured data has had the bugs hammered out of it.  I
think running your own SILC server is a great way to get owned, which
is something anyone wanting encrypted chats should care about.  There
are other problems with it, but that's the show-stopper for me.