On 11/30/2015 12:07 PM, Julien Vehent wrote:
On 2015-11-30 12:47, Robert Relyea wrote:
I've always found the 128 bit prioritized over 256 a silly recommendation, I support reordering.

Can you expand on why you think it is silly?

The argument went that 128 bit was 'sufficient' and there was a performance 'hit' doing 256. Sufficient changed our criteria from objective (stronger first, then performance) to subjective (random definition for sufficient). At one point DES 56 was considered 'sufficient'.

The case in point, we've subjectively decided 128 bit isn't sufficient. That was highly predictable (attacks get better, the subjective line will move again).

At Red Hat, we've already reordered this. We were having problems connecting to servers who had the following logic: SSL connect to client. Check to see if the key strength was sufficient. If not display an error message through the SSL connection. The server was assuming if a client connected with a 128 cipher, then it must not be able to do a 256 bit cipher because why would it prioritize 128 bits over 256 bits? The server didn't turn off the weaker ciphers because the server wanted to give the weaker clients a reasonable error message.

The original thread [1] had a long discussion on this topic.

Yes, which is why I didn't push it. I gave my reasons for disagreeing. They weren't accepted. I saw no reason to get religious about it. Still didn't mean I didn't think the decision was silly. I find life goes better if you only fight against patently wrong decisions and let silly ones go with just giving notice.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

dev-tech-crypto mailing list

Reply via email to