[Swan-dev] the great algorithm rename

[Andrew Cagney]

FYI, I did a partial merge (I don't like sitting on changes),

I've added the fully-qualified names and modified algparse and the
algorithm list code to use them.  Pluto proper still uses the old code
(old names and old format).  This way we get to play with the change
without hurting anything :-)

For instance:

$ ./algparse -v ike=aes
./algparse Encryption algorithms:
./algparse   AES_CCM_16         IKEv1:     ESP     IKEv2:     ESP
FIPS  {256,192,*128}  (aes_ccm aes_ccm_c)
[...]
[ike=aes]
    AES_CBC-HMAC_SHA2_256-MODP2048
    AES_CBC-HMAC_SHA2_512-MODP2048
    AES_CBC-HMAC_SHA1-MODP2048
$ ./algparse ike=AES_CBC-HMAC_SHA2_256-MODP2048
[ike=AES_CBC-HMAC_SHA2_256-MODP2048]
    AES_CBC-HMAC_SHA2_256-MODP2048

Andrew

On 22 June 2017 at 20:52, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> On 22 June 2017 at 15:05, Paul Wouters <paul at nohats.ca> wrote:
>> On Thu, 22 Jun 2017, Andrew Cagney wrote:
>>
>>> A two part "trivial" change I've had sitting here for some time is to
>>> update logging so that algorithm names are more consistently qualified
>>> and upper case.  For instance:
>>>
>>>    cipher: camellia -> CAMELLIA_CBC
>>>    prf: sha -> HMAC_SHA1
>>>    integ: sha2_256 -> HMAC_SHA2_256_128 (lets ignore truncbug for now)
>>
>>
>> works for me, might need some prefix_stripping for readability.
>
> I'd really like to get away from stripping prefixes and suffixes in
> the output logs as it leads to ambiguous names.
>
>>> -134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
>>> v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=sha group=MODP2048}
>>> +134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
>>> v2R2 {auth=IKEv2 cipher=AES_CBC_128 integ=HMAC_SHA1_96 prf=HMAC_SHA1
>>> dh=MODP2048}
>>
>>
>> While we are at it, I think "sent v2I2" should be replaced with "sent
>> IKE_AUTH request" and similarly "sent IKE_AUTH reply" and that we use
>> the exchange names properly.
>
> I'll look, I suspect it is a different printf.
>
>>> (I've got to wonder if the meaningless auth=IKEv2 should also be stripped
>>> out)
>>
>>
>> That is legacy mostly. In IKEv1, the IKE header told you if you were
>> doing RSA or PSK, and that info displayed there. In IKEv2, that information
>> is not in the IKE header, but inside the IKE_AUTH payload, so the code
>> just writes "IKEv2" there. It should really pull the data from elsewhere
>> and put in PSK, RSA, NULL or even NULL|RSA for asymmetric auth.
>
> Does it know?  Only the INIT packets have been exchanged.
>
>>> - for IKEv1 things are similar:
>>>
>>> -004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
>>> established {auth=RSA_SIG cipher=3des_cbc_192 integ=sha
>>> group=MODP1536}
>>> +004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
>>> established {auth=RSA_SIG cipher=3DES_CBC_192 integ=HMAC_SHA1_96
>>> dh=MODP1536}
>
> The above example is wrong, the new output for IKEv1 would be ... prf=HMAC_SHA1
> but I'm not sure how IKEv1 that term is.
>
>> Okau.
>>
>>> Part 2 then follows this up by replacing the IKEv1 centric
>>> enum_show_shortb() calls found in ike_info.c and esp_info.c:
>>>
>>>                        "%s(%d)_%03d-%s(%d)-%s(%d)",
>>>                        enum_show_shortb(&oakley_enc_names,
>>>
>>> ike_info->ike_encrypt->common.ikev1_oakley_id,
>>>                                         &enc_buf),
>>>                        ike_info->ike_encrypt->common.ikev1_oakley_id
>>>
>>> with ike_info->encrypt->common.name (et.al.).  The result is:
>>>
>>> -IKE algorithms found:  AES_CBC(7)_256-SHA2_256(4)-MODP2048(14)
>>> +IKE algorithms found:  AES_CBC_256-HMAC_SHA2_256-MODP2048
>>>
>>> and, unlike before, the new output can be fed straight back into the
>>> parser!
>>
>>
>> Sounds good.
>>
>>> Hopefully I'll be able to push this in a few weeks,
>>
>>
>> After v3.21 would be nice :)
>
> Yea.