[openssl-dev] cipher order

Emilia Käsper emilia at openssl.org
Sat Mar 5 00:36:54 UTC 2016

On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni <openssl-users at dukhovni.org>

> > On Mar 4, 2016, at 3:57 PM, Emilia Käsper <emilia at openssl.org> wrote:
> >
> > I've updated the pull to do a much more substantial cleanup.
> What will @STRENGTH mean in this context?  Will ignore
> the distinction between AES256 and AES128?

@STRENGTH will sort it back by symmetric encryption key strength. Which is
a bit of a bummer but I have no good answer for how to avoid it, because
this is what @STRENGTH's contract promises to do.

What does this
> do to the @SECLEVEL interface which tries to provide
> NIST-compatible bit strengths across multiple features?

@SECLEVEL will continue to work as expected, i.e., it will filter out the
ones that don't meet the level.

(@SECLEVEL operates directly on the cert, and does nothing to the
cipherlist alone. Which results in misleading output from the 'ciphers'
app, but that is a separate bug.)

> Or we just changing the default order, and allowing
> @STRENGTH to perturb it back, and @SECLEVEL to prune-away
> 128 leaving just 256, ...
> In other words how does this fit into the larger picture?

The ordering affects lists built from the predefined groups - ALL, DEFAULT,
HIGH, MEDIUM, LOW etc. More generally, it sorts each cipher group separated
by the ':'.

For example, if you do 'CAMELLIA:AES' then you get CAMELLIA ciphers sorted
by this preference, followed by AES ciphers sorted by this preference., and
if you do 'CAMELLIA:AES at STRENGTH' then - sadly - you get the symmetric
strength-sort back.

We could add a variant of @STRENGTH that re-sorts by our internal implicit
preferences (which we're allowed to change at any time), but that's not
going to happen for 1.1.0.

It is, however, possible, to achieve the same effect in multiple ways
- start from DEFAULT, and remove more ciphers, e.g.


- Or, if you want a superset of DEFAULT, start from ALL, and remove some


Both of these operations will preserve the preferences.

Anyway, the goal here is to improve the situation *if the user does
nothing*. It does not solve all the other problems of the API, but it does
not make them worse.


> --
>         Viktor.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160305/327bf070/attachment.html>

More information about the openssl-dev mailing list