<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 1:33 PM Miles Nordin <<a href="mailto:carton@ivy.net">carton@ivy.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>>>> "il" == Isaac ( ike) Levy <<a href="mailto:ike@blackskyresearch.net" target="_blank">ike@blackskyresearch.net</a>> writes:<br>
<br>
    il> end to end encryption communications software they like,<br>
<br>
<a href="http://matrix.org" rel="noreferrer" target="_blank">matrix.org</a> / <a href="http://riot.im" rel="noreferrer" target="_blank">riot.im</a><br>
<br>
 - fully open-source client and server.  If they pack up their tent<br>
   and go, you can run your own netowrk without them, just like email<br>
   and XMPP.<br>
<br>
 - non-cartel federation.  Unlike irc or SMS, joining the mesh of<br>
   servers doesn't require a higher level of trust than connecting a<br>
   client, so there's no approval barrier to doing this.  You just<br>
   register in DNS and go, just like email and XMPP.<br>
<br>
 - modern features: encrypted rooms, scrollback from before you joined<br>
   kept perfectly in sync, multiple devices per user presented to<br>
   others as a single virtual identity and kept in sync (your messages<br>
   and theirs).<br>
<br>
 - the "identity server" is factored out.  There's a parallel system<br>
   running under <a href="http://vector.im" rel="noreferrer" target="_blank">vector.im</a> which attests that people own phone numbers<br>
   or email addresses, which you call "centralized," but when it's<br>
   factored out like that there are other ways to think about it.  In<br>
   any case, I haven't explored it.  I'm chatting with people on<br>
   Matrix and completely ignoring this.  We have the best-case here<br>
   because anyone calling for such features is diverted to the<br>
   existing system and prevented from compromising the core.<br>
<br>
 - modern languages (for better or worse)<br>
<br>
 - modern client platform.  It's just a web page that you go to.  The<br>
   app on the page keeps working normally when Internet goes away,<br>
   unless you press [Reload].<br>
<br>
One thing to watch out for while exploring their ecosystem is that<br>
encryption is "optional"---it has to be turned on in each room or each<br>
1:1 conversation.  This is a reasonable feature because it allows them<br>
to make bridges to irc, and it allowed them to develop incrementally<br>
without which they couldn't sustain this much complexity (the<br>
encryption is "v2" now and has been ripped out and rewritten once<br>
already).  However they're not always honest in promoting it.  They<br>
say they have support for 99 clients on qt and elisp and weechat Lua<br>
plugins and Python libraries all this great stuff, but those clients<br>
either don't support encryption or support now-useless v1 encryption.<br>
If you want a list of clients that has feature parity with <a href="http://riot.im" rel="noreferrer" target="_blank">riot.im</a>, I<br>
do not have it.  There might be a few, or it might be none at all.<br>
<br>
Another thing is more optimistic.  Currently the manual key<br>
verification you are asking for exists, but it's device-to-device, not<br>
user-to-user.  The behaviour of normal users is such that this just<br>
doesn't work at all.  They are absolute spazzes, clearing cookies and<br>
getting and discarding phones tablets and other gadgets constantly.<br>
It doesn't even need to be that frequent to undermine usability.  In a<br>
group text of five people if everyone does it twice a year that's<br>
enough that most people including me will give up on being in the<br>
verified state.  There's a project supposedly nearing completion to<br>
improve the protocol so users verify other users, not devices, and<br>
there's some workflow to add and remove devices that handles theft and<br>
doesn't trust the server.  tl;dr devices share copies of the<br>
overall-user key with each other, always wrapped by the user's login<br>
password [wave hands] in some way that the server can't unwrap, maybe.<br>
If it's not good enough for you run your own server, I guess.<br>
<br>
The last thing is just a gotcha.  You need to set up key backup for<br>
the system to act normally.  The idea here is that you have a "tier 2"<br>
password besides your login password wihch undoes PFS.  Without this,<br>
clearing cookies removes your access to scrollback because by<br>
definition that's what PFS is supposed to do, and the protocol has<br>
PFS.  The purpose of backup is not normally explained in this way and<br>
is instead phrased as some emotional nonsense over how much you trust<br>
the server.  That's not the issue, or it shouldn't be.  Key-wrapping<br>
is accepted as a legit thing now.  The new discussion is about<br>
retention limits and their effect on opsec, and the backup situation<br>
is related to that but as currently Matrix doesn't have a good<br>
retention/expire story it's not normally presented in that way.<br>
<br>
They're currently running <a href="http://matrix.org" rel="noreferrer" target="_blank">matrix.org</a> on a single-threaded Twisted<br>
Python server.  I don't understand how this can work.  There's a<br>
project to rewrite the server, which is called Synapse, into a<br>
distributed system based on Apache Kafka and several stateless Go<br>
frontends.  However they are throwing most of their energy into the<br>
client and AFAICT not making much progress on Dendrite.<br>
<br>
    il> Remember when gpg over xmpp got hot?<br>
<br>
no, I don't.<br>
<br>
I remember GPG not being reasonable on XMPP because OTR has PFS,<br>
authentication, and repudiation.  An online chat can offer all that<br>
stuff while store and foward cannot, so it should be included.<br>
<br>
I also remember them never solving the multi-device problem in the<br>
protocol, so group chats were not possible, and many messages had to<br>
be manually resent for reasons opaque to the user.  I remember it<br>
being total garbage, frankly, and everyone walking away from it<br>
because the programmers were unable to identify and fix the problems<br>
that were obvious to normies.<br>
<br>
      > SILC<br>
<br>
I think the time for this stuff has passed because of security bugs.<br>
<br>
It's ok to write programs in C++ even though "omg pointer safety."<br>
Reasonable people can disagree on this.<br>
<br>
It's not ok to write programs in C and write your own parser from<br>
string arithmetic.  It's 9000x not ok to do the same thing when crypto<br>
is involved because it leads to too many exploits.  You need to use<br>
JSON or protobufs or something so that all the code serializing and<br>
deserializing structured data has had the bugs hammered out of it.  I<br>
think running your own SILC server is a great way to get owned, which<br>
is something anyone wanting encrypted chats should care about.  There<br>
are other problems with it, but that's the show-stopper for me.<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@lists.nycbug.org" target="_blank">talk@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org:8080/mailman/listinfo/talk" rel="noreferrer" target="_blank">http://lists.nycbug.org:8080/mailman/listinfo/talk</a></blockquote><div><br></div><div>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.<br></div></div></div>