1
$\begingroup$

Is there a table (or a whitepaper from official sources) that compares the size of X509 certificates generated with RSA (starting from 1024 bits) and ECDSA (starting from 160 bits) ? Thanks for the support.

$\endgroup$

migrated from security.stackexchange.com Aug 23 '14 at 18:28

This question came from our site for information security professionals.

  • $\begingroup$ @MattNordhoff I have found on IETF, this slide Datagram Transport Layer Security in Constrained Environments. There are these certificate's sizes: ECDSA P-256: 91 bytes ECDSA P-384: 120 bytes ECDSA P-521: 156 bytes There aren't certificate's sizes of RSA 1024 (and lower and upper) and ECDSA P-160. How can i find these certificate sizes ? $\endgroup$ – Ellipticat Aug 23 '14 at 12:52
  • 1
    $\begingroup$ Ohhh. I totally misunderstood your question. I'm sorry. I think there have been one or two certificate size-related questions here or Crypto, but I don't have any information off the top of my head. I suppose you could create some certs and find out. It can be pretty variable depending on the meta data in the cert, no? (e.g. the length of your domain, of the CA's name...). $\endgroup$ – Matt Nordhoff Aug 23 '14 at 13:15
  • $\begingroup$ @MattNordhoff Maybe i have found what i wanted: An Introduction to the Uses of ECC-based Certificates on the Table 2 at page 5. What do you think ? Thanks for your answers. $\endgroup$ – Ellipticat Aug 23 '14 at 13:31
  • 1
    $\begingroup$ I do think that they should have mentioned that you would need point compression to reach those kind of differences. But personally I think that they just equated key strength with key size. I mean, I don't see any numbers for the domain parameters or public exponent either. Please take with a grain of salt. Note also that it makes quite a lot of difference if named curves are used or if the domain parameters are all present in the certificate; this makes comparison rather tricky. $\endgroup$ – Maarten Bodewes Aug 24 '14 at 0:26
  • $\begingroup$ Why not try and create two otherwise identical certificates using OpenSSL command line? You can try yourself! $\endgroup$ – Maarten Bodewes Sep 7 '16 at 16:22
1
$\begingroup$

Building such a table would be very difficult, because certificate-sizes depend on a lot of (variable-sized) things, including but not limited to:

  • usage constraints
  • signatures
  • public keys
  • URLs to CRLs and OCSP-servers
  • Name, location and other identifiers of the key-holder
  • Name, location and other identifiers of the issuing CA

However, you can estimate the difference between a pure ECC certificate and a pure RSA certificate yourself using simple math.

The relevant properties here are the public keys, the signatures and the signature algorithms. Let's assume that the signature algorithm identifiers are equally large in both cases (e.g. it's a simple OID or an integer).

Now we need to figure out the public key sizes. But this is easy as a public RSA key usually consists of the pair $(n,e)$ of which the lengths are known. Usually $e$ is 2-3 bytes long and $n$ is roughly 2048/8=256 bytes long. Now add these sizes together and ignore the structural ASN.1 encoding overhead and we get roughly 260 bytes of public key of the key-holder for RSA. RSA signatures are as long as the modulus so that's another 256 bytes coming from the CA. So in sum we're at about 520 bytes for RSA.

For ECC, the public key consists of one point, of which we only need the x-coordinate and an additional byte and an identifier identifying the used (standardized) curve. The curve point usually is as large as the curve modulus, e.g. 256/8=32 byte with one extra byte to encode the compression type. The OID is about 9 bytes long. An ECDSA signature by itself consists of two points, so that's another 66 bytes. Summing up you end up at about 110 bytes with ECDSA.

Similar calculations can be done for the security parameters of your choice.

$\endgroup$
  • 1
    $\begingroup$ Nitpick: ECDSA signature is two integers up to the order of G (and sometimes small enough to encode shorter), which is either equal to or only a small factor smaller than the order of the curve. More significantly, the CA key may be requred to be stronger than the entity key, and then the CA signature is bigger than an entity signature would be. $\endgroup$ – dave_thompson_085 Jul 10 '16 at 0:05
  • $\begingroup$ Yup, the key size and even type of the key of the CA doesn't have to correspond at all to the one of the certificate of the end-entity. Usually the key of the CA is stronger than the end-entity of course, but even that may not be the case if the CA uses RSA and the end-entity is using ECC. $\endgroup$ – Maarten Bodewes Sep 7 '16 at 16:20
  • $\begingroup$ The larger the size of the components, the higher the overhead of the DER (length) encoding. May not matter much, but it does make a difference. $\endgroup$ – Maarten Bodewes Sep 7 '16 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.