[Swan-dev] DH group naming
Andrew Cagney
andrew.cagney at gmail.com
Fri Jun 23 15:35:02 UTC 2017
For reference,
FYI, I came up with the following additions. While I don't think
aes_gcm_256 is valid, aes_gcm_16_256 certainly is :-/
@@ -104,10 +104,36 @@
[esp=aes_gcm_c-128-null] OK: AES_GCM_C(20)_128-NONE(0)
[esp=aes_gcm_c-192-null] OK: AES_GCM_C(20)_192-NONE(0)
[esp=aes_gcm_c-256-null] OK: AES_GCM_C(20)_256-NONE(0)
+[esp=aes_ccm_a-null] OK: AES_CCM_A(14)_000-NONE(0)
+[esp=aes_ccm_b-null] OK: AES_CCM_B(15)_000-NONE(0)
+[esp=aes_ccm_c-null] OK: AES_CCM_C(16)_000-NONE(0)
+[esp=aes_gcm_a-null] OK: AES_GCM_A(18)_000-NONE(0)
+[esp=aes_gcm_b-null] OK: AES_GCM_B(19)_000-NONE(0)
+[esp=aes_gcm_c-null] OK: AES_GCM_C(20)_000-NONE(0)
[esp=aes_ccm-null] OK: AES_CCM_C(16)_000-NONE(0)
[esp=aes_gcm-null] OK: AES_GCM_C(20)_000-NONE(0)
[esp=aes_ccm-256-null] OK: AES_CCM_C(16)_256-NONE(0)
[esp=aes_gcm-192-null] OK: AES_GCM_C(20)_192-NONE(0)
+[esp=aes_ccm_256-null] ERROR: ESP encryption algorithm 'aes_ccm_'
is not recognized, enc_alg="aes_ccm_"(256), auth_alg="null", modp=""
+[esp=aes_gcm_192-null] ERROR: ESP encryption algorithm 'aes_gcm_'
is not recognized, enc_alg="aes_gcm_"(192), auth_alg="null", modp=""
+[esp=aes_ccm_8-null] ERROR: ESP encryption algorithm 'aes_ccm_'
is not recognized, enc_alg="aes_ccm_"(8), auth_alg="null", modp=""
+[esp=aes_ccm_12-null] ERROR: ESP encryption algorithm 'aes_ccm_'
is not recognized, enc_alg="aes_ccm_"(12), auth_alg="null", modp=""
+[esp=aes_ccm_16-null] ERROR: ESP encryption algorithm 'aes_ccm_'
is not recognized, enc_alg="aes_ccm_"(16), auth_alg="null", modp=""
+[esp=aes_gcm_8-null] ERROR: ESP encryption algorithm 'aes_gcm_'
is not recognized, enc_alg="aes_gcm_"(8), auth_alg="null", modp=""
+[esp=aes_gcm_12-null] ERROR: ESP encryption algorithm 'aes_gcm_'
is not recognized, enc_alg="aes_gcm_"(12), auth_alg="null", modp=""
+[esp=aes_gcm_16-null] ERROR: ESP encryption algorithm 'aes_gcm_'
is not recognized, enc_alg="aes_gcm_"(16), auth_alg="null", modp=""
+[esp=aes_ccm_8-128-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_ccm_8-" (state=ST_EK_END)
+[esp=aes_ccm_12-192-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_ccm_12-" (state=ST_EK_END)
+[esp=aes_ccm_16-256-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_ccm_16-" (state=ST_EK_END)
+[esp=aes_gcm_8-128-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_gcm_8-" (state=ST_EK_END)
+[esp=aes_gcm_12-192-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_gcm_12-" (state=ST_EK_END)
+[esp=aes_gcm_16-256-null] ERROR: Non alpha char found after enc
keylen end separator, just after "aes_gcm_16-" (state=ST_EK_END)
+[esp=aes_ccm_8_128-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_ccm_8" (state=ST_EK)
+[esp=aes_ccm_12_192-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_ccm_12" (state=ST_EK)
+[esp=aes_ccm_16_256-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_ccm_16" (state=ST_EK)
+[esp=aes_gcm_8_128-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_gcm_8" (state=ST_EK)
+[esp=aes_gcm_12_192-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_gcm_12" (state=ST_EK)
+[esp=aes_gcm_16_256-null] ERROR: Non digit or valid separator found
while reading enc keylen, just after "aes_gcm_16" (state=ST_EK)
[esp=aes_ctr] OK: AES_CTR(13)_000-MD5(1),
AES_CTR(13)_000-SHA1(2)
[esp=aesctr] OK: AES_CTR(13)_000-MD5(1),
AES_CTR(13)_000-SHA1(2)
[esp=aes_ctr128] OK: AES_CTR(13)_128-MD5(1),
AES_CTR(13)_128-SHA1(2)
On 23 June 2017 at 10:08, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> 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