One of the paradoxes I struggle with in my work, is the conflict between crypto and reliability.
Crypto is important. But it is very binary in nature - either the stars align and you can decrypt, or it fails and there's no recovery. With that kind of binary, reliability suffers. This is inevitable.
As an example, most of the Mastodon downtime I've experienced has been related to minor SSL certificate blunders.
I feel like most of the #InfoSec community wilfully ignores this dynamic.
As an example of the encrypt-or-not struggle in #Mailpile: currently the recommended settings encrypt all sorts of local files, including the search index, settings and downloaded e-mail.
I'm pretty confident that the settings and search index need encrypting.
But the e-mail itself? There I'm not as sure.
If the Mailpile master key gets lost or corrupt, losing all the mail is a very high price to pay. It's also a significant barrier for folks who decide to switch to another client later.
@HerraBRE secure transit vs. encryption at rest are also very different, in terms of usability and common threat models. Use of HTTPS requires almost nothing of users, and mitigates well-known widely-used attacks on confidentiality and integrity by various network parties.
Encrypting backup hard drives (or other long-term storage) is a much weightier risk of lost access and requires user to manage long-term keys, and protects against certain types of mostly in-person theft.
