1. Home
  2. Categories
  3. Coding Help
  4. Is there a guide to certificate algorithms?

Is there a guide to certificate algorithms?

  • Bulb

    Everybody I know has always been generating X.509 (TLS) certificates using algorithm¹ RSA, because it's traditional and because it only takes one parameter, the size.

    But recently I've seen some proposal that stipulated algorithm¹ EC with curve secp384r1² for a project CA, also stating other algorithm like Ed25519 might be considered for the subordinate keys, and we just discussed vulnerability concerning P-521, which openssl would know as EC secp521r1, in putty.

    The matter is further complicated by the fact that

    • the “normal” elliptic curves are called slightly differently in different sources and it's not always obvious whether they are referring to the same thing, and
    • the “Edwards” curves (25519 and 448) have two separate algorithms each, and X one for ECDH and an Ed one for EdDSA, which is supposed to be more efficient than the generic ECDSA. With the sources never even clearly stating which one corresponds to which keyUsage.

    Does anybody know of a guide on what to use for which purpose, usable by average developer or devops engineer? My google/duck/etc.-fu is failing me.

    ¹ As in openssl genpkey -algorithm option.
    ² The -pkeyopt ec_paramgen_curve: option.

    2 pcooper 1 Reply
  • Bulb

    … it crossed my mind to check what CFSSL supports[1]¹, and it looks like they offer:

    • RSA (rsa) size ∈ 〈2048, 8192〉 bits
    • EC (ecdsa) size ∈ {256, 384, 521} (the P-256, P-384 and P-521 curves)
    • Ed25519 (ed25519) (size ignored, it's just one curve)

    so that's probably the set that's actually usable. If Microsoft support EC at all, that is.

    And their default is actually ecdsa size 256.

    ¹ Use the source, Luke. I didn't even bother trying the documentation, I already know it sucks.

    1
  • pcooper

    @Bulb For general "web" TLS usage, use ECDSA P-256 if you can. If you need compatibility with old systems for some reason (like an email server, or old embedded systems, or whatnot) then stick with RSA 2048-bit.

    For things like SSH and GPG, use Ed25519. (Web stuff doesn't generally support it, or I'd recommend it there too.)

    2
  • pcooper

    If you're looking for something a little more authoritative than what I as a random person on the Internet says, then I'd suggest looking at Mozilla's configuration recommendations:

    https://wiki.mozilla.org/Security/Server_Side_TLS

    If you're a bit more paranoid, it's worth noting that the NSA's guidance as of a few years ago was to use P-384 or 3072-bit RSA for securing government systems, as they didn't seem to think P-256 or 2048-bit RSA was good enough, though I haven't seen any compelling reasons as to why.

    It's also worth knowing that ECDSA uses curves that have parameters hand-picked by NIST, and so doesn't qualify as a "Safe Curve". I figure if the US government recommends the military use it for important things then it can't be too bad, but just throwing that out there. That's the main argument I'm aware of for using Ed25519 instead, but it isn't generally supported by CAs/browsers/etc. for "normal" TLS yet (which I'm guessing isn't due to a vast conspiracy, but one never knows…).

    3 Bulb Jaime 2 Replies
  • Bulb

    @pcooper said in Is there a guide to certificate algorithms?:

    If you're looking for something a little more authoritative than what I as a random person on the Internet says, then I'd suggest looking at Mozilla's configuration recommendations:

    https://wiki.mozilla.org/Security/Server_Side_TLS

    Thanks, that's what I was looking for.

    If you're a bit more paranoid, it's worth noting that the NSA's guidance as of a few years ago was to use P-384 or 3072-bit RSA for securing government systems, as they didn't seem to think P-256 or 2048-bit RSA was good enough, though I haven't seen any compelling reasons as to why.

    Yeah, the Mozilla page says there ain't much of a difference and P-256 should be enough.

    It's also worth knowing that ECDSA uses curves that have parameters hand-picked by NIST, and so doesn't qualify as a "Safe Curve". I figure if the US government recommends the military use it for important things then it can't be too bad, but just throwing that out there.

    Perhaps they are confident they are the only ones who know the weakness :tinfoil-hat:.

    That's the main argument I'm aware of for using Ed25519 instead, but it isn't generally supported by CAs/browsers/etc. for "normal" TLS yet (which I'm guessing isn't due to a vast conspiracy, but one never knows…).

    My guess is that some of the implementors didn't want to bother with the separate imlementations that curve uses.

    1
  • Jaime

    @pcooper said in Is there a guide to certificate algorithms?:

    It's also worth knowing that ECDSA uses curves that have parameters hand-picked by NIST

    Fifty years ago, NIST hand picked S-boxes for DES, and it turned out that they tweaked them to be resistant to attacks that only NIST knew.

    Today, there's not so much trust that they will be as ethical, especially after they were already caught breaking Dual_EC_DRBG in exactly this way.

    4
Log in to reply