<div>Venturing slightly off-topic...</div><div> </div><div>31.12.2021, 03:35, "John Gilmore" <gnu@toad.com>:</div><div>> Re Signal:<br />><br />> If only Signal wasn't actually recording all our contacts permanently in<br />> their servers (under their mandatory PIN requirement), then Signal might<br />> be a useful tool for encrypted messaging. But somebody apprently got to<br />> them to undermine their users' privacy.<br /> </div><div>The reason Signal has the concept of registration lock/PIN is because the user doesn't actually know their authentication credentials, they're automatically generated for them. The nuance of having a password that the user doesn't know is how to cope with new/lost/stolen/etc devices because the user cannot simply enter their credentials and thus a quirk exists that an existing user can be registered a second time, and the PIN is intended to prevent that from happening.</div><div> </div><div>I'd also add two additional thoughts. The first is that the signal server is written in a manner that terminates SSL at one point and then the API calls are proxied over to the actual server via HTTP. This in effect means that a CALEA tap or similar could in theory collect a large amount of metadata, e.g. who messaged who at what time and so forth. There are some specifics that make this maybe not the case, for instance its possible that they're proxying over a loopback interface or because its cloud-hosted that it hits a virtual only interface and thus there is no network traffic to be collected in a traditional sense.</div><div> </div><div>The second point, and this seems to apply to all E2EE applications, is that its security still basically reduces to TLS/SSL. During initial interactions, there is a key exchange but there is no way to verify the identity of who the key belongs to and in signal this is handled by having the keys put into a certificate signed by Signal, but in the case of an active attacker that has compromised the server (whether it be via hacking or court order) they can simply replace the keys exchanged and MiTM the connection effectively reducing the security to nil. In other services, e.g. Google's implementation, they have the capacity to verify a key fingerprint, but its not clear what you would hypothetically verify it against-- its not like it's an SSH key that you generated and thus know the fingerprint.</div><div> </div><div>In effect, in order to securely use the secure messaging applications you first need a secure messaging application so that you can validate identity which leaves the question of why I would be using these other applications if I had such a thing in the first place. E2EE is still an improvement, it saves you from passive collection and collection of stored records, but it won't hold up in the face of a real-world governmental adversary.</div><div> </div><div>What's absent from all of these implementations is the "web of trust" model traditionally used by GPG/PGP/et cetera and in the wake of things like Lavabit, it seems likely that court orders for these keying materials already exist, so you're still better off using GPG/PGP and email for high-security communications.</div><div> </div>