Is it possible to make ECDSA keys with insecure Debian OpenSSL?

Issuance Policy
1

After reading the announcement on blocking RSA key sizes because one can’t be sure if they were made with the old buggy OpenSSL from Debian, it got me curious on something that I couldn’t readily find an answer to in my web searching:

Is it possible for somebody to make an ECDSA private key with the buggy OpenSSL version? I know that ECDSA wasn’t nearly as popular in 2008 (and I don’t know if it existed in any version of OpenSSL from that era), but my (limited) understanding of the bug was that it affected all random number generation from it. So I thought it wouldn’t hurt to ask, and worst case I’d just look as silly as if I asked why NASA didn’t use the Space Shuttle to help save the astronauts on Apollo 13. :wink:

(And also, I assume the new key block applies to account keys as well as to leaf certificates? Again, I assume it doesn’t really matter for most users, but I don’t know if account keys currently allow for one of the less-standard sizes.)

4 Likes
2

Funny you should mention them. :wink: They were around here recently...

2 Likes
3

Hi @petercooperjr

an ECDSA key has 256 or 384 bits.

That's not an RSA key.

2 Likes
4

Yes, I know ECDSA is different from RSA, I’m asking if in addition to all oddball-sized RSA keys being unknown if it was made with an insecure OpenSSL, if it might somehow be possible for there to be ECDSA keys that we don’t know if they were made with an insecure OpenSSL.

3 Likes
5

From memory, I think ECDSA support was added to OpenSSL somewhere around 0.9.8 (haven’t actually verified), and the weak key bug was somwhat around 0.9.8c, so ECDSA support was highly new back then. The old posts from the time say that RSA and DSA keys are affected. If the OpenSSL version used was capable of generating ECDSA keys, it was probably affected too, since the EC key also needs a random number on which the curve point(s) is/are calculated.

4 Likes
6

It is not. From the 2009 paper "When Private Keys Become Public: Results from the 2008 Debian OpenSSL Vulnerability":

the version of OpenSSL deployed on Debian-derived distributions ships without any elliptic curve support.

9 Likes
7

I forgot to answer this. The block won't apply to account keys yet. We've done the analysis for leaf certificates to know what the impact will be, but we don't know what the impact will be for account keys. We want to double check that before applying a similar mitigation (which we would do mainly for consistency, since in general all our key quality checks are applied to both account keys and leaf keys).

4 Likes
8

ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits.
Although 521 bit ecdsa keys aren't yet supported by LE.... Or Are they?

3 Likes
9

Not according to the CPS. Though perhaps the wording for RSA should be updated to be "one of ..." instead of "between 2048 and 4096".

5 Likes
10

:woozy_face:

That's clearly gotta be a typo...

I'm sure it should be 256, 384, and 512 bits. I mean, hooray for the extra 9, but really?

2 Likes
11

Not a typo. Check section 3.1 of the JWA RFC. The ES512 alg specifier indicates “ECDSA using P-521 and SHA-512”. P-521 is the name of the NIST curve.

Also referenced in the ECC wikipedia page.

4 Likes
12

Interesting… I’m not very experienced with the pragmatic side of EC. I definitely feel like it’s time to learn though. At some point I’ll have to read up on exactly why they chose that size.

2 Likes
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.