On 23 June 2017 at 02:39, Oleg Rosowiecki <[email protected]> wrote:
> Thanks! I noticed recent changes to this code but didn't have a chance to
> analyze them.
>
> There is another similar problem with the parser: ealg_getbyname_or_alias()
> has these aliases for AEAD algorithms:
> aes_ccm_a -- aes_ccm_8
> aes_ccm_b -- aes_ccm_12
> ...
> aes_gcm_c -- aes_gcm_16
>
> If you try to use any of these aliases, parser_machine() will complain. The
> reason is that the parser immediately switches to key length processing
> (ST_EK) if it encounters a digit right after the algorithm name ("bravely
> switch to enc keylen" is the comment :)).
Ah! I'd noticed that algparse.c contains tests for those but they
were commented out (and fail when enabled) so left it at that. Thanks
for pointing out the cause.
BTW, post 3.21 testing should get easier, vis:
$ ./OBJ.linux.x86_64/programs/algparse/algparse aes_ccm_a aes_ccm_8
[ike=aes_ccm_a] ERROR: IKE encryption algorithm 'aes_ccm_a' is not
implemented, enc_alg="aes_ccm_a"(0), auth_alg="", modp=""
[ ah=aes_ccm_a] ERROR: AH integrity algorithm 'aes_ccm_a' is not
recognized, enc_alg=""(0), auth_alg="aes_ccm_a", modp=""
[esp=aes_ccm_a] OK: AES_CCM_A(14)_000-NONE(0)
[ike=aes_ccm_8] ERROR: IKE encryption algorithm 'aes_ccm_' is not
recognized, enc_alg="aes_ccm_"(8), auth_alg="", modp=""
[ ah=aes_ccm_8] ERROR: AH integrity algorithm 'aes_ccm_8' is not
recognized, enc_alg=""(0), auth_alg="aes_ccm_8", modp=""
[esp=aes_ccm_8] ERROR: ESP encryption algorithm 'aes_ccm_' is not
recognized, enc_alg="aes_ccm_"(8), auth_alg="", modp=""
> This is probably not as important as fixing the DH group, but still it
> doesn't work as intended. Worth fixing, too, IMO.
>
> On Fri, Jun 23, 2017 at 2:36 AM, Andrew Cagney <[email protected]>
> wrote:
>>
>> On 22 June 2017 at 19:04, Oleg Rosowiecki <[email protected]> wrote:
>> > Speaking of the algorithm rename... Is there any reason behind accepting
>> > only the value of "dh21" for ike= and allowing only "ecp_521" for
>> > phase2alg?
>>
>> I didn't know about that quirk - the recent changes have been unifying
>> the lookup while largely ignoring the parser. The final round will be
>> merged post 3.21.
>>
>> A quick test shows the current code behaves as follows:
>>
>> ike:
>> [ aes-sha1;dh21] OK: AES_CBC(7)_000-SHA1(2)-ECP_521(21)
>> esp:
>> [ aes-sha1;dh21] OK: AES(12)_000-SHA1(2); pfsgroup=ECP_521(21)
>>
>> but:
>>
>> ike/esp:
>> [ aes-sha1;ecp_521] ERROR: Non alphanum char found after in modp
>> string, just after "aes-sha1;ecp" (state=ST_AK)
>> [ aes-sha1;ecp_521] ERROR: Non alphanum char found after in modp
>> string, just after "aes-sha1;ecp" (state=ST_AK)
>>
>> so things are at least consistent (and dh21 is the preferred name).
>> I'll tweak the parser.
>
>
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
