On 7 aug. 2014, at 05:01, David <[email protected]> wrote: > 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"
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
signature.asc
Description: Message signed with OpenPGP using GPGMail
