[talk] Encrypted Chat Applications (aka not Signal)

[George Rosamond]

On 2/13/20 10:45 PM, Edward Capriolo wrote:
> On Thu, Feb 13, 2020 at 1:33 PM Miles Nordin <carton at ivy.net> wrote:
> 
>>>>>>> "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.
>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> 
> Sometimes the problem isn't the app. Like in the Stone case everyone is
> asking, "how did they got the "super encrypted whats app messages?". They
> did not get them from facebook to turn them over. The problem is that some
> people do things like backup phone to icloud, or backup this to their
> watch, and sync that with their toaster. it's hard to find a vessel to read
> your super encrypted 8 time pgp'ed message and ensure the person on the
> other side is not backing up things to their toaster.

Or, just the meta data, which is why over Tor matters.

This might be worth looking at also:

https://dino.im/

Now in OpenBSD...

https://marc.info/?l=openbsd-ports-cvs&m=158159513813583&w=2

g