On Tue, Dec 16, 2014 at 05:17:01PM +0000, Viktor Dukhovni wrote: > In particular there MUST NOT be any fragile hand-tuning. All > ordering needs to be based on general principles.
+1. > One might for example say that any CBC cipher at 128+ bits gets a > baseline sorting strength of 128 bits. One might then apply either > "@STRENGTH" or "@SPEED" (new), the first of which adds "1" to any > CBC cipher whose key is longer than 128-bits, the second to those > that are equal to "128" bits. > > With AES AEAD the baseline could be "129", with similar "STRENGTH" > vs. "SPEED" boosts. Which would ensure that AEAD@128 beats CBC@256. > > However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement, > but some extensible algorithm. Any algorithm numeric strength assignments should be baked into the library, or perhaps configurable in a configuration file. The should not be known to applications. Ditto for any computaiton of overall strength of cipher-mode combinations. Internally using such numeric strength assignments is fine. In particular I want you to avoid the problem that Cyrus SASL had (and still has) with the "security strength factor (SSF)", where entire security mechanisms get boiled down to a single numeric strength factor even though a mechanism might negotiate cryptographic algorithms, and where applications end up hardcoding SSF values for things like Kerberos V5 (which has "SSF" of 56, because initially Kerberos V5 only supported 1DES). This is a horrible problem to have. Nico -- _______________________________________________ openssl-dev mailing list [email protected] https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
