[Swan-dev] new test failures

Andrew Cagney andrew.cagney at gmail.com
Wed Feb 13 19:28:18 UTC 2019

On Wed, 13 Feb 2019 at 13:44, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 13 Feb 2019, Andrew Cagney wrote:
> > It would be from more algorithms being added to defaults.  But there's
> > another change I think needs to follow.  Namely changing the way IKE
> > proposals are formatted.  Namely remove the smart that suppresses
> > <integ>, so that what was:
> >
> >  <encrypt>-<prf>-<dh>
> >  AES_GCM_16-HMAC_SHA1-DH31
> That is really encrypt-integ-dh right?
> We don't specify/print the prf until now because we assume integ == prf
> except for AEAD.

Above is or IKE the code was printing the PRF because that was
slightly shorter than the equivalent INTEG.

ESP: <encr>-<integ>
AH: <integ>

(so yea, I see your point, IKE isn't exactly consistent)

> > becomes the longer:
> >
> >  <encrypts>-<prfs>-<integs>-<dhs>
> >
> > thoughts?
> I'd prefer encr-integ-prf-dh maybe ? I don't know.

What ever it is, I think it needs to be possible for the output format
to be cut/pasted into a config file and just work.   With the old
proposals and format it was possible.

So looking at the parser, officially, for IKE, it expected:


but, unofficially, it could also parse (I don't think this was documented?):


if we reverse things vis:


then proposals like:


all still work fine - prf can be painfully derived from integ, but:


would break; force aes_gcm-none-sha1, or require some heuristic to
figure out <integ> should be skipped.

> > I'll look at this.  It wasn't expected.  IKE proposals should prefer
> > 256 while ESP proposals should prefer 128.
> Ok,
> Paul

More information about the Swan-dev mailing list