[openssl-dev] Circumstances cause CBC often to be preferred over GCM modes

[Nico Williams]

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 at 128 beats CBC at 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
--