Description of problem: When you run genkey, you get a certificate with SHA-1 signature. SHA-1 is insecure and should not be used anymore according to NIST Special Publication 800-131A (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf) Use at least SHA256. See p. 14: "SHA-1 shall not be used for digital signature generation after December 31, 2013." Also, hash strength should match RSA strength. See http://www.keylength.com/ Version-Release number of selected component (if applicable): crypto-utils-2.4.1-48.fc20.i686 How reproducible: always Steps to Reproduce: 1. genkey localhost.localdomain Actual results: you always get a certificate with SHA-1 signature Expected results: RSA <= 3072 bits yields SHA-256 signature 3072 < RSA <= 7680 bits yields SHA-384 signature 7680 < RSA yields SHA-512 signature
I disagree that this is a RFE. SHA-1 is broken and deprecated for signatures. In addition, using SHA-1 makes larger RSA key lengths quite pointless. Hence, this is a bug, IMO.
There you have it, it's soon going to cause real trouble: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2-R4XziFc7A/YO0ZSrX_X4wJ pls consider fixing this now.
note that the older Makefile method in /etc/pki/tls/certs , which calls openssl , uses SHA-256, at least in Fedora 21 (I believe both tools inherit the defaults of their helper apps, 'certutil' for genkey and 'openssl' for Makefile).
grr, actually crypto-utils uses its own 'keyutil' tool for some stuff, as well as calling certutil. i'm trying to work up a patch for this.
certutil -Z (for signature hash) is undocumented see https://bugzilla.mozilla.org/show_bug.cgi?id=1058870 keyutil uses SHA1 but that can be changed. keyutil is a stripped down certutil like tool to support writing pem files. Hope this info helps you some.
OK, I think I have a handle on this now, testing patches. Note that kaie has a patch in review to change the default of NSS's 'certutil' tool to SHA-256: https://bugzilla.mozilla.org/show_bug.cgi?id=1058933 when that change goes into nss, genkey's 'nss' path would get fixed for free. The 'openssl' path still needs fixing in genkey. I think I'll still include a genkey-level fix for the 'nss' path in my submission, though, so this doesn't have to wait for a new nss release or package to get fixed.
Created attachment 932826 [details] patch to use SHA-2 hashes This is a git-formatted patch (against the package git master branch) to make genkey use SHA-2 hash functions by default: SHA-512 if the key length is > 7680 bits, SHA-384 if the key length is > 3072 bits, and SHA-256 otherwise. It has a fairly detailed git commit message and in-line comments in the source files touched. I've tested it on both paths, with an F20 scratch build, generating 2048-bit and 4096-bit keys and ensuring the appropriate functions are used in the generated certificates.
Hum, that version only handles generation of self-signed certs, not CSRs, on the NSS path. I'm testing a new version which handles both now (by creating a helper function for figuring out the appropriate hash function and calling it after setting the key length).
Created attachment 932828 [details] patch to use SHA-2 hashes, v2: apply to CSR as well as self-signed cert creation on NSS path Here's an updated version of the patch, which should be more comprehensive. There would be a few different ways to do this, I'm not really used to the somewhat old-fashioned style of genkey.pl so I wasn't sure which would be considered cleanest. you *could* use only a single getHashForKeyLength() function if you really crowbarred it in somewhere (top of getRandomDataWindow() , for instance) but that seemed ugly. I'm not entirely sure if it's best practice to only set the default value of $hashalg once (at the top of main, when first asserting the variable), or set it both there and in the getHashForKeyLength() function as well, as I do in this version. please do review carefully, I'm only the QA monkey :) again, I've tested this on both paths with both 2048 and 4096 bit keys (not 8192, life's too short, but I did test that once with an earlier version just to make sure 'SHA512' does actually work, and it was fine).
Looks fine to me. Minor note, I forgot to mention that RSA = 2048 with SHA-224 is still deemed "acceptable" by NIST, so you can add this one, if you like.
Thanks. FWIW, saying this is going to cause 'real problems' is stretching things a bit. Well, I can see one very specific corner case, but the common cases, no. The two things that wind up with SHA-1 hashes are: 1) self-signed certificates 2) CSRs So far as I can see both the practical and theoretical impact of 1) for server certificates is "very close to nothing". self-signed certificates are already treated as untrusted by browsers in any case - the browser experience when visiting a site with a self-signed cert with an SHA-1 hash is probably going to be exactly the same as the browser experience when visiting a site with a self-signed cert with an SHA-2 hash. in theoretical security terms, with my in-depth wikipedia-gleaned understanding of public-key cryptography, I believe that given what a self-signed server certificate *is*, it doesn't matter much what the hashing mechanism is. running a hash collision attack on a self-signed server certificate gains you nothing at all. Ditto for 2). I dug out the explanation of why CSRs are signed at all from the RFC (OK, OK, from the RFC by way of wikipedia...): "Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course." , from https://tools.ietf.org/html/rfc2986#page-4 . So again, compromising the signature on a CSR really doesn't get you anywhere very significant. I don't think it's an 'attack' vector that's going to cause anyone any lost sleep. Now, I think there is one unusual case where there could just arguably be a 'real' impact. genkey has a mode for generating a CA certificate - genkey --makeca . It's supposed to be used for setting up a private CA. This goes through the affected functions and so generates a CA certificate that uses SHA-1 hashing. Such a cert *is* potentially vulnerable to hash collision attacks. It still seems fairly unlikely that all the requisite elements for such an attack to be viable would be in place in any situation where someone had set up a private CA using genkey, but it's theoretically possible, I guess. (Also note that it's not like SHA-1 is known to be practically vulnerable to attack right now, it's only supposed to be really *gone* by 2017, and genkey's default lifetime for a CA cert is only two years).
By "real problems" I meant that a popular browser will soon begin to nag users about it (and rightly so). We both don't know the exact impact of the hash algorithm. Things go wrong in places that one overlooks and doesn't expect to be a problem. Too much time has been wasted in the past, and is still wasted, by discussing whether things are still practically secure despite of the allegedly merely theoretical possibility of a security problem. I can only recommend not to that, but simply to fix the problem. Given enough effort, time and money, most security issues, however remote and theoretical, can be exploited (cf. http://slashdot.org/story/14/08/26/2233257/project-zero-exploits-unexploitable-glibc-bug). We need to fix those issues, not speculate about their exploitability. That should be the the key insight of the Snowden age.
"By "real problems" I meant that a popular browser will soon begin to nag users about it (and rightly so)." My point is that browsers already nag you anyway if you're using a self-signed certificate, and that's the only kind of certificate genkey produces. It's not like CAs are signing other people's certificates using genkey, it's not even capable of that.
Yes, but it's a different nag screen. I have to finish a paper for VMCAI and I want to waste my braincells on that rather than an attempt to refute your conclusion that there's no problem with the weak hash for the relevant use cases.
Commit: http://pkgs.fedoraproject.org/gitweb/?p=crypto-utils.git;a=commitdiff;h=a2aaef550cf5b7b9c6eeb2a150058840b2c90319 Package: crypto-utils-2.4.1-56.fc22 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=574680
Thanks for the patch Adam!
Commit: http://pkgs.fedoraproject.org/gitweb/?p=crypto-utils.git;a=commitdiff;h=a2aaef550cf5b7b9c6eeb2a150058840b2c90319 Package: crypto-utils-2.4.1-56.fc21 Build: https://koji.fedoraproject.org/koji/buildinfo?buildID=574682
crypto-utils-2.4.1-56.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/crypto-utils-2.4.1-56.fc21
Package crypto-utils-2.4.1-56.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing crypto-utils-2.4.1-56.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10225/crypto-utils-2.4.1-56.fc21 then log in and leave karma (feedback).
crypto-utils-2.4.1-56.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.