**RSA-PSS private keys**

The following command will generate an RSA-PSS private key:

```
openssl genpkey -algorithm rsa-pss -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_keygen_pubexp:65537 -out CA.priKey
```

Here's a sample one I just generated:

Here's the asn1parse output:

```
0:d=0 hl=4 l=1213 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 11 cons: SEQUENCE
9:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss
20:d=1 hl=4 l=1193 prim: OCTET STRING
```

**Regular RSA private keys**

This command, in contrast, will generate a regular RSA private key:

Here's a sample one I just generated:

Here's the asn1parse output:

```
0:d=0 hl=4 l=1213 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 13 cons: SEQUENCE
9:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption
20:d=2 hl=2 l= 0 prim: NULL
22:d=1 hl=4 l=1191 prim: OCTET STRING
```

**My question**

Why do RSA-PSS private keys have their own format? The probabilistic signature scheme (PSS) affects how the *signatures* are made. At least according to PKCS#1 v2.2. The keys are the same. They both make use of the same CRT parameters and what not. So why two different OIDs in this context? Is there a difference or is this just OpenSSL being dumb? And are there any other OIDs OpenSSL might be using to represent RSA private keys?

If you reuse the same key material for different algorithms, you rely not on the security of any one algorithm individually, but on the security of the composition of the two algorithms simultaneously.

For a particularly egregious example, if you use the same RSA public key for RSASSA-PKCS1-v1_5 and for HMAC-SHA256, the results might be entertaining.

It may turn out that while we have high confidence in the security of RSASSA-PSS assuming the RSA problem is hard, and reasonable confidence in the security of RSASSA-PKCS1-v1_5 because after decades nobody's made progress on it, the combination of the two with the same key material could have catastrophic results.

The theory behind these tags is presumably that associating such metadata with the key may serve to reduce the danger of accidentally reusing the same key material for different cryptosystems.

External links referenced by this document: