|Main Archive Page > Month Archives > ipsec archives|
2009/10/23 Alfred HÎnes <email@example.com>
> Sean Shen wrote:
> > Section 2.2 says that "AES MUST use different rounds for each of the
> > key sizes: ...".
> > The draft is not trying to say that IKEv2 requires 10/12/14 rounds for
> > 128/192/256 key lengths. The draft is not trying to say that AES-CTR
> > requires 10/12/14 rounds for 128/192/256 key lengths.
> > Sean
> > ...
> The "MUST" still makes the difference! That is normative and does
> NOT belong into this draft. Although that would still be regarded
> out of scope of your draft, I would be more willing to accept an
> _informative_ statement like:
> "Note: AES uses different rounds for each of the key sizes: ...".
> ^^^^^^ ^^^^
[Sean] Correct, "MUST" is defined in key words conventions and should not be used here. I will dropt it.
> But the most important topic remains: The draft is ill-advised in
> pretending that the interface of AES -- or, btw, *any* currently
> sensibly used block cipher primitive of reasonable strength --
> had an _external_ parameter "number of rounds" that upper protocol
> (sub-)layers would need to have to deal with.
> Otherwise, the "IKEv2 Transform Attribute Types" would have to
> include an entry for "number of rounds", which it doesn't, and
> you also do not aim at establishing such entry.
[Sean] The IKEv2 requirement in the draft is only about key lengths. I never pretended that the AES standard allows arbitary conbinations of key lengths and rounds.
I checked the document again and noticed that in the second paragraph of section 2:
"... The choices of Key Size, Rounds and Block Size are defined as following which are compatible with [RFC3686]."
If this sentense misleads readers to think that users can choose all conbinations, I will rewrite it as:
"... The choices of Key Size are defined as following which are compatible with [RFC3686]."