Hello,
I've done some research of other peoples opinions and that's the best I can do. Please advise SVP.
I want to us ECDSA for my Web server's SSL certificate via an ACME client to Let's Encrypt and maybe later BuyPass.
I thought that EC is better than RSA, but now I don't think so. The answer seems to be: it depends.
Safe Curves (SafeCurves: Introduction) says that the NIST curves are P-224, P-256 (ye prime256v1 and what I was trying to implement with Python3 ACME client), and P-384 and NOT SAFE. They did not mention RSA. They give key type Curve25519 a fully passing grade. I think that is ye X25519, also know as ed25519. Linux program ssh has ed25519. I don't trust NIST 'cause I don't trust NSA.
This is a comparison that favors old RSA over new ECDSA: Comparing ECDSA vs RSA - SSL.com
|
This suggests that RSA keys are mostly safe: Is it still safe to use RSA Encryption? - Hashed Out by The SSL Store™
|
So my conclusion is to prefer in descending order of preference: ed25519, RSA-4096 (I suppose RSA-8196 is sorta overkill maybe. I suspect quantum computers would make it not overkill, but then mobile devises might not like it for the overhead.)
My local version of openssl is:
OpenSSL 1.1.1d 10 Sep 2019
When I openssl ecparam -list_curves I do NOT get X25519.
However, I was apple to generate a private key per ye documentation (manpage for genpkey): /docs/man1.1.0/man1/genpkey.html
Hey, I have that manpage on my linux. So whadayouknow? My remote virtual machine has OpenSSL 1.0.2g 1 Mar 2016 and no X25519.
On my local machine, the CSR generation fails only for the X25519 private key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Two-letter Country Code [US]:
139873970037888:error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not supported for this keytype:../crypto/evp/pmeth_fn.c:40:
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Two-letter Country Code [US]:
139873970037888:error:0608D096:digital envelope routines:EVP_PKEY_sign_init:operation not supported for this keytype:../crypto/evp/pmeth_fn.c:40:
Supposing I can get a resolution to using X25519, anybody know of how to get the X and Y coordinates of a public key of type X29915 in the Python3 language? The PYPI repository has python-jose, which uses pyca/cryptography, which is in PYPI as plain, old 'cryptography 2.8'. My exploration of pyca/cryptography's documentation is what led me to the safe curves webpage. Maybe I can get the x and y coordinates with it. Looks scary.
So any informed assessments on:
(1) key types RSA, PRIME-256, and ed25519,
(2) on openssl and X25519, or
(3) getting the X and Y coordinates of the ed25519 public key for making a JSON Web Key (JWK) for a ACME client in Python3.
The ACME protocol is rfc8555 and refers to 'the "EdDSA" signature algorithm using the "Ed25519" variant'. Interestingly, rfc 7518 for JWA (A is for Algorithms) does not have ed25519--though I can't rule out a standards repository somewhere could have it as an addition, for all I know--and does have the curves P-256, P-384, and P-521.
Emhhm.
Maybe I should just use RSA and likewise regress to ed for all my editing needs. I knew a consultant who used ed and was quite good. My supervisor joked about rubbing two sticks together. I'm sure there's lot of vi fans here. 'Twas the night before Christmas and I was stirring. Stirring I tell ya. Me and a mouse.
Douglas Morris
