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

[William H. Geiger III]

In <199807051554.QAA13346@server.eternity.org>, on 07/05/98 
   at 04:54 PM, Adam Back <aba@dcs.ex.ac.uk> said:


>I commented that in my view encrypt to self should not be used because of
>the risks it adds.

>Someone asked me off list why I held this view, so I thought I'd comment
>here too.

>The problem with `encrypt to self' is that it places access to ciphertext
>on my disk under the control of a third party -- the sender.  What's more
>I have no idea what precautions the sender takes of their key or
>passphrase -- they might not have a passphrase, or have it written on a
>sticky note on the side of their screen, and they may be using a multi
>user unix system.

>If the message is encrypted to my key only, I can periodically delete my
>private key and generate a new key.

This is irrelevent. When you send an encrypted message to another person
you have lost all control of what they will do with this data on their
end. The reverse is also true, you have no control of what a sender does
with the raw data he is sending you. Encrypt to self has no affect on this
one way or another.


>The reason I call encrypt to self a misfeature is because it sends an
>additional door into the plaintext over the internet when there is no
>technical reason to do so.  If the sender wishes to keep a copy the
>software should keep a copy in plaintext or should keep a copy encrypted
>with the sender's own keys locally -- by sending an additional door into
>the data over the internet he is adding additional, and entirely
>unnecessary, risk.  

Insignificant. Please provide any reference to cryptanalysis of multi-key
encrypted messages and their weakness when compaired to single key
encryption.

>That archival encryption is implemented with the `encrypt to self'
>feature by PGP is for the convenience of the implementor only. Another
>reason that encrypt to self is a bad approach to archival encryption is
>that it uses one key for two distinct purposes: communications and
>archiving.  For archiving keys you need to keep them as long as you wish
>to have access to the data.  For
>communications keys you should delete private keys periodically to reduce
>risks.  So using the same key for both purposes prevents one from
>discarding old keys, because doing so would make archives inaccessible.

>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.

>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.

>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.

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.

>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. Not to mention you run a real risk of obstruction
charges unless you can *prove* that the purge of documentation was done
*before* any type of investegation has started.

A secret shared between more than one person is no longer a secret. If you
have something questionable *don't put it in writting!!* It will come back
to bite you in the ass sooner or latter.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://users.invweb.net/~whgiii/pgp.html
---------------------------------------------------------------
 
Tag-O-Matic: OS/2...Opens up Windows, shuts up Gates.