this post was submitted on 12 Oct 2025
125 points (97.7% liked)
Privacy
42558 readers
581 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
When it comes to initializing the connection, It's true that those identifiers (or perhaps more accurately, addresses) are susceptible to collisions in a "global space". But they are temporary, ephemeral addresses (they are discarded after use and/or expiration), and the space is astronomical so chances of collision are tiny, and even in the rare event of a collision you still have a step in which you verify a fingerprint code that's independent of the address, related to the individual local device.. so you have a second factor authentication of sorts, if you are adding a person and the code does match then you can be pretty sure it's the correct person, since both the shared address and the internal locally-stored key match.
If there's a permanent global fingerprint code isn't that, well, the opposite of what the marketing says? Why is that not a unique user identifier?
The fingerprint (or you can also call it "security code", it's just a code for verification), is generated from the combination of the locally stored encryption keys from each side of the conversation, it will be different every time. I believe it's also not technically required by the protocol that the same encryption key should be used for all conversations (although I don't really know if the client does generate a new one every time or keeps reusing the same, that's up to the implementation I believe).
Makes sense, thanks for the explanation