Features/StrongerHashes

Support and use hashes stronger than SHA-1

Summary

Support stronger hashes than MD5 and SHA-1 (focusing on SHA-2 in particular, but making it easy to migrate to other hashes in the future), and use them by default where appropriate.

Owner

• Name: Mitr
• Email: mitr@redhat.com

Current status

• Targeted release: Fedora 11
• Last updated: 2008-12-17
• Percentage of completion: 10%

Detailed Description

The widely-used MD5 and SHA-1 hashes have known vulnerabilities ([1], [2]). These vulnerabilities are do not break the hashes completely, but it is prudent to migrate to stronger hashes (e.g. the SHA-2 family) as soon as possible (see for example the tables in [[3]]).

As many packages as possible will have SHA-2 hash support added, focusing on the most widely used and most security sensitive packages first. If it does not significantly affect interoperability, these hashes will be used by default.

Of particular interest if the RPM file format: The file format now has support for using stronger hashes in package signatures and payload file hashes, but it is not enabled by default because there are some interoperability issues when RPM packages using more than one hash type are used together. These need to be resolved, and tools that work with RPMs (e.g. yum, koji) need to support the RPM file format extensions. See [[4]] for current proposal and things that would break.

Another important area is hashes used in repodata, repodata signatures, package signatures, and release signatures (the signed SHA1SUM file). This might require small extensions to the repodata format.

Not all uses of hashes are security relevant and need to be converted. For example, these uses can be vulnerable to attacks on hash algorithms:

• Digital signatures
• Other uses of hashes to verify authenticity of data (e.g. the digitally signed SHA1SUM file that contains hashes of other files)
• Password encryption (/etc/shadow already uses SHA-2 in Fedora 10, but application-specific password stores often don't.)

These uses should be converted to better ensure integrity of important data:

• Detection of data corruption

These uses are probably not at risk:

• Combining data from various unpredictable sources into a few random bytes

Benefit to Fedora

A system more resistant to attacks on the hashes. This will also make it possible to build an operating system based on Fedora that will be certifiable for government use ([5]).

Scope

For RPM file hashes: RPM, yum, koji, spacewalk.

For repodata/release hashes and signatures: yum, createrepo, pungi.

At least one file copying tool (probably rsync or scp) and one backup tool (amanda?).

As many other individual packages that use hashes as possible.

How To Test

• Where changes in packages are local, test the packages one by one.
• Enable SHA-2 hashes in RPM, build RPMs that use them. Test various scenarios of systems that combine packages that use SHA-2 hashes and MD5 hashes (file conflicts and %config file handling in particular).

User Experience

• No user action is necessary to continue to be able to use Fedora.
• Users that require use of strong hashes at the cost of interoperability might have to configure some applications manually to use the strong hashes.
• RPM files generated on Fedora will not be installable on systems with older versions of RPM by default; rpmmacros changes will be necessary to build backward-compatible RPMs

Dependencies

None

Contingency Plan

• For isolated packages, revert the specific package.
• For RPM file format, revert the RPM configuration change and rebuild affected packages.

Documentation

None yet. Tracking bug #461972 [6].

Release Notes

Should mention how to build backward-compatible RPMs and how to enable SHA-2 hashes in applications that disable them by default.

Comments and Discussion

• See Talk:Features/StrongerHashes

---