don't use encrypt to self (Re: legislating the impossible?)

[Adam Back]

William Geiger writes:
> >The additional problem `encrypt to self' presents when we consider
> >someone trying to recover keys is that the attacker can coerce either
> >party to recover keys.  This is particularly pertinent when the DTI and
> >UK government starts to talk about legal requirements to hand over keys. 
> >By using encrypt to self, you will open yourself up for demands for keys.
> 
> This is where Encrypt To Self is a problem. You send a message to John
> Doe, John Doe is under court order to release the plain text, he refuses,
> the courts come after your key as they know it will also decrypt the data.
> This not only is a hassle but now exposes *all* your communications to
> government inspection.

Yes, you see the problem.

The problem is a general problem also: using the same encryption key
forever means that if someone does recover your encryption key, all
your past communications are compromised.

> >Similarly by using long term encryption keys (rather than deleting
> >private keys and generating new keys say on a monthly basis) you are also
> >opening yourself up for such demands.
> 
> This opens up some rather nasty problems dealing with key certs, WOT and
> all that.

No problem at all: the WoT is based on signature keys; you decrypt
messages with encryption keys.  You delegate trust to short lived
encryption keys with the long lived signature key.  This is a solved
problem.

> >Companies not wishing to open themselves up for expensive discovery
> >processes, and individuals who value their privacy would be better to not
> >use encrypt to self, and would do well to use short lived keys.
> 
> I really don't know how much of a problem this will really be as
> they will just ask for your storage keys rather than your comm keys.

View it this way: encryption is a form of secret sharing, plaintext is
split into two parts: ciphertext and the key.  If the attacker can
recover both he can get the plaintext back.

Your aim is to ensure that you keep one or more of the secrets out of
the hands of the attacker.

With communications, the attacker already has the ciphertext; with
long lived communications keys he can coerce the private key from you.
So all of your received traffic remains vulnerable forever (and with
encrypt to self all of your sent traffic is also vulnerable forever).

If you archive encrypted to a separate storage only key rather than
using `encrypt to self', both the ciphertext and the key are not
available to the attacker.  (The ciphertext being on the disk, the
attacker has to kick down doors to get at it).  If you decide after
some time to purge some of your archives, you can delete the
ciphertext.

With encrypt to self you can't purge ciphertext because the attacker
may have archived it all.

With encrypt to self you can't delete old private keys either without
losing access to all of your archives.

> There is always a balancing act between security and convieniance. Issues
> of WOT, keyserver load, key exchange all needed to be taken into account
> when considering the lifetime of a key.

WoT is a non-issue with separate signing and encryption keys; key
generation is cheap for Elgamal, keyserver load I don't think is a
significant problem.

> >This is analogous to the practice of housekeeping to discard memos and
> >internal documentation periodically to reduce risks of discovery
> >processes.
> 
> Looks good on paper but in practice it is not pratical. I have been in
> both government and corporate situations where I kept ever note, memo,
> letter, ..ect. This is SOP for CYA as some SOB will try to stick it to you
> if you don't. Now multiply this by the 100's or 1000's of emplyees,
> contractors, ect in a corporation and their is no way you are going to
> purge the documentation. 

Plenty of people have documented the opposite, where companies have as
a matter of policy destroyed paperwork periodically.  All we can draw
from your comment is that some employees don't follow company policy,
and/or that some companies are less worried about discovery.

Adam