<div dir="ltr"><div>Thanks! I noticed recent changes to this code but didn't have a chance to analyze them.</div><div><br></div><div>There is another similar problem with the parser: ealg_getbyname_or_alias() has these aliases for AEAD algorithms:</div><div><br></div><div>aes_ccm_a -- aes_ccm_8</div><div>aes_ccm_b -- aes_ccm_12</div><div>...</div><div>aes_gcm_c -- aes_gcm_16</div><div><br></div><div>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 :)).</div><div><br></div><div>This is probably not as important as fixing the DH group, but still it doesn't work as intended. Worth fixing, too, IMO.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 2:36 AM, Andrew Cagney <span dir="ltr"><<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 22 June 2017 at 19:04, Oleg Rosowiecki <<a href="mailto:orosowiecki@gmail.com">orosowiecki@gmail.com</a>> wrote:<br>
> Speaking of the algorithm rename... Is there any reason behind accepting<br>
> only the value of "dh21" for ike= and allowing only "ecp_521" for phase2alg?<br>
<br>
</span>I didn't know about that quirk - the recent changes have been unifying<br>
the lookup while largely ignoring the parser.  The final round will be<br>
merged post 3.21.<br>
<br>
A quick test shows the current code behaves as follows:<br>
<br>
ike:<br>
[       aes-sha1;dh21]    OK: AES_CBC(7)_000-SHA1(2)-ECP_<wbr>521(21)<br>
esp:<br>
[       aes-sha1;dh21]    OK: AES(12)_000-SHA1(2); pfsgroup=ECP_521(21)<br>
<br>
but:<br>
<br>
ike/esp:<br>
[    aes-sha1;ecp_521] ERROR: Non alphanum char found after in modp<br>
string, just after "aes-sha1;ecp" (state=ST_AK)<br>
[    aes-sha1;ecp_521] ERROR: Non alphanum char found after in modp<br>
string, just after "aes-sha1;ecp" (state=ST_AK)<br>
<br>
so things are at least consistent (and dh21 is the preferred name).<br>
I'll tweak the parser.<br>
</blockquote></div><br></div>