[Top] [All Lists]

Re: I have a technical idea/change for the ECC draft

2008-04-13 04:15:24

David Crick wrote:
"11.3. Interoperability with Suite-B profile" currently states:

   "If TripleDES is the only shared algorithms for a set
   of recipients, no Suite-B compliant recipient can be added to the
   mentioned recipient set."

I had to look at all of 11.3 to try and make sense of this, and found that whole subsection to be hopelessly confusing. Can we have a simple statement as to whether an OpenPGP-ECC key can be used with TripleDES or not? Can messages be mixed-mode or not?

It seems to me that if an application creates and exports an OpenPGP-ECC key (only) then that public key cannot be used with TripleDES, as the document does not suggest it anywhere (and implies it is ruled out). Which means there should be a specific claim that this ECC draft overrules the "guarantee" of TripleDES intersection in RFC4880.

(To me, this seems like a reasonable price to pay to get a good, clear result.)

Alternatively, there should be a specific claim permitting use of TripleDES and describing how/what.

(I should note that I do not recall the discussions of a few months back. This should be a "good thing" because it allows me to view it as a first time reader. My routine excuse is that if I can't understand it from a simple reading then I suspect we are putting an unnecessary burden on first time readers, but not many agree with that!)

but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the

Personally, I would have said that the recipient should reject the message with an error. If there is a mixed mode message, then the sender is in error, allowing for a potential attack. We might not be able to stop the attack through a misbehaving client, but we should red-flag it when we see it.

(but I've not seen the full sense yet, I may be wrong.)

(Apps have these flags to decrypt even when there are errors in modes, so that's ok.)

I therefore have a suggestion:

implement a key-packet preference flag that says "strict SuiteB"

If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.

This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.

Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox

thoughts people?

these complexities will roll forward in history :( ...