[Swan-dev] pluto/netkey-algo-cast-01

[Paul Wouters]

On Wed, 2 Apr 2014, D. Hugh Redelmeier wrote:

> This gets an assertion failure for me.  Is this currently normal?

Apparently?

> The problem is with
> /source/programs/pluto/kernel.c:1738
> 	passert(st->st_esp.keymat_len == key_len + ei->authkeylen);
>
> I don't think my current changes are the source of the problem.
>
> For what it's worth,
>    st->st_esp.keymat_len == 36
>    ei->authkeylen is 20
>    key_len is optimized away :-(
>
> the ei->transid is 6 which is ESP_CAST
>
> ==> odd fact: ESP cast is defined twice!
> 	linux/include/libreswan/ipsec_xform.h:74:#define ESP_CAST 6
> 	linux/include/libreswan/ipsec_policy.h:107:	ESP_CAST=6,
>    Same is true for a lot of related symbols.
>    This seems like a bad idea.

ipsec_xform.h is only used for KLIPS (and I see in programs/spi/spi.c)
It seems to use an XF_* table that is made up of our own numbers, and
not IANA values :( And KLIPS and spi.c have to remain in sync, so
changing that would mean increasing compatibility issues between
userland and KLIPS. We should look at reducing the entries in
ipsec_xform.h. You can see my comment to that as well:

/* why are these hardcoded here? See ipsec_policy.h for their enums -- Paul*/

I think it was done to avoid needing ietf_constants.h for the kernel, as
it contains a plethora of IKE (not IPsec) related IANA numbers.

ipsec_policy.h is only used for userland (except 
./linux/net/ipsec/ipsec_alg_cryptoapi.c which I just fixed to use ipsec_xform.h.

Perhaps we should move linux/include/libreswan/ipsec_policy.h to include/ipsec_policy.h

> key_len starts out as
> 	st->st_esp.attrs.transattrs.enckeylen / BITS_PER_BYTE
>
> This is 0.  I'd guess that this is wrong.

key length of 0 usually mean "use the default key length".

> Note: I've only done enough analysis to convince myself that it
> probably isn't due to the changes that I'm working on.
> I'm willing to pick this up later, once my current dust has settled.

The CAST test cases are relatively new - I don't think we formally
supported it ever (either IKE or ESP)

Paul