There’s another dimension (covered in the link to soatok’s excellent tutorial, but not in the article): Do you want auditability or deniability? If someone compromises my key and decrypts the DM that you sent me, then can they post something online that proves that they wrote the message? This has been a problem with DKIM and is why some people are advocating rolling over DKIM keys periodically and publishing the private keys: so that you can verify on receipt that a message is genuine, but you can’t prove this to other people later (unless you recorded a hash of it in a public log on receipt, or similar, but that doesn’t help an attacker who compromises your historical DMs). This feels particularly important given the goal:
The end goal of my proposal is that I want to be able to send DMs to queer furries that use Mastodon such that only my recipient can read them.
This presumably means that you also want to receive DMs from queer furries, some of whom probably live in areas where having those messages published would lead to persecution. How do you design an E2E scheme such that you can validate the message on arrival as coming from the sender, but someone who later compromises your client (or server and injects malicious JavaScript into your system) can use this validation to publicly prove that a particular individual sent a message?
Unrelated, but the discussion of Signal really reminded me of my pet peeve with Signal: that it conflates knowledge of an identity with possession of a capability to communicate with the owner of that identity. I would love to be able to give someone a one-time code that lets them add a single entity to my Signal contacts, but then stops working, so they can’t pass it on to spammers (or can’t leak it to spammers after a compromise). With something like Mastodon, this could be combined with a mechanism for distributing these capabilities along the social graph, so I could pass on the ability to DM folks that I talked to.
I don’t see how you can do E2EE in a web-based service. Or rather, I know how, but it requires trusting the JS the server sends you, which means trusting the server. Which defeats the point of E2EE in a federated system where the server is run by some volunteer in Ruritania whom you’ve never met and don’t know by name.
I know you ultimately have to trust the software that’s doing the encryption, but in other E2EE systems like iMessage the software isn’t downloaded on literally any page view, and it’s only the app or OS vendor you need to trust this way, which is (a) one entity, and (b) one that’s very visible and has a lot of reputation to lose if they abuse this.
PS: Thanks for posting this. I’m working on E2EE myself, in a different system, and it’s useful to read more about how others have done it.
I don’t see how you can do E2EE in a web-based service. Or rather, I know how, but it requires trusting the JS the server sends you, which means trusting the server.
Users shouldn’t expose their keys to the webserver. This means using end-to-end encryption outside the context of the website. This implies a Browser Extension.
I wish there was a way to do this with something like WebAuthN or FIDO, where the secret key is in a TPM of some sort and persists on the device. I know this works for authentication, but I don’t think you can use it to encrypt arbitrary data. This still doesn’t solve the issue of migrating devices, but it would be a neat way to securely store the private key, ensuring it never gets to the server.
I do eventually want to write a W3C specification for using a FIDO2-compatible device to encrypt/decrypt keys in a browser context. That would give us a better key management solution than the ones listed on that page.
Honestly I think that mastodon would do itself a big favor by asking people to use native clients. Beyond this problem (web extensions are of course mentioned, and I think you can create isolated contexts that would be very hard for hijacked instances to deal with), there are loads of issues that come from “we are passing around instance-specific links to things”, that basically completely disappear if you are using a client.
“The follow button semantics are weird” native client resolves auth issues with HTTP. “Why is this link from instance A being hosted on instance B when shared” protocol links to allow clients to receive real things. “E2EE trust semantics” again, native clients mean your trust matrix is different (and theoretically easier to audit).
One side note on the web-based service issue, is that with a lot of effort mastodon instances could make it so that you could outright save an HTML page locally on disk and have that be “the software”, for people who are worried. There is still an audit step involved there, but it’s not impossible!
But ultimately the fact that instances host web interfaces (rather than “there are instances, get your client software from X/Y/Z”) is generating constant usability concerns.
You can have whatever download semantics you want with service workers and progressive web apps (PWA). You could only let the app update with the user’s permission, you could make all updates be signed by a predefined set of keys, etc.. This closes the gap between native apps and web apps and makes it more of a spectrum.
If you rely on a browser extension then you’ve just ruled out 99% of people who are not able to, or will not, install a browser extension in their environment.
Interesting. How does the end user know the web-app has these policies, though? If I create a Mastodon account at randomsite.io, can I verify that they are using an unmodified copy of a front end codebase I trust, and that it can’t be changed without my consent?
99% of people who are not able to, or will not, install a browser extension
[citation needed]
Back to my original point, 99% of people will install apps on their phones/tablets though.
You can verify the update policy by reading the (typically < 100 LOC) service worker code. They could also check the hashes of retrieved assets against some known value, which again you could inspect and compare against some other source with the values in the service worker source.
EDIT: I’ve just dug deeper and I think I’m wrong. This only applies to all the website assets excluding the service worker script itself. This is still checked for updates regardless, and the browser will install the new version either on next load or immediately if it calls skipWaiting. Although that is also visible to the user (the SW has an incrementing version controlled by the browser).
That 99% of people is based on the following: Take one of the most popular extensions like ublock origin, add up the number of installs across all browsers (23 million) divide by the number of internet users (~5 billion). this gives 0.5%. If this is the most popular extension then this would be an upper bound.
This is really important work! Thanks for sharing. It would be an absolutely wonderful thing to have as part of the standards, or even as an optional thing for servers to embrace.
fediverse is architecturally similar to email, with each party having a provider who may store metadata. so you have to weigh the risks introduced by email clients against the risk of using new JavaScript crypto implementations.
Signal has an instant-messaging UX, which is different from a mail UX and not suitable for the same use cases. Also, key management is lacking: I can change my phone whenever, and the worst my recipient will get is a small note saying “oh by the way Loup changed its phone”, without explicitly warning them that my previous keys are now invalid, and they probably want to authenticate me all over again.
Oh, and Signal requires your phone number. They try their hardest not to misuse it, but that’s still a deal breaker for some people.
Signal is explicitly only distributed through official palmtop stores (Google’s or Apple’s), to get it anywhere else you are supposed to compile it yourself. This means a phone keyboard and a small screen.
Signal has desktop apps for Mac, Windows, and Linux. It needs a mobile to create an account, because they outsource identity management to the phone network, but you can still use it on a big computer with a keyboard. Video conferencing also works on the desktop app.
It’s not just the phone network. They only have apps for the ‘primary’ application on Android and iOS. You can’t use a Linux phone, KaiOS, etc. I very much dislike giving into this duopoly. As such, I don’t think it’s as suitable as folks act (and I’m someone that convince friends and family to use Signal to get them off of Messenger, LINE, and SMS).
Uh, no. I can use the Signal app on my desktop and on my iPad when my phone is turned off. I can send and receive messages and use voice and video calling, and inspect my message history, all without my phone being turned on.
The desktop apps do not get copies of messages sent before they were trusted. This is also true of the mobile apps, because Signal does not store message history server side and so you need to back it up and restore it to the new device. Until very recently, the backups were tied to a specific app, so you couldn’t move between Android and iOS and keep message history. That is now fixed for the mobile apps but there is not yet a mechanism for importing message history into the desktop apps.
Everything that you said is true of the WhatsApp desktop clients.
Everything that you said is true of the WhatsApp desktop clients.
That hasn’t been true in a long while, those can run without your phone nowadays, and get full message history.
Considering I have to re-pair the Signal Desktop app every single day, because it claims it’s been too long, I get no message history on Signal Desktop at all. I’ve moved entirely away from Signal because it’s utterly unusable.
Considering I have to re-pair the Signal Desktop app every single day, because it claims it’s been too long, I get no message history on Signal Desktop at all. I’ve moved entirely away from Signal because it’s utterly unusable.
Have you filed a bug report? I have the Signal deskop on two Windows PCs and a Mac, and the Signal iPad client installed. I needed to re-pair when I put my phone through the washing machine by mistake, but the only messages that aren’t in my history on the other devices are the handful that were received in between installing Signal on the new phone and re-pairing the other devices. I don’t know what’s going wrong for you, but I can confirm that this is not a problem that I have encountered, or seen anyone else encounter, so you’d be likely get help on the issue tracker if you can help narrow down the root cause.
From what I can tell from my own debugging, it’s intended behavior. If you stop using a device for a few days/weeks, it’s supposed to automatically log you out.
It just so happens that I’ve got many devices logged into signal, and only open signal desktop when I actually need to read/write messages, which can be several weeks apart for a single device.
Nothing. And from the look of it nothing ever will. But I do believe we could have a similar UX experience to email (federated servers & native clients), only secure. The Fediverse actually looks promising, though I know very little of it.
There’s another dimension (covered in the link to soatok’s excellent tutorial, but not in the article): Do you want auditability or deniability? If someone compromises my key and decrypts the DM that you sent me, then can they post something online that proves that they wrote the message? This has been a problem with DKIM and is why some people are advocating rolling over DKIM keys periodically and publishing the private keys: so that you can verify on receipt that a message is genuine, but you can’t prove this to other people later (unless you recorded a hash of it in a public log on receipt, or similar, but that doesn’t help an attacker who compromises your historical DMs). This feels particularly important given the goal:
This presumably means that you also want to receive DMs from queer furries, some of whom probably live in areas where having those messages published would lead to persecution. How do you design an E2E scheme such that you can validate the message on arrival as coming from the sender, but someone who later compromises your client (or server and injects malicious JavaScript into your system) can use this validation to publicly prove that a particular individual sent a message?
Unrelated, but the discussion of Signal really reminded me of my pet peeve with Signal: that it conflates knowledge of an identity with possession of a capability to communicate with the owner of that identity. I would love to be able to give someone a one-time code that lets them add a single entity to my Signal contacts, but then stops working, so they can’t pass it on to spammers (or can’t leak it to spammers after a compromise). With something like Mastodon, this could be combined with a mechanism for distributing these capabilities along the social graph, so I could pass on the ability to DM folks that I talked to.
I don’t see how you can do E2EE in a web-based service. Or rather, I know how, but it requires trusting the JS the server sends you, which means trusting the server. Which defeats the point of E2EE in a federated system where the server is run by some volunteer in Ruritania whom you’ve never met and don’t know by name.
I know you ultimately have to trust the software that’s doing the encryption, but in other E2EE systems like iMessage the software isn’t downloaded on literally any page view, and it’s only the app or OS vendor you need to trust this way, which is (a) one entity, and (b) one that’s very visible and has a lot of reputation to lose if they abuse this.
PS: Thanks for posting this. I’m working on E2EE myself, in a different system, and it’s useful to read more about how others have done it.
Luckily, I already wrote the part that addresses this:
I wish there was a way to do this with something like WebAuthN or FIDO, where the secret key is in a TPM of some sort and persists on the device. I know this works for authentication, but I don’t think you can use it to encrypt arbitrary data. This still doesn’t solve the issue of migrating devices, but it would be a neat way to securely store the private key, ensuring it never gets to the server.
I do eventually want to write a W3C specification for using a FIDO2-compatible device to encrypt/decrypt keys in a browser context. That would give us a better key management solution than the ones listed on that page.
maybe the idea of an eternally stored, private message is a fallacy.
Are short-lived keys like at https://privatebin.info be helpful?
Honestly I think that mastodon would do itself a big favor by asking people to use native clients. Beyond this problem (web extensions are of course mentioned, and I think you can create isolated contexts that would be very hard for hijacked instances to deal with), there are loads of issues that come from “we are passing around instance-specific links to things”, that basically completely disappear if you are using a client.
“The follow button semantics are weird” native client resolves auth issues with HTTP. “Why is this link from instance A being hosted on instance B when shared” protocol links to allow clients to receive real things. “E2EE trust semantics” again, native clients mean your trust matrix is different (and theoretically easier to audit).
One side note on the web-based service issue, is that with a lot of effort mastodon instances could make it so that you could outright save an HTML page locally on disk and have that be “the software”, for people who are worried. There is still an audit step involved there, but it’s not impossible!
But ultimately the fact that instances host web interfaces (rather than “there are instances, get your client software from X/Y/Z”) is generating constant usability concerns.
You can have whatever download semantics you want with service workers and progressive web apps (PWA). You could only let the app update with the user’s permission, you could make all updates be signed by a predefined set of keys, etc.. This closes the gap between native apps and web apps and makes it more of a spectrum.
If you rely on a browser extension then you’ve just ruled out 99% of people who are not able to, or will not, install a browser extension in their environment.
Interesting. How does the end user know the web-app has these policies, though? If I create a Mastodon account at randomsite.io, can I verify that they are using an unmodified copy of a front end codebase I trust, and that it can’t be changed without my consent?
[citation needed]
Back to my original point, 99% of people will install apps on their phones/tablets though.
You can verify the update policy by reading the (typically < 100 LOC) service worker code. They could also check the hashes of retrieved assets against some known value, which again you could inspect and compare against some other source with the values in the service worker source.
EDIT: I’ve just dug deeper and I think I’m wrong. This only applies to all the website assets excluding the service worker script itself. This is still checked for updates regardless, and the browser will install the new version either on next load or immediately if it calls skipWaiting. Although that is also visible to the user (the SW has an incrementing version controlled by the browser).
That 99% of people is based on the following: Take one of the most popular extensions like ublock origin, add up the number of installs across all browsers (23 million) divide by the number of internet users (~5 billion). this gives 0.5%. If this is the most popular extension then this would be an upper bound.
This is really important work! Thanks for sharing. It would be an absolutely wonderful thing to have as part of the standards, or even as an optional thing for servers to embrace.
obvious solution is just email right? and you can link it from the web page with mailto:
So, PGP, or something else?
Obligatory links:
fediverse is architecturally similar to email, with each party having a provider who may store metadata. so you have to weigh the risks introduced by email clients against the risk of using new JavaScript crypto implementations.
Or just move the private messaging to Signal.
Signal has an instant-messaging UX, which is different from a mail UX and not suitable for the same use cases. Also, key management is lacking: I can change my phone whenever, and the worst my recipient will get is a small note saying “oh by the way Loup changed its phone”, without explicitly warning them that my previous keys are now invalid, and they probably want to authenticate me all over again.
Oh, and Signal requires your phone number. They try their hardest not to misuse it, but that’s still a deal breaker for some people.
We’re discussing direct messages here, which are a good fit for Signal.
The way I see it, for E2EE DMs in fedi, we have
….
99. security LARPing using PGP.
You mean short direct messages?
Signal is explicitly only distributed through official palmtop stores (Google’s or Apple’s), to get it anywhere else you are supposed to compile it yourself. This means a phone keyboard and a small screen.
Any future solution has to be mobile first for any meaningful mass adoption.
I already see people referring to Mastodon, like Twitter before it, as “an app”.
My point is, Signal is mobile only.
Signal has desktop apps for Mac, Windows, and Linux. It needs a mobile to create an account, because they outsource identity management to the phone network, but you can still use it on a big computer with a keyboard. Video conferencing also works on the desktop app.
It’s not just the phone network. They only have apps for the ‘primary’ application on Android and iOS. You can’t use a Linux phone, KaiOS, etc. I very much dislike giving into this duopoly. As such, I don’t think it’s as suitable as folks act (and I’m someone that convince friends and family to use Signal to get them off of Messenger, LINE, and SMS).
Oh… I stand corrected then.
Thise aren’t real apps, they forward everything through the phone, and can’t access message history at all.
Uh, no. I can use the Signal app on my desktop and on my iPad when my phone is turned off. I can send and receive messages and use voice and video calling, and inspect my message history, all without my phone being turned on.
The desktop apps do not get copies of messages sent before they were trusted. This is also true of the mobile apps, because Signal does not store message history server side and so you need to back it up and restore it to the new device. Until very recently, the backups were tied to a specific app, so you couldn’t move between Android and iOS and keep message history. That is now fixed for the mobile apps but there is not yet a mechanism for importing message history into the desktop apps.
Everything that you said is true of the WhatsApp desktop clients.
That hasn’t been true in a long while, those can run without your phone nowadays, and get full message history.
Considering I have to re-pair the Signal Desktop app every single day, because it claims it’s been too long, I get no message history on Signal Desktop at all. I’ve moved entirely away from Signal because it’s utterly unusable.
Have you filed a bug report? I have the Signal deskop on two Windows PCs and a Mac, and the Signal iPad client installed. I needed to re-pair when I put my phone through the washing machine by mistake, but the only messages that aren’t in my history on the other devices are the handful that were received in between installing Signal on the new phone and re-pairing the other devices. I don’t know what’s going wrong for you, but I can confirm that this is not a problem that I have encountered, or seen anyone else encounter, so you’d be likely get help on the issue tracker if you can help narrow down the root cause.
From what I can tell from my own debugging, it’s intended behavior. If you stop using a device for a few days/weeks, it’s supposed to automatically log you out.
It just so happens that I’ve got many devices logged into signal, and only open signal desktop when I actually need to read/write messages, which can be several weeks apart for a single device.
This will still cover maybe 90% of use cases.
Anyway, what working encrypted email solutions exist?
Nothing. And from the look of it nothing ever will. But I do believe we could have a similar UX experience to email (federated servers & native clients), only secure. The Fediverse actually looks promising, though I know very little of it.
I think if we manage to pull off E2EE in the fediverse, those solutions can be applied to email as well!
seems more natural to start with email, rather than something like mastodon which bundles a lot more cuntionality.
How about using matrix? The protocol supports E2EE and handles federated servers much better than Signal. And it’s free software.
Everyone keeps suggesting Matrix, but I strongly urge everyone to read up on the design flaws and reconsider strongly.
What about OMEMO?
I’d rather implement MLS.
Most of those findings are implementation bugs and have already been fixed. Genuine issues in the spec are rare, and afaik already being worked.
A new matrix implementation integrated into mastodon would be unlikely to make the same implementation mistakes.
you can’t use Signal if you don’t have a smartphone.
Um, you just used the word “email” in a thread about security. 🤯
(I know about PGP and S/MIME, but the fraction of people using those, or able to install them without expert help, is indistinguishable from 0.0.)