paul at nohats.ca
Wed Apr 2 19:20:27 EEST 2014
On Wed, 2 Apr 2014, D. Hugh Redelmeier wrote:
> This gets an assertion failure for me. Is this currently normal?
> The problem is with
> 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)
More information about the Swan-dev