So I have read up and have a decent understanding of how the crypto works with Elliptic Curve Cryptography. I also think I have an understanding of how signing works with things like Elliptic Curve Digital Signature Algorithm (ECDSA). The certificate and private key on my web server are both 2048 bit RSA keys. Can I only do RSA signatures because that is what my keys are? If I can do things like ECDSA, how is the trust chained from my RSA keys to the ECC keys that are used for signing under ECDSA?


Elliptic-curve (EC) cryptography is significantly different than traditional RSA-style cryptography.

Bottom-line Up Front (BLUF): Your server can only handle RSA key exchanges given the information you provided.

As a primer, both of these are asymmetric cryptographic protocols. They are used to securely transmit a SYMMETRIC key that both parties use to encrypt the actual data/message. The reason behind this is that asymmetric cryptographic protocols are extremely computationally intensive as compared to symmetric cryptographic protocols (in the general case). So encrypting a large dataset or a streaming message would be resource intensive. Instead, the symmetric key is used.

So back to your question. Your digital signature has been created and signed stating that your public key is a 2048-bit RSA key. That necessarily means that your private key is also an RSA key - You cannot use EC protocols with that digital signature or the keys that you possess. So the answer to your first question is: Yes, you can only do 2048-bit RSA key exchanges on your web server.

To create/generate EC keys you would have to either be issued one (or more) from an upstream provider or generate them yourself via a 3rd party tool like openssl.

As an additional aside, readers may be wondering why you would use EC over RSA. Well that's because of performance. In theory (at least to what's been proven to date in the security community), EC keys take up much less space and run more quickly on a particular system (hardware implementations may vary that contradict that statement, but in solely software implementations on the same system EC should be faster than the equivalent-strength RSA).

For instance, according to the openssl page on EC (http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography), encrypting a 256-bit symmetric key in RSA would require a15360-bit RSA key but only a 512-bit EC key.

So you see, if you're running an HTTPS server with lots of clients, you would want EC keys because you can secure the symmetric key much more quickly and reduce your overall processing by a lot (including the amount of data sent over the wire in the key exchanges).

On to your second question. If you were to have EC keys, they would likely be in a different certificate because they would be issued/generated at a different time. The trust would be from whatever source your current trust is - whether that's an internal root certificate authority or an external one like verisign or godaddy.

In theory, if your certificate were granted the proper permissions, it COULD be used to sign down-stream certificates (meaning, your certificate is an intermediate certificate authority that can then sign requests from others within your organization). If that were the case (not likely given your certificate is used on a web server), you could create EC keys and an EC certificate signing request and issue a certificate that is authorized by your 2048-bit RSA signature to permit the use for your, for example, 384-bit EC key.

I hope this helps some. I'd read the openssl link I posted for a bit more on this.

  • It is correct that ECC keys are much smaller than RSA (and DSA or DH) keys for the same currently-desired security levels, and ECC operations are faster/cheaper than comparable RSA privatekey operations (but not much better than DSA or DH). For web = HTTPS = SSL/TLS most of the rest is wrong. First, it is possible to encrypt with ECC (ECIES, which is basically one-way ECDH), but SSL/TLS never does so, and openssl does not implement it; notice the referenced wiki page does not have the string "encrypt" anywhere. ... – dave_thompson_085 Jul 27 '14 at 20:16
  • ... In addition to original RSA-only key-exchange, which does encrypt and "transmit" the premaster secret but not "a" key that both parties use, SSL/TLS widely supports ECDHE-RSA and ECDHE-ECDSA key exchanges where the premaster is "agreed" by combining ephemeral key material from both parties. ECDHE-RSA is signed by an RSA cert with key such as the OP has; ECDHE-ECDSA is signed by an EC cert with (longterm) key. It also allows ephemeral classic DH signed by RSA or DSA, but DSA certs are rare; see security.stackexchange.com/questions/14731/what-is-ecdhe-rsa ... – dave_thompson_085 Jul 27 '14 at 20:18
  • ... Finally, it supports several methods that don't use asymmetric crypto at all. ECDSA and DSA signatures are smaller than RSA -- but plain-RSA key exchange usually uses no signature at all. ECDH key exchange is smaller than DH or akRSA, at least with named curve as is usual. But the SSL/TLS handshake is usually overwhelmingly dominated by the server certificate chain (almost always used) and client certificate chain when used (rarely), and possibly the ticket when used (mostly newer implementations); the key-exchange data is pretty much lost in the noise. – dave_thompson_085 Jul 27 '14 at 20:20
  • -1 for misinterpretation of equivalence of RSA / EC / symmetric key as needing a 512-bit EC key to encrypt a 256-bit symmetric key. (The equivalence is from the best known attacks; brute forcing an ~15000-bit RSA key with GNFS would take about 2^256 work as would brute-forcing a 256-bit symmetric key for an idealized symmetric cipher; you can easily encrypt a 256-bit symmetric key with a 1024-bit RSA key). Also as dave_thompson_085 pointed out, your answer doesn't really answer the questions or distinguish key exchange from signing. – dr jimbob Aug 26 '14 at 21:18

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.