On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
> > > On Mar 4, 2016, at 3:57 PM, Emilia Käsper <emi...@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@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 already: - start from DEFAULT, and remove more ciphers, e.g. "DEFAULT:!3DES:!AES128" - Or, if you want a superset of DEFAULT, start from ALL, and remove some ciphers: "ALL:!MEDIUM:!LOW:!aNULL:!eNULL:!IDEA:!SEED" 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. Emilia > -- > Viktor. > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev