ietf-openpgp
[Top] [All Lists]

Re: OpenPGP keys and Suite-B

2008-05-04 08:55:34

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