Librem one e-mail plans to delete non-encrypted emails… Why not auto-encrypt them with user’s own key? That way it’d be safer and would not make users lose data (important non-encrypted mails). Could that be done with autocrypt? What do you think?
Where did you read that? Cannot be true, >99% of emails are not encrypted today.
I am talking about end-to-end (GPG) encryption, not transport server<>server TLS.
As a matter of fact, that was not a statement, but rather a question – or even a feature suggestion.
Think of it not as p2p encryption, but as the user autoencrypting its own emails and deleting the original one (the non-encrypted), instead of just deleting the original one…
Does that male sense?
Not really, at least not on the technical level.
There are 2 main parts here: transport encryption and content encryption.
For the 1st part you have to trust them, for the 2nd part you can encrypt your emails and then they
are only being relayed by them.
At any point they receive the email in plain text on the server side. So the way they store it is largely
irrelevant, since if:
- You trust them, use GPG on top of that and you are good to go
- You don’t trust them, don’t use their service, host your own server, it’s easy
A good practice for them would be having that server Full Disk Encrypted. The rest of it is just technically
impossible, because of the way Dovecot works (maildir or mbox formats) and encrypting it means
you won’t have access to your old emails anymore, only via some specific software which will use
the key somehow. No other email provider did it since it goes to my options 1 and 2.
Again, Purism lying to their users on https://librem.one#faq
@luisfsr yes, you can prevent unencrypted mail from being wiped from the server by re-sending it to yourself with encryption.
To automate this, Purism would need to know your
private key. You might trust Purism, but if they have the key, they also have to hand it over to authorities. That’s why automatic encryption is not really what you want.
EDIT: wrong. See below.
It could be a semi-automatic process embedded in the Librem Mail client. It could retrieve the unencrypted mail, encrypt it, and then delete the original. Either triggered automatically or with an “Encrypt!” button for the users.
I think many users would consider this a nice feature, but I don’t expect it in the very near future.
You got it! This way the server wouldn’t have access to user’s private keys.
BTW, the server could encrypt mails without having the private key, so it could either be done locally (mail app) or by the server. The private key could stay only with the user to decrypt the emails. Is that correct?
I’d like a feature like that.
Better if it was done semiautomatically, by the mail app side, thus users would select only the important mails, knowing that the unimportant ones would be deleted within 30 days.
Actually yes i think you’re right. Didn’t think about that.
But maybe some user interaction would prevent a false sense of security.
Encrypting after receiving is just not the same.
Yes, indeed it’s not the same. Sadly people generally find it hard to encrypt mails, so the vast majority of mails are unencrypted. Maybe it’ll change with autocryp.
And also, doing it with user interaction would save server disk space, which I think is fair.
Mailfence (I think? I tried them a year ago among many others when I was looking for a gmail/protonmail replacement) offers this already. In fact, Purism wouldn’t need the user’s private key.
This is PGP we’re talking about. There are 2 keys, and one of them is known and public by definition, to allow other people to encrypt emails to you.
Mailfence does it by having your public key, allowing them to encrypt emails to you only on receipt, no user interaction needed save for providing the public key one time. This way, only you on your email client with your private key could decrypt the emails.
I’ve been thinking about implementing that on my self-hosted email server as well, somehow…
The threat is still there however, since the email itself is unencrypted from the moment it is send by the other person until it is encrypted by the Librem server, so this all protects only part of the story, but would be an improvement: a mailbox nobody else can read, not even Purism or whoever is snooping on their servers.
They actually already mentioned that feature in this post.
As the Mail service evolves, we’ll add the following features:
Encrypt-on-receipt: If you share your public key, we can encrypt your mail on receipt. Or, no more temporary mail.
I think it’s important that it’s clear to users once they do add the feature. Perhaps they could have it as an option with a warning in to your Librem One account settings.
How effective would that be in practice? They will still receive the mail unencrypted (after TLS) and will
have to pass it to the gpg module for encryption, even if it takes microseconds they still have a copy of
your email. Largely gimmicky feature, which will require an attacker to gain access to the Librem mail
server to exploit, but then you have much bigger issues than that. I say an attacker deliberately because law enforcement can ask them to mirror the received mails to an unencrypted storage, and encrypt them later as usual so the user won’t know the difference.
Everybody understands the limitations of this approach, and it has already been pointed out.
No need to state the obvious.
It helps for mails received before an attack / request. Not more. Not less.
actually i doubt everybody understands this - maybe sometimes stating the obvious isn’t so bad.
That would be the exact purpose of this. It can’t replace end-to-end encryption, as the server will see plain content on receiving anyway, but nobody will be able to come after the message is stored and read its contents: exactly as if the message was deleted after a short time after receiving, except the user keeps access to it.
It shares the same shortcomings, i.e. if the server is compromised, neither deleting nor receiving and then encrypting can prevent it from exfiltrating the plain messages. Use GPG (or S/MIME), kids!