> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Dipak Gaigole
> Sent: Thursday, April 13, 2017 15:12

>  I will try with disabling FIPS.

Opinions differ, but many people - including myself - recommend not enabling 
FIPS mode unless it is explicitly required (generally because you work for the 
US Federal Government or a relatively small number of other organizations that 
let bureaucracy stand in the way of security).

> Where can i find current best practice cipher list? Or Can you suggest few?

The free ebook /OpenSSL Cookbook/ from Feisty Duck is a good place to start. It 
was updated only a year ago, so it's reasonably current.

https://www.feistyduck.com/books/openssl-cookbook/

Beyond that, you really need to be following current research, or at least the 
people who write knowledgeably about current research.

Ben wrote "AES256-SHA is both CBC and SHA1, neither of which is really a 
current best practice". Certainly the bloom is off the rose of SHA1, 
particularly since the "SHAttered" demonstration of a successful collision. The 
reality is that SHA1 is still fine for many purposes in practice; but if you're 
in a position to pick a better digest, it makes sense to do so. That means 
SHA-256 or SHA-384; or perhaps SHA3 with appropriate parameters, but SHA3 
hasn't seen widespread adoption yet. (That's more or less by design - NIST 
wanted to standardize SHA3 before it was needed.)

Regarding CBC, he presumably was referring to the various issues with CBC mode 
and the general move to various AE and AEAD combining modes, particularly GCM. 
AES-GCM suites are most people's default recommendation these days, when there 
aren't any compelling reasons to use something else. With GCM you have to be 
careful that you have a solid implementation and you never reuse an IV, so it's 
a bit easier for a non-expert to screw up. But considering the aforementioned 
issues with CBC, it's easy to see why people recommend it.

There's a ton of information - more than a non-expert can be expected to absorb 
- on these topics available online, even if we ignore the actual primary 
research and just look at treatments for lay readers. Adam Langley talks about 
the problems with AES-CBC in particular in this post, for example:

https://security.googleblog.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html

In TLS, AES-CBC is vulnerable to the BEAST (TLS 1.0 only) and Lucky13 attacks, 
given certain other conditions. Lucky13 (aka "Lucky Thirteen") actually applies 
to all block ciphers in CBC mode, if the implementation exposes certain timing 
side channels. These days decent implementations (including OpenSSL) try to 
remove or whiten side channels, but that's actually quite difficult to do 
comprehensively (see various pieces of research published over the past several 
years). Again, for many applications, these attacks simply aren't feasible. But 
many applications are developed without the benefit of a cryptographer who can 
look at them and decide whether you need to worry about them.


Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to