[Swan] SHA2 support for ESP in KLIPS?

Paul Wouters pwouters at redhat.com
Tue Jun 25 17:29:04 EEST 2013


On Tue, 25 Jun 2013, Elison Niven wrote:

> I never had KERNEL_ALG undefined.
> This if condition never passed :
>
> #ifdef KERNEL_ALG
>    if (kernel_alg_esp_auth_ok(pi->attrs.auth, NULL)) {
>
> So it went to the default case below.
> Changing it to
>
> if (!kernel_alg_esp_auth_ok(pi->attrs.auth, NULL)) {
>
> worked and pluto no longer gives the assertion.

But that's wrong:

err_t kernel_alg_esp_auth_ok(int auth,
                              struct alg_info_esp *alg_info __attribute__(
                                      (unused)))
{
         int ret = (ESP_AALG_PRESENT(alg_info_esp_aa2sadb(auth)));

         if (ret)
                 return NULL;
         else
                 return "bad auth alg";
}

The function (misleadingly) returns NULL on success, and non-NULL on
failure.

> After doing this however, I still get the same error in KLIPS as earlier.
>
> This patch proposed here also does the same change in ikev1_quick.c : 
> https://www.openswan.org/issues/331

It was wrong there too :)

While we could adopt the patch to add sha2 to klips, I really feel we
should only extend ciphers/algorithms in klips using cryptoapi. In fact,
I wish we could drop the native md5/sha1/3des/aes from klips as well,
but I understand that would currently break OCF.

Paul

> On Tuesday 25 June 2013 09:12:12 AM IST, Paul Wouters wrote:
>> On Tue, 25 Jun 2013, David McCullough wrote:
>> 
>>>> Looking at IKE_ALG, it seems that we always need it and the #ifdef
>>>> should just be killed. The same for KERNEL_ALG too?
>>>> 
>>>> In fact, this one even seems to have mixed up the two:
>>>> 
>>>> #ifdef KERNEL_ALG
>>>>                 alg_info_addref(IKETOINFO(c->alg_info_ike));
>>>> #endif
>>>> 
>>>> 
>>>> So I'd like to suggest we clean these defines up and remove them, as
>>>> the
>>>> code seems to be always required.
>>> 
>>> Agreed.
>> 
>> Done and tested with netkey and klips (though it should not have
>> affected the kernel stack)
>> 
>> Paul
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>> 
>> 
>
> --
> Best Regards,
> Elison Niven
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>


More information about the Swan mailing list