ietf-openpgp
[Top] [All Lists]

do security recommendations belong in standard? (Re: CAN'T Re: MUST versus SHOULD in application decisions)

1997-10-30 11:13:00

Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
Storage Keys vs. Communication Keys; SHOULD/SHOULD NOT/MUST/MUST NOT
CMR vs. CDR vs. GACK vs. CMRK.

I don't think we'll be able to find a satisfactory answer to this,
or at least not that's useful for a standard like OpenPGP.
The problem is that PGP doesn't _do_ Storage or Communication;
it takes a batch of input data, does crypto, and produces output data.

It is simpler to proceed on the basis that the standard says nothing
about storage or communication -- however I'm not sure this safe.
Also I'm not sure this is valid.

I think much more useful security, and proper use recommendations can
be made if the standard, or at least security recommendations in the
standard or related document acknowledges the difference between
storage and communication -- there is a huge difference in security
implications and proper usage.

For starters there is not really much point using public key
encryption for storage for your own use.

Communications keys are much more sensitive than storage keys (with
communications your attacker has easy access to the ciphertext this
means if you use long term keys for communications, the passive
attacker can snoop a years worth of traffic, and then bribe, or coerce
a key from one of your employees).  For storage on the other hand,
access to the data is needed, as well as obtaining the key.

Since PGP doesn't know what other programs do with its output data,
it can't implement DO/DONT/SHOULD/MUST; they're out of its scope.

No, I disagree.  At the very least how keys are treated, the security
risks of using the same comms keys for extended periods are inside
it's scope surely?

This has implications for output data handling which you declare above
is outside scope.  If the output data is transferred over an insecure
medium (effectively broadcast over the Internet), this is what creates
the need for short lived keys.

For storage on the other hand, you have less risk, and there is less
value to frequently updating keys.

PGPdisk does storage.  SMTP does communication, and could add crypto.
The old PGP2.6.2 did most of its crypto on files, but still generated
output files from input files rather than directly doing storage,
and it didn't do any communication at all.

What pgp2.6.x does is also highly dangerous -- no key expiry
mechanism, common practice of having long term keys, no forward
secrecy over the link.

pgp5.x message formats allow for better than this -- there are expiry
fields on keys, and encryption keys can have different expiry fields
than signature key expiry fields.  pgp5.0 (at least linux version) can
also encrypt with symmetric storage keys.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

<Prev in Thread] Current Thread [Next in Thread>