Just curious if that is the case. I assume not as Lemmy does not advertise it’s encryption at all.
Would this ever be planned for Lemmy?
Just curious if that is the case. I assume not as Lemmy does not advertise it’s encryption at all.
Would this ever be planned for Lemmy?
I don’t get what makes it hard to implement the same stuff using libraries provided, encryption should be optional for servers administrators to enable
Encryption is hard to get right. Which doesn’t help when it’s essentially useless unless you get it right
https://github.com/soatok/mastodon-e2ee-specification was a thing but it doesn’t seem to be updated for months now.
Encryption is also pretty much useless if the thing performing the decryption is served by the people encryption is protecting you against. It would be trivial for a Lemmy instance to serve you backdoored JavaScript as the decryption Algo.
E2e encryption is a legal device used by companies to remove their liability to give your messages to the government. Because united states v Apple (which didn’t have a ruling but the case made was pretty strong), code is speech and the US gov cannot compel you to change your code, therefore companies that have e2e encrypted comms can say “we don’t know, we have a way of knowing but you can’t make us” whenever the US gov comes in with a subpoena.
Bear in mind this is only US jurisprudence, there exist jurisdictions in which the government could legally compel an instance admin to serve you backdoored JavaScript and read your messages.
Each crypto operation (“verify the signature of this message”, “encrypt this chunk of data with this key”) is covered by any one of a number of libraries and if you’re writing your own implementation you’re probably doing the wrong thing.
For the system that you’re trying to build (messaging system, secure boot, HDD encryption, etc) working out which one you need to when is where the difficulty is. What is the overall design of your system - how do keys get exchanged, what is important to protect etc.