On Tue, Mar 17, 2015 at 11:04 AM, Derek Atkins <warlord(_at_)mit(_dot_)edu>
wrote:
Bill Frantz <frantz(_at_)pwpconsult(_dot_)com> writes:
On 3/16/15 at 6:51 AM, warlord(_at_)MIT(_dot_)EDU (Derek Atkins) wrote:
Oh, you expected me to decrypt/re-encrypt my encrypted email as I got
it???
For many uses, decrypting from the wire format and re-encrypting in
the "data at rest" security format makes excellent sense. Having only
one encryption scheme for long-term storage allows easy (relatively)
upgrade and helps to ensure that the data is still accessible,
i.e. the decryption still works. I probably have a bunch of old PGP
encrypted email I can't read anymore because I don't have the secret
key, or its passphrase. If that mail had been re-encrypted in a format
that I decrypt every day, I would still be able to read the
mail. Encryption that isn't regularly exercised gets rusty.
Show me an MUA that does this, please? None of the OpenPGP-aware MUAs
I've ever used have this feature, as far as I know. I suppose I could
go out of my way to replace the encrypted email with a
re-encrypted/plaintext email.
But frankly I'd like my encryption software to just maintain the ability
to decrypt it later.
Cheers - Bill
-derek
The only thing I have seen done that is similar is re-signing documents
under a stronger signature key. But that is now obsolete since the
Harber-Stornetta patents expired and hash chain type schemes are possible.
We have considered the underlying problem quite a bit on the cryptography
list. There are many problems of key management. For example, do I want
people to be able to read some of my emails on death? In an enterprise
scenario, I don't want the bank to lose all the emails I sent to my broker
because she fell under a bus.
There are also many complicating factors. Phones get stolen or lost, etc.
etc.
This led me to an approach in which each user has a personal PKI hierarchy.
This is probably going to look excessive. But solving the use cases
requires every bit. If you want to be able to have some part of your
communications be proof against court warrants, you need more.
1) A personal offline key signing key. [R]
2) A personal offline recovery encryption key. [R]
3) A personal online key signing key with expiry ~ 10 years
4) A personal mail encryption key [R] that is rotated monthly and escrowed
under the personal offline recovery encryption key.
In addition each device has a personal message signing key and a key
distribution key that are unique to that device and never leave it.
So in PRISM-PROOF, the standard configuration begins with six keygens(!)
The keys marked [R] may have recovery support. To do this we encrypt the
message and store the bits in the cloud. This means we only need to escrow
the decryption key somehow. In the case of (1) and (2) this is done with
key shares printed out onto paper (and as QR codes). In the case of (4) the
key is escrowed under key (2).
Each key is wrapped in X.509. Yes, I hate it as much as anyone else. But
doing that allows me to use the keys in S/MIME and enroll them in TRANS
logs.
Yes, there is a lot of complexity. But the user does not see any of it. I
would rather have more code complexity than user experience complexity.
The user's fingerprint is the hash of (1) which is intended to be
potentially a life long master key. By which I mean that it should work for
a person's whole life though it is possible it might be superseded in
certain circumstances.
Now this is probably not something people want to be thinking about in
OpenPGP vNext. But it is something you might want to consider as a future
convergence possibility.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp