On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote:
===================================================================
B. Use feature bits of a key 0x02, 0x4 of
"5.2.3.24. Features" as follows:
0x02: The default symmetric alg. of the key is AES-128
0x04: The default symmetric alg. of the key is AES-256
These bits can be combined (i.e. they are not mutually
exclusive).
===================================================================
TOP SECRET (TS) must have 0x02
SECRET must have 0x02|0x04=0x06
The existence of 0x02 or 0x04 tells that the implicit default
algorithm TripleDES is replaced by (either of) corresponding AES
algorithm(s).
This specification may appeal to these who don't want to see Suite-B
mentioned in the "protocol/format" document. It also specifies
narrow feature using the concepts compatible with the scope of RFC
4880.
I'm not sure that option (B) is really selectable here. Or put
another way, I think option (B) already exists as part of the current
cipher preferences system.
For example, take the entire installed user base of OpenPGP programs
to date. That's a non-trivial amount of code in active use. Those
programs will not know about the new feature flags, and will thus
ignore them (meaning they will use 3DES as the default algorithm).
Now take the case of an old key (default is 3DES) and a new key
(default is AES) as recipients to a message. Let's assume that there
is no agreement on ciphers, so the cipher of last resort must be
used. A sender using the 4880-compliant program will (correctly) use
3DES, as it knows nothing about the feature flag telling it do behave
otherwise. A new OpenPGP program might not have 3DES (why bother
since AES is the new default), so one of the recipients won't be able
to read the message. Okay, so we can fix that: we can enhance (B)
with a rule saying that 3DES is still a MUST-implement cipher, to
cover that case.
Now take the reverse case: the same two recipient keys, but the sender
is a new OpenPGP program that believes AES to be the default. In the
case above, the message will *still* be 3DES, as the older key does
not have the necessary feature flag, so the new program can't use this
new feature across the entire recipient set.
So given that new programs will need to have 3DES anyway to cover the
transition case, and given that messages sent to a mixture of old and
new keys that are forced to use the cipher of last resort will end up
as 3DES.... how is (B) different than the current cipher preference
system with AES listed before 3DES?
David