cross-posted from: https://lemmy.world/post/12199398
TLDR version as per Signal’s Mastodon:
Introducing usernames and phone number privacy on Signal!
We’re making it possible for people to connect with each other without having to share phone numbers. Now launching to beta users, available for everyone soon.
- New default: Your phone number will no longer be visible in Signal
- You can create an optional username to connect without sharing your phone number
- You can enable a new, optional privacy setting to require people to connect with you via username instead of phone number
A Signal username isn’t the profile name that’s displayed in chats, and isn’t visible to the people you chat with on Signal. A username is simply a way to initiate contact on Signal without having to share your phone number. (You still need a phone number to sign up for Signal.)
Create a username by going to your Settings > Profile. Your username must be unique, and can be changed at any time.
To connect with someone via username instead of phone number, type their exact, unique username.
We’re launching these updates to our beta users now, and will be turning them on for everyone running the latest version of the Signal app soon. Our goal is to listen to your feedback, make adjustments, and ensure phone number privacy on Signal is easy and useful for everyone.
You can sign up for beta to test these features. Note that Apple caps the number of iOS beta testers, and we have reached that limit. If you use Signal on iOS, you can get around this by signing up for Desktop beta, linked to your iOS account. See more: https://support.signal.org/hc/en-us/articles/360007318471-Signal-Beta
For more information: Signal’s Blog Post
Sign-up still requires a phone number… -.-"
Checkout Matrix/Element or Session,
there you can actually enjoy privacy by signing-up without a phone number/email:Session eliminated perfect forward secrecy. Big no for those who take encryption seriously.
I’d like to add SimpleX to this list, as Matrix based messengers hemorrhage metadata, and Session doesn’t have perfect forward secrecy. Also, while the Matrix protocol technically supports perfect forward secrecy, Element does not currently use it.
while the Matrix protocol technically supports perfect forward secrecy, Element does not currently use it.
No kidding? I thought that was one of the few things that set them apart from the others. Do you have any sources for that, preferably their own documentation
ETA: StackOverflow concurs that if you have encryption on a chat or group, PFS comes along with it due to the Olm protocol being heavily inspired by the Signal one.
Element itself says “It is based on Olm, an implementation of the Double Ratchet protocol popularised by Signal”, but it’s not totally clear how “based on” it is. Wouldn’t it just be Olm(/Megolm)?
Do you have any sources for that, preferably their own documentation
https://github.com/element-hq/element-meta/issues/1296
I got that from the privacyguides.org website, at:
https://www.privacyguides.org/en/real-time-communication/#element
If you look carefully on the Element website, there are never any claims that it provides perfect forward secrecy. This is intentional, and unless they change their backup keys, it will continue to stay that way. As the issue is still currently open, I can only assume it is still currently an issue.
I’ve looked at my own Element key backups before and noticed that every message has a key associated with it; is the issue then that those keys are not being discarded, and if they were discarded, they could call it PFS?
(Doing something as trivial as scrolling up a couple screens in a 1v1 conversation might trigger a server side call, at which point those keys would need to be used… Element does not store a lot of data on the client side.)
The idea with perfect forward secrecy is that by breaking one key, you aren’t able to read all the other messages. The way Element works (allowing users to share encryption keys for messages stored server-side across devices, using a shared storage system), allows for a single key to allow access to all messages. All you need is your backup phrase (or a valid login session), and suddenly not just one message is visible, but all messages are. That is fundamentally in complete opposition to perfect forward secrecy.
The way to work around this is by storing all messages locally so they cannot be decrypted simply with server access, but Element stores messages on their servers, not locally (like SimpleX does, for instance). That would allow robust backup and syncing without breaking PFS.
Is it worth noting that the single key that allows you to sign into a new device basically downloads a list of all the per-message keys, something that can also be experienced if you manually export it on one device and import it on another, even allowing you to see the JSON they use to store it?
For what it’s worth, in my 2018 era experience with the software, it was really easy to sign on to a new device without this key, but I couldn’t access old messages (they would appear, in bulk, but they would all say “unable to decrypt”)
Yes, that is exactly where perfect forward secrecy fails in Element. It allows all of the message keys to be downloaded by attacking a single point of failure. Perfect forward secrecy would necessitate that all messages and their encryption keys be completely independent, and each message would need to be broken one-by-one, as each key is completely different. What Element does with their cloud backup solution is it adds a single point of failure that results in every single message being compromised, without physical access to any device. Real perfect forward secrecy would make that impossible, as you have to break the encryption of every message independently (again, ignoring physical access to the device, because the device will always have access to all the messages anyway). It essentially invalidates many of the benefits of using a double-rachet key exchange protocol to begin with, as you can attack a single point of failure that would compromise all messages instead.
Granted, whether or not that matters to you is entirely up to you. I’m just clarifying that Element lacks perfect forward secrecy, so I have an ideological objection to my own personal use of it for anything sensitive, since there are more secure messengers out there (like SimpleX) that do have perfect forward secrecy, and many more security and privacy features (like the whole no user identifiers thing and no server side storage with SimpleX). That does of course come with the tradeoff that you can only use it on one device at a time, but everything is a list of pros and cons. Is anyone going to target you and attack you by attempting to gain access to your cloud backup keys? No, most certainly not. But the fact that it exists as an attack vector to begin with is troubling from a security perspective (again, that’s where SimpleX shines with all data being stored locally, so there is no way to access those messages on demand without physical access to the device). I personally think that the metadata issues are much worse with Matrix from an immediate privacy perspective, as that is an avenue that can be actively exploited in a much easier capacity.
If I understand correctly though, I believe we’re both on the same page. Element is still a much better option than something like Discord, but it is not without its own flaws.
This seems like a good feature.
Though, the main thing I want from Signal is back-sync (from a phone to a computer) when pairing a new device… The lack of the ability to do that is effectively a deal breaker for me. I want my entire chat history (or at least the last 90 days or so) available on my computer so I can search it/see recent context even if it’s a fresh install/new device/there’s a bug resulting in a resync being required/etc.
They’ve been working on a cloud backup feature, which might enable this.
My biggest frustration with this is that the Signal server can still be given a username and it can return your phone number as an ID.
As I understand it, the phone number is invisible to average users and isn’t transmitted between them when utilizing username-based messaging, but someone with access to Signal servers directly (read: government agents, signal employees) can get a phone number from an ID at a point in time.
