Bug 1062924

Summary:	Several issues with hash algorithm selection in cipher suites
Product:	[Fedora] Fedora	Reporter:	Peter Backes <rtc>
Component:	openssl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	tmraz
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-10 10:57:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Peter Backes 2014-02-08 19:18:02 UTC

Description of problem:
According to "Recommendation for Key Management," NIST Special Publication 800-57 Part 1 Rev. 3, 07/2012, one should use twice the number of bits of hash as the number of key bits in block cipher. For example, use a SHA256 with AES128.

Yet, openssl cipher suite selection (openssl ciphers -v) contains lots of choices that violate this recommendation.

SHA512 is not offered at all for AES256; SHA384 is the maximum.

Further, SHA1 appears in quite a lot of ciphers suites. It has severe known weaknesses. Yet, unreasonable cipher suites with SHA1, like ECDHE-ECDSA-AES128-SHA even have higher priority than reasonable ones like DHE-RSA-AES128-SHA256.

Version-Release number of selected component (if applicable):
openssl-1.0.1e-39.fc21.i686

How reproducible:
always

Steps to Reproduce:
1. openssl ciphers -v

Actual results:
- Mac=SHA1 appears all over the list
- Mac=SHA512 does not appear at all.

Expected results:
- Mac=SHA1 appears only after all other 
- Mac=SHA512 should be top priority for Enc=AES(256)

Comment 1 Tomas Mraz 2014-02-09 17:14:05 UTC

This is request for upstream, please report in by mail to rt.

Note that the weaknesses of SHA-1 and also the birthday attack on collisions does not apply to the use of HMAC-SHA for message authentication. So the real required strength (not a "strength required by standard" though) for AES256 is HMAC-SHA256 and not HMAC-SHA512.

Comment 2 Peter Backes 2014-02-09 23:16:42 UTC

I am not an expert on cryptography, but two points:

- It is not obvious to me that collision attacks pose no threat under any circumstances in this context. It seems like a plausible conjecture, at first sight. But it may be wrong! Do you have a formal source that clearly says it's okay, and explains why?

- Let us assume you are right. Then, how is it to be explained that AES256 with SHA384 occurs in the list, as well as other combinations where the hash has more bits than the key of the block cipher? If you were right, it would be quite pointless! I don't know whether you are right or whether there is some rationale to do this, or whether I misunderstood something completely, but the question should definitely be investigated.

I reported all bugs opened yesterday upstream as well.