When most of your email traffic is encrypted there are two things that really start to become a problem:
- You can’t search for encrypted emails
- If the sender is using a client that supports encrypted headers, such as thunderbird, your emails will be completely unrecognisable because the subject no longer contains anything useful.
To fix this we’re going to start decrypting encrypted emails when syncing and indexing the encrypted content. That way we can make sure encrypted emails are just as usable as non-encrypted emails, at least as long as you’re using Kube.
This means that in the future you will not only be able to search through all your email, it also means you get a more useful subject displayed than “…” or some other nonsense.
This is of course a trade-off in terms of security; you will have at least parts of your encrypted email in decrypted form on your disk, and so an attacker that has access to your system will have access to the encrypted contents in plain text. However, it’s a reasonable trade-off as an attacker that has access to your system, which contains your private GPG key as well, will have have good chances of obtaining what he looks for anyway. It’s also a necessary trade-off to make encrypted communication usable enough so it can be used across the board.
Of course we could attempt to protect the index, but this is best left to the same tools that protect the rest of your system, such as full-disk encryption.
“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.” For more info, head over to: kube-project.com
Finding New Ways... 
Hmm, couldn’t you use an encrypted index like seshat does for Matrix (and store it on the server)? Though I am not sure the return on investment is really worth it… 🙂
It’s a local cache, so storing it on the server is not a think in our scenario. We certainly could encrypt parts of the index, but that adds complexity and works against the goal of being able to access the data quickly. I think it would also mean that we would have to introduce something different for encryption/decryption than gpgme, which again makes the system more complex. So IMO a lot of effort for little security gains.