[talk] Encrypted Chat Applications (aka not Signal)
George Rosamond
george at ceetonetechnology.com
Fri Feb 14 12:43:12 EST 2020
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
More information about the talk
mailing list