This is just a query really. I wondered why Runbox does not encrypt messages at rest in our inbox as I understand some other privacy providers do. Just out of curiosity really. And are there any plans to do this? Thanks!
2 Likes
Encryption at rest is very problematic:
- Server has to create key per user, which probably has to be derived from password. It’s creation is not easy.
- IMAP/POP protocols were not designed to decrypt, so client has to detect encryption and do it on it’s own.
- It breaks searching for messages on server side, as it’s impossible to keep everything decrypted just for session/operation. It would take minutes to decrypt whole inbox to be able to search. This is why the top zero-knowledge email provider does not provide searching for emails content (only metadata like sender and subject). They can’t physically keep index of all words in emails because this technically breach the zero-knowledge. This also mean they keep subjects/senders not encrypted.
I couldn’t find information that Google keeps emails encrypted at rest, do you have such information ?
3 Likes
Thanks Dawid, that’s really helpful to know! I don’t think Gmail encrypt at rest. I assume providers like Protonmail, Tutanota and Posteo etc do and I haven’t seen any complaints about how that works, but I am not sure and could be wrong!
The contents of the server are encrypted with whole disk encryption which offers some protection but it isn’t done on a per mailbox basis which would be much better if that’s the sort of thing you are interested in.
As @DawidGoslawski has already pointed out, there would be trade-offs in some ways but the fact our new Runbox 7 web app runs in the browser makes for some interesting possiblities.
For example, it might be possible to download the encrypted data from the server and decrypt it in the browser locally. As our search index can also run in the browser there may be a solution for search too.
There is already a (not well advertised) feature in Runbox 7 to decrypt PGP encrypted messages locally in the browser. We hope to add the ability to encrypt message too. The feature isn’t mentioned too much as it’s still really us testing some ideas out for the future.
I hope that helps.
1 Like
Thanks Dave, that’s all very interesting and useful to know and makes sense even to my amateur tech mind! I’m not highly concerned about lack of encryption at rest, it is obviously common apart from for the most private providers like Protonmail. I personally would be Ok about searching content of mails being restricted but can see that would bother others and can also see the ways round that you mention. Thanks for the very informative and useful feedback!
I migrated from Protonmail to Runbox cause the top security has its issues and I wouldn’t recommend it until you have access to data that can do severe dmg to you and/or others. Simple sticking to “Inbox 0” rule and deleting Trash regularly will keep your email free of data that should be secured like documents and photos.
With Protonmail, I had to use Protonmail Bridge https://protonmail.com/bridge/ to have local access to emails unencrypted like with a normal provider. Bridge was Windows only, very buggy and slow. It was losing connection very often or in the middle of the index update process.
That’s really helpful and makes a lot of sense. Thanks!
Runbox can do the following:
Users can upload their PGP public key to Runbox. Runbox would encrypt all incoming and outgoing emails and store it encrypted. Users are able to decrypt email in their email software (Thunderbird, Outlook and etc) and in their browsers, using Mailvelope extension (https://en.wikipedia.org/wiki/Mailvelope)
Thanks David, much appreciated!
1 Like
@Dave This scheme is in active use by Mailbox.org mail provider. Most probably Runbox’s users would greatly benefit from this idea.
1 Like
Shame, this feature is unfortunately the only reason holding us back from using Runbox. Privacy friendly jurisdication, good track record, but no encryption at rest in a dealbreaker. Why?
Hi guys,
I’m new here.
Sorry to revive this old thread but I also think it is becoming more and more important to adapt services to encryptions because of (often) the lack of real protection against whistleblowers (that’s just one of many examples) but we could also speak about the problem that States have against environmentalism activists etc.
The possibility, @Dave, to give your company the ability to deny any capabilities of decryption at request of the court (unless you are telling us that there is a specific national legislation about that) and so not being able to comply is pretty important I thin and would be pretty re-assuring.
So you were right about the fact that normally whitepapers and design patterns( well I’m not sure there are officials about one who would have consensus over it) about it are talking normally about the decryption happening on the client side That’s why tutanota or proton and skiff and other in the past were going through a dedicated mail client.
But I think We can find a compromise here as others companies have succeeded to it.
Like countermail or posteo where there is a cryptostorage.
Are you willing to discuss that matter or is it really out of the question?
If you are ready to discuss that matter,
Here are some of the requirements and how to proceed for it.
First, it would be really important that the current db of password of your users would be accessible directly and certainly not from the outside of course. If access directly it should be a incomprehensible blob of data.
Which means getter and setters need to be put in place.
setters should be able to be actionable under very strict and specific conditions like at creation and the the possibly change in case for recovery account (which is already a big compromise about the real no access to user data.
Second, about the imap service, ti would not have access to the password db but the to intermediary passwd db which would be keys derived from the actual password and entropy probably, maybe OTP even. The system would not have complete information and so would not be able to decrypt the blob on its own or someone inside the system would not be able either. It would lack the password that the user is entering on his client on the imap service.
For the webmail it can be even simpler since the JS could do entire job on its own client-side.
With a clear infrastructure plan and the code available we could all work on that together…
That’s great! Can we chat? I’d love to hear more. I’m working on OpenPGP and trying to set up my mail server.
1 Like
Well since we have both runbox I suppose. But there is no xmpp server as there is in countermail for example, we can contact each other on delta chat with our adresses I suppose ?
1 Like
Just send me a pl when you are ready
1 Like
sorry for late reply, I was working on webauthn to builg a login page, and here my mail: slueth@runbox.com, so we can talk more