[Swan-dev] new test failures
andrew.cagney at gmail.com
Wed Feb 13 22:44:25 UTC 2019
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'
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
(I tried hacking things so <aead>-none-<prf>-... <aead>-<prf>- and
<encr>-<integ>-... work but it gets messy)
More information about the Swan-dev