@STRENGTH in cipher list

[David]

Is there any downside to adding @STRENGTH to the cipher list?  From "man ciphers" (openssl), "the cipher string @STRENGTH can be used at any point to sort the current cipher list in order of encryption algorithm key length."

For example, the current default is:
  "HIGH+kEDH:HIGH+kEECDH:HIGH:!PSK:!SRP:!3DES:!aNULL"

which I've changed to the following in my installation:
  "HIGH+kEDH:HIGH+kEECDH:@STRENGTH:HIGH:!PSK:!SRP:!3DES:!aNULL"

Confirming the resulting list via "openssl ciphers -v 'HIGH+kEDH:HIGH+kEECDH:@STRENGTH:HIGH:!PSK:!SRP:!3DES:!aNULL'" shows that the ephemeral suites are still listed before the non-ephemeral suites, but now the longer encryption keys are also preferred over shorter ones.  (for a given enc key length, EDH and still preferred over EECDH)

Without @STRENGTH, the default list prefers any EDH suite (such as 128 bit keys) over any EECDH suite (including 256 bit keys).  But by adding @STRENGTH, now EDH or EECDH 256 bit enc keys are preferred over EDH or EECDH 128 bit enc keys...


Using the test at xmpp.net to confirm, here's the default cipher list before adding @STRENGTH:
  https://xmpp.net/result.php?id=46754

and here's the list after adding @STRENGTH:
  https://xmpp.net/result.php?id=48429

Is there any reason to not include @STRENGTH?


Going one step further, we can also sort the hash functions (for each enc key length) so that stronger hashes are preferred before weaker ones.

Adding ":+SHA384:+SHA256:+SHA:" just before @STRENGTH such as:
  "HIGH+kEDH:HIGH+kEECDH:+SHA384:+SHA256:+SHA:@STRENGTH:HIGH:!PSK:!SRP:!3DES:!aNULL"

results in:
  https://xmpp.net/result.php?id=48444
(ephemeral preferred over non-ephemeral, then longer encryption keys over shorter ones, and lastly, stronger hashes over weaker.)

- David

note: I wish openssl had a "@HASHSTRENGTH" string for sorting by hash strength, rather than hard coding the "SHA384", "SHA256" and "SHA" strings...  then the combination could just be: "...:@HASHSTRENGTH:@STRENGTH:...".  Or perhaps if sorting could be generalized such as "@SORTHASH:@SORTENC:@SORTEPHEMERAL", then the whole string could become: "HIGH:@SORTHASH:@SORTENC:@SORTEPHEMERAL:!PSK:!SRP:!3DES:!aNULL"

[Thijs Alkemade]

Hi David,

The sorting of ciphers is Prosody is primarily based on the key exchange: DHE
and ECDHE have very different characteristics, with each their pros and cons.
The difference between AES-128 and AES-256 is (by comparison) much smaller,
both should currently be sufficiently secure.

That said, with the clients that exist, I don’t think there will be much of a
difference in practice between 46754 and 48429: it will only lead to a
different result when a client supports ECDHE+AES256 and DHE+AES128, but not
DHE+AES256. I doubt that’s something you’ll encounter.

As for hash strength, I would give that even less importance than the
symmetric key length. SHA1 has some flaws already, but it’s still not anywhere
near being broken when used as a HMAC.

Regards,
Thijs