[Swan-dev] a better unified proposal matcher

Andrew Cagney andrew.cagney at gmail.com
Fri Feb 27 08:23:52 EET 2015

On 26 February 2015 at 15:28, Paul Wouters <paul at nohats.ca> wrote:
> On Tue, 24 Feb 2015, Andrew Cagney wrote:
>> Never post before lunch, or coffee, here are better O() guesses:
> [ more statistics ]
> Can we go through the received list of transforms and delete those we
> know we do not support/allow as a preprocessing item? Before we try
> to combine these bits?

By bits I'm guessing you mean the different transform types: ENCR,

The critical change is to not do any combinatory explosion at all.
Instead just go through the transforms once; and look at each

That means, instead of trying to form and then match an entire
combination such as aes_cbc+sha2_256+modp2048+sha2_256 we look at the
transforms independently, and combine the result at the end.

> In our default proposal, we would have (ignoring for now combos that are
> not allowed)
> ENC: aes_cbc, aes_gcm, 3des
> INTEG: sha2_256_, sha2_512, sha1, md5, null
> PRF: sha2_256_, sha2_512, sha1, md5
> DH: 1024, 1536, 2048

This first pass is close to the suggestion of only doing one pass.  At
it's simplest, and assuming our end has only one proposal:

for each proposal
   for each transform
       if transform is encr and we don't have an encr transform saved
and transform in our list of acceptable transforms
             save the encr transform as part of the match
       if transform is integ and ...

at the end of this we will have hopefully saved a transform of each
type and that is the accepted crypto-suite
If we've multiple proposals at our end, the inner loop gets more
complicated - we could do more pre-filtering, and different lookups;
but the principal remains.

> If strongswan now comes with 16 PRF's, we can just delete 12 of them.
> If they come with 10+ DH groups, we can just delete all but 3.

I suspect I can construct a proposal set that gets past the above, but
still causes the below:

> Once done, we do the combinatory explosion. Then we take good care not
> to allow illegal combinations like aes_cbc-null or aes_gcm-md5.
> Paul

More information about the Swan-dev mailing list