Many crucial applications - Apache, above all - make use of the ssl-cert eclass. I noticed it defaults to generating 1024b RSA which is not top-notch security nowadays. I think the eclass should be revised with today's security demands in mind. If nothing, the hardened profile(s) should get an upgrade.
For "openssl x509 -req" there could be an explicit call for a SHA-2 hash. For "openssl genrsa" keylength could be set to 2048/4096 b (the latter for hardened). Etc.(?)
Umm, s/^Many/A few/ :)
# Max Kalika <firstname.lastname@example.org>
Someone should fix that.
For people using self-signed certs, 1024 bit rsa is pretty strong at 80 bits. Let's not follow the herd and install 2048 (or higher) bits by default.
A case can be made perhaps for 1280 bits which has about 89 bit security and does not incur the performance penalty of 2048 bit rsa (which has a gnfs factoring cost of 2^110). Not everything is a desktop. If you need a different security model, just generate your own certs.
My vote would be WONTFIX although I believe 1280 bits would be a reasonable choice as well.
You're right after all, 1024b RSA and SHA1 (currently used in the eclass IIRC) are safe for the time being. If the default profiles are to stick with these, so be it. But for hardened this could be bumped today - hardened shouldn't restrain itself with handheld devices for the common user and the common app (if that's what you meant by not everything being desktop). 1024xSHA1 means living on the edge. Unexpected stuff in cryptanalysis happens; upgrading certs could take admins days to years. ... Yeah, perhaps even the default profiles... It's true that not everything is a desktop, but most things do are a desktop and the minority of admins can still make the simpler certs manually.
But then, we're talking self-signed certs here, as you fittingly put. Well, I'm giving this a "minor", quitting any more arguments and leaving it to your decision.
as long as the certs only get used for self signing, i don't see any value in increasing things
the certs also include values which don't make sense to try and get publicly signed ("localhost", "For Testing Purposes Only", etc...). that means people will have to generate their own cert from scratch (and thus it'll be up to them to pick the right bit size). i don't think they'll look at the existing cert as any sort of input for picking values.
if people don't have contradictory thoughts, i'll WONTFIX this.
(In reply to SpanKY from comment #6)
> as long as the certs only get used for self signing, i don't see any value
> in increasing things
If there's use case (for whatever reason) to trust a self-signed certificate then users should get a sufficient level of security IMO.
B/c there otherwise there would be no special reason to even use 1024. 768 bits would be still enough too for testing purpose only.
So what's about at least to mention this topic by putting a comment line like "#SSL_BITS=4096" in make.conf ?
(In reply to Toralf Förster from comment #7)
do you have an actual use case where the trust is required ? i don't mean setting up a test apache instance and verifying things on your LAN. if you want the certs to be used beyond your two systems, you need to generate your own.