[Swan-dev] DH group naming

Fri Jun 23 15:46:05 UTC 2017

Thanks! By the way, I think it's worth updating the man pages with the
summary of this. Some of the naming conventions and algorithm names are
unclear unless you investigate by trial and error and/or looking at the
source code.

On Fri, Jun 23, 2017 at 5:35 PM, Andrew Cagney <andrew.cagney at gmail.com>
wrote:

> 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.
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20170623/bb4d9465/attachment-0001.html>