For what it's worth, I used to use encrypted mail some time ago as much as possible, before realising it was fundamentally flawed:
— the key retention is the biggest issue. You need to keep your key around for a long time, probably storing copies of it. This increases the probability of a leak.
— there is no method to revoke a key with a 100% assurance that nobody will use or trust it afterwards.
— if a key is broken or leaked, every encrypted message you ever received can be deciphered. And I hope you realise it, or future messages are also at risk.
Those are the three major flaws I can remember right now. The way people usually use it make them feel safe while they are not necessarily. It's a bit like reusing a complex password on different websites (although far less critical since the key is assymetric).
The way I use it now (and I never actually needed it, to be fair), is that if some third party want to send me some confidential information, they request my public key via an open channel, and I then generate a key, unique for this conversation (ideally, it would be done on a per-email basis).
Of course, the complex part here is ensuring they receive the proper key (ie, no man in the middle). This can be done by using a side (preferably secure) channel.
Of course, in today's world, encrypted emails are not the best way to communicate privately, in my opinion, but that's another story.
And there are a couple of other issues regarding encrypted emails such as its adoption, it's complexity, etc. But none as fundamental.
> the key retention is the biggest issue. You need to keep your key around for a long time, probably storing copies of it.
As I get it, this one is a fundamental issue, not specific to messaging at all, but is just a secure storage problem.
You either keep a copy of the message (and need some key to decrypt it, unless you keep it unencrypted), or you throw it away. No amount of engineering can solve this.
That's what 'perfect forward security' is intended to solve. For more details please look up the Off The Record (otr) protocol overlay.
The basic idea is that any given session is authenticated temporally; when a session is completed the details for it are leaked so that anyone could forge content as having been within that session. Thus there is reasonable doubt about anything that was said/transferred having actually been said/transferred.
No. PFS is about when messages are in transit. Sure thing, it makes sense to encrypt them with ephemeral keys rather than a long-living ones.
However, that particular point I've quoted was - as I understood it - about message archives. Short-lived keys are just fundamentally incompatible with long-term storage. We either keep data, or we don't.
PFS helps for about another point raised, "if a key is broken or leaked..." (but has a trade-off, as it requires some sort of key exchange)
> However, that particular point I've quoted was - as I understood it - about message archives.
In a sense you're right, but the archive in question is the one your adversary accrued while they were intercepting your in-flight emails, which you encrypted with your static key. Any archive you have control over is sort of beside the point.
If you want archiving, store "plain text" mail on an encrypted disk/along with your other encrypted backup?
You will need to archive the public and private keys if you need to go back and audit messages - but that assumes that "I verified to my satisfaction in 1996 and archived securely" isn't enough.
— the key retention is the biggest issue. You need to keep your key around for a long time, probably storing copies of it. This increases the probability of a leak.
— there is no method to revoke a key with a 100% assurance that nobody will use or trust it afterwards.
— if a key is broken or leaked, every encrypted message you ever received can be deciphered. And I hope you realise it, or future messages are also at risk.
Those are the three major flaws I can remember right now. The way people usually use it make them feel safe while they are not necessarily. It's a bit like reusing a complex password on different websites (although far less critical since the key is assymetric).
The way I use it now (and I never actually needed it, to be fair), is that if some third party want to send me some confidential information, they request my public key via an open channel, and I then generate a key, unique for this conversation (ideally, it would be done on a per-email basis). Of course, the complex part here is ensuring they receive the proper key (ie, no man in the middle). This can be done by using a side (preferably secure) channel.
Of course, in today's world, encrypted emails are not the best way to communicate privately, in my opinion, but that's another story.
And there are a couple of other issues regarding encrypted emails such as its adoption, it's complexity, etc. But none as fundamental.