Added the special private key that triggers bug (CVE-2011-4354) in 32…

[Trust-Worthy]

… bit linux distros running openssl 0.9.8g

According to this paper, https://eprint.iacr.org/2011/633, the authors (@bbbrumley being one of them) identified a complex and unique EC bug that can be triggered for P-256 & P-384 curves in openssl 0.9.8g on 32 bit systems. @bbbrumley has helped me find a unique private key that can trigger the bug in the aforementioned version. This special private key is included in the changes to the evppkey_ecc.txt file. The correct public key is also included.

This is my first pull request and attempt at writing a regression test. Please let me know any feedback that you may have.

Thanks!

Checklist

• documentation is added or updated
• tests are added or updated

[bbbrumley]

Thanks!

Could you replace the private key with the output of

openssl pkey -in foo.pem

This will put it in a format consistent with the other keys.

You'll notice the difference because the PEM will start with

-----BEGIN PRIVATE KEY-----

instead of

-----BEGIN EC PRIVATE KEY-----

[bbbrumley]

@Trust-Worthy I am also guessing the maintainers are gonna want a signed CLA here. @romen what do you think

[t8m]

For the priv/pub key pair being really useful we will need some testcases added with it. I.e., we need Derive/PeerKey/SharedSecret triplet added. Also the names seem to be duplicate with the following priv/pub keys which is wrong.

[bbbrumley]

whoops yes name collision thanks @t8m!

but also PrivPubKeyPair is a test -- it check the consistency of the given key pair.

[bbbrumley]

.. and in that public-key-from-private-key computation, is exactly where the bug is triggered. I'll get @Trust-Worthy to add a little more detail, at least to this thread, bc without the context it just looks like random KATs going in

[t8m]

Ah, ok. Then please at least rename the keys

[t8m]

Yes, we will need a signed CLA to be able to accept this PR.

[bbbrumley]

I can confirm that recent OpenSSL gives you this

$ openssl pkey -in key.pem -text
-----BEGIN PRIVATE KEY-----
MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcEJzAlAgEBBCCrgvdSKyu+zo6wERHP
+5gkQ5yoY1SIgHYyZXQXRr+O2A==
-----END PRIVATE KEY-----
Private-Key: (256 bit)
priv:
    ab:82:f7:52:2b:2b:be:ce:8e:b0:11:11:cf:fb:98:
    24:43:9c:a8:63:54:88:80:76:32:65:74:17:46:bf:
    8e:d8
pub:
    04:e6:eb:0d:84:e1:cc:5d:85:b5:5b:cf:c4:d1:34:
    5b:32:14:af:2b:86:b4:8a:9b:b9:fb:10:e8:29:b8:
    73:e7:95:81:80:44:47:c4:b5:80:bd:9b:a0:88:3a:
    72:a2:c8:58:a9:53:ec:78:6b:9b:10:f0:38:66:91:
    9d:89:e6:1a:8c
ASN1 OID: prime256v1
NIST CURVE: P-256

.. and a 32-bit build of 0.9.8g gives you this

$ openssl-0.9.8g/apps/openssl ec -in key.pem -text
read EC key
Private-Key: (256 bit)
priv:
    00:ab:82:f7:52:2b:2b:be:ce:8e:b0:11:11:cf:fb:
    98:24:43:9c:a8:63:54:88:80:76:32:65:74:17:46:
    bf:8e:d8
pub: 
    04:c1:ca:2c:ab:6f:b8:ad:3a:54:70:ce:5b:1d:51:
    52:63:40:94:01:d9:4f:5c:b5:9e:81:e6:6c:b3:cd:
    c2:a5:26:bc:cc:c4:9d:7b:34:8b:e1:6a:72:50:43:
    9f:e7:21:de:ee:e5:5e:33:e5:b0:8b:c2:09:c5:e6:
    b7:94:bf:93:53
ASN1 OID: prime256v1
writing EC key
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIKuC91IrK77OjrAREc/7mCRDnKhjVIiAdjJldBdGv47YoAoGCCqGSM49
AwEHoUQDQgAEwcosq2+4rTpUcM5bHVFSY0CUAdlPXLWegeZss83CpSa8zMSdezSL
4WpyUEOf5yHe7uVeM+Wwi8IJxea3lL+TUw==
-----END EC PRIVATE KEY-----

So yes, this is a regression test for that CVE.

[bbbrumley]

@Trust-Worthy when you have time, please take a look at the CLA issue the maintainers mentioned.

[Trust-Worthy]

I just emailed my CLA to legal@opensslfoundation.org.

Thank you @t8m for your feedback. Also, thank you @bbbrumley for helping me clean up the key.

This is the just the first of many successful pull requests!