On 7 aug. 2014, at 05:01, David 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
