On 7 aug. 2014, at 05:01, David <da...@ad5ey.net> 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:
> which I've changed to the following in my installation:
> Confirming the resulting list via "openssl ciphers -v 
> 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:
> 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: 

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to