[Swan-dev] new test failures

[Andrew Cagney]

On Wed, 13 Feb 2019 at 14:46, Paul Wouters <paul at nohats.ca> wrote:
>
> On Wed, 13 Feb 2019, Andrew Cagney wrote:
>
> > So looking at the parser, officially, for IKE, it expected:
> >
> >  encr-prf-dh
> >
> > but, unofficially, it could also parse (I don't think this was documented?):
> >
> >  encr-prf-integ-dh
> >
> > if we reverse things vis:
> >
> >  encr-integ-[prf]-dh
> >
> > then proposals like:
> >
> >   aes-sha1
> >
> > all still work fine - prf can be painfully derived from integ, but:
> >
> >   aes_gcm-sha1
> >
> > would break; force aes_gcm-none-sha1, or require some heuristic to
> > figure out <integ> should be skipped.
>
> Sure, so I guess encr-prf[-integ]-dh it is. I mean prf should be integ
> in all non-aead cases anyway. At least, we used to only support those
> and I wouldn't mind to keep it that way. I dont think we ever tested
> prf != integ on non-AEAD. So be careful allowing that now without a
> bunch of a new tests.
>
> so what happens now with ike=aes-sha2-sha2-dh14 ?

algparse -v2 'ike=aes-sha2-sha2-dh14'
    AES_CBC-HMAC_SHA2_256-MODP2048

i.e., it hides integrity HMAC_SHA2_256_128 because it was derived from the PRF.

I'll change fmt_proposal() to do this more generally - provided all
the integrity algorithms are 1:1 derived from a PRF then they are
hidden.

(I tried hacking things so <aead>-none-<prf>-... <aead>-<prf>- and
<encr>-<integ>-... work but it gets messy)