Bug 1062924 - Several issues with hash algorithm selection in cipher suites
Summary: Several issues with hash algorithm selection in cipher suites
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-08 19:18 UTC by Peter Backes
Modified: 2017-01-10 10:57 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-10 10:57:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.