ietf-openpgp
[Top] [All Lists]

Re: Algorithms and specifiers

1998-03-21 12:47:47
Bill Stewart:
If you're paranoid enough that you insist that your messages be encrypted
with CAST5, do that, add a note saying it's encrypted with CAST5, and
encrypt that with the 3DES the recipient wants.

William H. Geiger III:
You seem to be missing the point here. Why should the recipiant mandate
how I encrypt my messages? It is *my* message! These are *preferences* not
mandates. The owner of a key may chose not to put any algorithm
*preferences* in his key should all communications to this user then be
forced to use 3DES dispite the fact he is capable of decrypting other
algorithms??

Uh, yes.  It's not a no-brainer decision though.

Perhaps we should consider some scenarios about why a recipient or
a sender would have a preference.

- Example: I'm involved in a conspiracy, and I don't want any of my
  clueless or government-stooge co-conspirators using Rot-N or
  Plaintext as their preferred cipher, since I suspect these ciphers
  may provide less protection than I feel my conspiracy is worth.
  If I can't specify that I refuse to accept crackable incriminating
  messages, then I'll have a lot of explaining to do in court.

- Example: I want to send a private message to someone, but know
  their only accepted cipher (IDEA) has recently been broken.  I
  can choose not to send the message, or else to send them a message
  telling them I can't send them secure mail and asking them to pick
  another algorithm.

- Example: I normally use this key/username to get gigabyte files of
  satellite data dumped to my machine.  If they send it in 3DES
  my scruffy P1 can't keep up.  I need it to use CAST or Blowfish.
  If the sender overrides this and sends me 3DES, my machine chokes.

Note that in this latter case the user chooses not to accept the
MUST algorithm for good (though uncommon) reasons -- should this
be OK?

Adam Back suggests that 3DES need not be listed, since it's a MUST.
However, doesn't this mean "client MUST implement" rather than
"recipient MUST accept"?  He also suggests that the list of
preferred algorithms is all the algorithms the client supports,
ordered by preference of user.  I strongly object to this -- I do
not want to accept Rot-N or Plaintext encrypted messages, whether
or not my client knows what to do with them, since I trust my own
guesses about security of algorithms more than I trust most people
sending messages to me.

What are some scenarios that would make ignoring the recipient's
preference the correct decision?

        Jim Gillogly
        Mersday, 29 Rethe S.R. 1998, 19:34
        12.19.5.0.9, 8 Muluc 7 Cumku, Ninth Lord of Night

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