One other clarification: in an encrypted and signed message there are
really four algorithms involved: the public-key signature algorithm,
the hash algorithm used for the signature, the public-key encryption
algorithm, and the conventional cipher algorithm used for encryption.
Generally the current PGP implementations assume that the signature
and hash algorithm will be chosen by the signer, without regard to
the recipient of the message. This is particularly appropriate for
messages to large groups and clear-signed messages to public forums,
or for messages which may have a long lifetime and be shown to many
parties, such as contracts. However for messages to one or a small
number of recipients, it might be useful for the sender to know which
signature and hash algorithms the recipient prefers or can handle.
With encryption, PGP currently chooses the public key and secret key
algorithms based on the recipient's preferences. Where we are encrypting
to multiple recipients, it chooses a conventional secret key algorithm
which all recipients can handle, and aborts if no such algorithm exists.
In both cases, it is difficult to know how to balance the interests
of the sender of the message and the recipient(s) in terms of choice
of algorithms. Each party could have preferences, and possibly vetoes,
in terms of what they would like to see used. There may be multiple
recipients, and in the case of signatures there may be unknown recipients.
We could generalize the preferred-algorithm packets to allow the
recipient key to say things like "don't send me messages hashed with
MD5" or "only send messages signed with RSA or DSA keys". This could
be handled similarly to the current specification of preferred secret
algorithms. It is somewhat more awkward to implement because signing
is conceptually a distinct step from encryption, and so this requires
some internal information flow which would not otherwise be needed.
Hal Finney
hal(_at_)pgp(_dot_)com