[Swan-dev] DH group naming

Andrew Cagney andrew.cagney at gmail.com
Fri Jun 23 14:08:31 UTC 2017


On 23 June 2017 at 02:39, Oleg Rosowiecki <orosowiecki at gmail.com> 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 <andrew.cagney at gmail.com>
> wrote:
>>
>> On 22 June 2017 at 19:04, Oleg Rosowiecki <orosowiecki at gmail.com> 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.
>
>


More information about the Swan-dev mailing list