[Swan-dev] Camellia trransform representation in IKEv1

Paul Wouters paul at nohats.ca
Tue Dec 9 19:20:58 EET 2014


On Sat, 6 Dec 2014, D. Hugh Redelmeier wrote:

> I'm looking at ce89ea7feed076044110da204456b8ba68a0986a, but not carefully
> enough.  My justification: this code should be clear enough that one
> doesn't have to look at it carefully.
>
> As I understand it, the annoying fundamental problem is that IKEv1 and
> IKEv2 differ on how to represent Camellia, and worse, the representation
> used in v1 already has a different meaning in v2.
>
> I think that the v2 representation has no meaning in v1.
>
> We should always know whether we're dealing with a v1 or a v2 number.
>
> But since they are almost the same, we have used the same functions
> for both v1 and v2.

Actually, not all through the code do we already know if we are v1 or
v2, and currently are (still) using v1 numbers for our internal
representation.

> To keep the code sane, if it is shared, I would think that we should
> be using a superset coding.  Perhaps that is the v2 code.  It cannot
> be the v1 code since we've just seen that v1 assigns Camellia the same
> number as something else uses in v2.

Yes, although that would make a lot of changes in the v1 one. In a way,
we do not want to touch the v1 code much.

> At a minimum, each variable or field that holds one of these values
> should have a comment to say which of the three varaints it contains:
> universal, v1, or v2.  Even better is to use a type to signify this.

I have been reluctant to add a third "universal" set. Although it is
useful for representing crypto algos in the state before we know if we
are v1 or v2.

> The whole sordid story should be documented clearly in the code (perhaps
> it is).

I tried to leave comments where I performed the unexpected work.

It is a mess and it could use cleanup for sure. But it is not very high
on my list. IKEv1 mostly uses 3DES and AES and SHA1 and MD5. IKEv2 is
strongly moving to AEAD ciphers only due to various padding attacks
like POODLE.

Paul


More information about the Swan-dev mailing list