On Fri, 20 Mar 1998, Jon Callas wrote:
The most important is what the symmetric algorithm preference is. It's a
list of symmetric algorithms that the keyholder accepts. If an algorithm is
not in the list, then the keyholder doesn't speak it, and consequently an
implementation MUST NOT use an algorithm absent from that list. If that
packet is absent, then it is implicitly stating a preference for 3DES, and
all keys implicitly accept 3DES even if unstated.
If 3DES is a MUST, even if it is not listed it should be usable (assume
the preference states Blowfish, and MyPGP doesn't do Blowfish).
Much of this is implementation, so how different preferences are handled
should be up to the implementor, and not in the spec.
The way I would implement the selection logic (in order):
1. Sender Overrides (command line, config, environment) with a list of
never, try to avoid (warn), prefer, force entries.
Force will leave a single entry. Otherwise start with the full list
the sender supports, delete the NEVERS, then create 3 lists: prefered,
neutral, avoid. A Force will equal a single neutral entry.
2. Recipient Preference. This is the list in the key | 3DES
Take this list, and find the first common cipher on the senders
preferred list, and if none exists, on the neutral list, and if there
is none there, use the avoid list (and print a warning).
If I don't want to send 3DES, I put it in my never send list. If I don't
want to receive 3DES, then I can't be running something that interoperates
with OpenPGP by definition. If I am the receiver, and don't want 3DES, I
should be able to specify a warning message (e.g. a never list on the
receiver side). I can still decrypt the message, but get warnings saying
that it uses something I don't want it to be using.
I'm planning on a few other things in the algorithm section. Among them, I
plan some notes on Elgamal, particularly notes explaining the restriction
on an Elgamal key that is going to be used for signatures. I always thought
that "plaintext" means plaintext, with no CFB stuff, but after reading
tzeruch's comments, it seems that having 10 bytes of reset data is more
correct. Arguably, this is a way to satisfy the desire for a debugging
algorithm without grossing out the people who don't like the idea. Comments?
I thought ROT-N was supposed to satisfy the desire for a debugging
algorithm.
10 bytes of reset data: I assume the bytes number 7==9 and 8==10, like all
other cfb variants, but the first 8 bytes are still random?
And more importantly, there would be a full conventional key header with
all the fields, just that the algorithm would be zero, so none of the
stuff would be used (except maybe the IV to do the 1st 10 bytes).
So the CFB routine won't even do the XOR operation with the previous 8
byte block? (or can we define the blocksize > 8 so dispense with the
reset that way?).
--- reply to tzeruch - at - ceddec - dot - com ---