Menu
RSA Private Key Token, 4096-bit Modulus-Exponent External Form. This RSA private key token and the external X'09' token is supported on the Crypto Express2 Coprocessor and Crypto Express3 Coprocessor. X'09', section identifier, RSA private key, modulus-exponent format (RSAMEVAR). X'00', version.
If you've been working with computers for a while, you may recognize the stuff between -----BEGIN PUBLIC KEY----- and -----END PUBLIC KEY----- as being base-64 encoded. Simply put, it's binary data that's been encoded into easily printable ASCII characters.
I wanted to help explain what's going on here.
An RSA "Public Key" consists of two numbers:
Using your RSA public key as an example, the two numbers are:
The question then becomes how do we want to store these numbers in a computer. First we convert both to hexadecimal:
RSA invented a format first:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
They chose to use the DER flavor of the ASN.1 binary encoding standard to represent the two numbers [1]:
SEQUENCE (2 elements)
INTEGER (2048 bit): EB506399F5C612F5A67A09C1192B92FAB53DB28520D859CE0EF6B7D83D40AA1C1DCE2C0720D15A0F531595CAD81BA5D129F91CC6769719F1435872C4BCD0521150A0263B470066489B918BFCA03CE8A0E9FC2C0314C4B096EA30717C03C28CA29E678E63D78ACA1E9A63BDB1261EE7A0B041AB53746D68B57B68BEF37B71382838C95DA8557841A3CA58109F0B4F77A5E929B1A25DC2D6814C55DC0F81CD2F4E5DB95EE70C706FC02C4FCA358EA9A82D8043A47611195580F89458E3DAB5592DEFE06CDE1E516A6C61ED78C13977AE9660A9192CA75CD72967FD3AFAFA1F1A2FF6325A5064D847028F1E6B2329E8572F36E708A549DDA355FC74A32FDD8DBA65
INTEGER (24 bit): 010001
The final binary encoding in ASN.1 is:
30 82 01 0A ;sequence (0x10A bytes long)
02 82 01 01 ;integer (0x101 bytes long)
00 EB506399F5C612F5A67A09C1192B92FAB53DB28520D859CE0EF6B7D83D40AA1C1DCE2C0720D15A0F531595CAD81BA5D129F91CC6769719F1435872C4BCD0521150A0263B470066489B918BFCA03CE8A0E9FC2C0314C4B096EA30717C03C28CA29E678E63D78ACA1E9A63BDB1261EE7A0B041AB53746D68B57B68BEF37B71382838C95DA8557841A3CA58109F0B4F77A5E929B1A25DC2D6814C55DC0F81CD2F4E5DB95EE70C706FC02C4FCA358EA9A82D8043A47611195580F89458E3DAB5592DEFE06CDE1E516A6C61ED78C13977AE9660A9192CA75CD72967FD3AFAFA1F1A2FF6325A5064D847028F1E6B2329E8572F36E708A549DDA355FC74A32FDD8DBA65
02 03 ;integer (3 bytes long)
010001
If you then run all those bytes together and Base64 encode it, you get:
MIIBCgKCAQEA61BjmfXGEvWmegnBGSuS+rU9soUg2FnODva32D1AqhwdziwHINFa
D1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBSEVCgJjtHAGZIm5GL/KA86KDp/CwDFMSw
luowcXwDwoyinmeOY9eKyh6aY72xJh7noLBBq1N0bWi1e2i+83txOCg4yV2oVXhB
o8pYEJ8LT3el6Smxol3C1oFMVdwPgc0vTl25XucMcG/ALE/KNY6pqC2AQ6R2ERlV
gPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeulmCpGSynXNcpZ/06+vofGi/2MlpQZNhH
Ao8eayMp6FcvNucIpUndo1X8dKMv3Y26ZQIDAQAB
RSA labs then said add a header and trailer:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA61BjmfXGEvWmegnBGSuS+rU9soUg2FnODva32D1AqhwdziwHINFa
D1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBSEVCgJjtHAGZIm5GL/KA86KDp/CwDFMSw
luowcXwDwoyinmeOY9eKyh6aY72xJh7noLBBq1N0bWi1e2i+83txOCg4yV2oVXhB
o8pYEJ8LT3el6Smxol3C1oFMVdwPgc0vTl25XucMcG/ALE/KNY6pqC2AQ6R2ERlV
gPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeulmCpGSynXNcpZ/06+vofGi/2MlpQZNhH
Ao8eayMp6FcvNucIpUndo1X8dKMv3Y26ZQIDAQAB
-----END RSA PUBLIC KEY-----
Five hyphens, and the words BEGIN RSA PUBLIC KEY. That is your PEM DER ASN.1 PKCS#1 RSA Public key
After that, other forms of public key cryptography came along:
When it came time to create a standard for how to represent the parameters of those encryption algorithms, people adopted a lot of the same ideas that RSA originally defined:
BEGIN PUBLIC KEY
But rather than using:
-----BEGIN RSA PUBLIC KEY----------BEGIN DH PUBLIC KEY----------BEGIN EC PUBLIC KEY-----They decided instead to include the Object Identifier (OID) of what is to follow. In the case of an RSA public key, that is:
1.2.840.113549.1.1.1
So for RSA public key it was essentially:
public struct RSAPublicKey {
INTEGER modulus,
INTEGER publicExponent
}
Now they created SubjectPublicKeyInfo which is basically:
public struct SubjectPublicKeyInfo {
AlgorithmIdentifier algorithm,
RSAPublicKey subjectPublicKey
}
In actual DER ASN.1 definition is:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, -- 1.2.840.113549.1.1.1 rsaEncryption (PKCS#1 1)
parameters ANY DEFINED BY algorithm OPTIONAL },
subjectPublicKey BIT STRING {
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
}
That gives you an ASN.1 of:
SEQUENCE (2 elements)
SEQUENCE (2 elements)
OBJECT IDENTIFIER 1.2.840.113549.1.1.1
NULL
BIT STRING (1 element)
SEQUENCE (2 elements)
INTEGER (2048 bit): EB506399F5C612F5A67A09C1192B92FAB53DB28520D859CE0EF6B7D83D40AA1C1DCE2C0720D15A0F531595CAD81BA5D129F91CC6769719F1435872C4BCD0521150A0263B470066489B918BFCA03CE8A0E9FC2C0314C4B096EA30717C03C28CA29E678E63D78ACA1E9A63BDB1261EE7A0B041AB53746D68B57B68BEF37B71382838C95DA8557841A3CA58109F0B4F77A5E929B1A25DC2D6814C55DC0F81CD2F4E5DB95EE70C706FC02C4FCA358EA9A82D8043A47611195580F89458E3DAB5592DEFE06CDE1E516A6C61ED78C13977AE9660A9192CA75CD72967FD3AFAFA1F1A2FF6325A5064D847028F1E6B2329E8572F36E708A549DDA355FC74A32FDD8DBA65
INTEGER (24 bit): 010001
The final binary encoding in ASN.1 is:
30 82 01 22 ;SEQUENCE (0x122 bytes = 290 bytes)
| 30 0D ;SEQUENCE (0x0d bytes = 13 bytes)
| | 06 09 ;OBJECT IDENTIFIER (0x09 = 9 bytes)
| | 2A 86 48 86
| | F7 0D 01 01 01 ;hex encoding of 1.2.840.113549.1.1
| | 05 00 ;NULL (0 bytes)
| 03 82 01 0F 00 ;BIT STRING (0x10f = 271 bytes)
| | 30 82 01 0A ;SEQUENCE (0x10a = 266 bytes)
| | | 02 82 01 01 ;INTEGER (0x101 = 257 bytes)
| | | | 00 ;leading zero of INTEGER
| | | | EB 50 63 99 F5 C6 12 F5 A6 7A 09 C1 19 2B 92 FA
| | | | B5 3D B2 85 20 D8 59 CE 0E F6 B7 D8 3D 40 AA 1C
| | | | 1D CE 2C 07 20 D1 5A 0F 53 15 95 CA D8 1B A5 D1
| | | | 29 F9 1C C6 76 97 19 F1 43 58 72 C4 BC D0 52 11
| | | | 50 A0 26 3B 47 00 66 48 9B 91 8B FC A0 3C E8 A0
| | | | E9 FC 2C 03 14 C4 B0 96 EA 30 71 7C 03 C2 8C A2
| | | | 9E 67 8E 63 D7 8A CA 1E 9A 63 BD B1 26 1E E7 A0
| | | | B0 41 AB 53 74 6D 68 B5 7B 68 BE F3 7B 71 38 28
| | | | 38 C9 5D A8 55 78 41 A3 CA 58 10 9F 0B 4F 77 A5
| | | | E9 29 B1 A2 5D C2 D6 81 4C 55 DC 0F 81 CD 2F 4E
| | | | 5D B9 5E E7 0C 70 6F C0 2C 4F CA 35 8E A9 A8 2D
| | | | 80 43 A4 76 11 19 55 80 F8 94 58 E3 DA B5 59 2D
| | | | EF E0 6C DE 1E 51 6A 6C 61 ED 78 C1 39 77 AE 96
| | | | 60 A9 19 2C A7 5C D7 29 67 FD 3A FA FA 1F 1A 2F
| | | | F6 32 5A 50 64 D8 47 02 8F 1E 6B 23 29 E8 57 2F
| | | | 36 E7 08 A5 49 DD A3 55 FC 74 A3 2F DD 8D BA 65
| | | 02 03 ;INTEGER (03 = 3 bytes)
| | | | 010001
And as before, you take all those bytes, Base64 encode them, you end up with your second example:
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA61BjmfXGEvWmegnBGSuS
+rU9soUg2FnODva32D1AqhwdziwHINFaD1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBS
EVCgJjtHAGZIm5GL/KA86KDp/CwDFMSwluowcXwDwoyinmeOY9eKyh6aY72xJh7n
oLBBq1N0bWi1e2i+83txOCg4yV2oVXhBo8pYEJ8LT3el6Smxol3C1oFMVdwPgc0v
Tl25XucMcG/ALE/KNY6pqC2AQ6R2ERlVgPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeu
lmCpGSynXNcpZ/06+vofGi/2MlpQZNhHAo8eayMp6FcvNucIpUndo1X8dKMv3Y26
ZQIDAQAB
Add the slightly different header and trailer, and you get:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA61BjmfXGEvWmegnBGSuS
+rU9soUg2FnODva32D1AqhwdziwHINFaD1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBS
EVCgJjtHAGZIm5GL/KA86KDp/CwDFMSwluowcXwDwoyinmeOY9eKyh6aY72xJh7n
oLBBq1N0bWi1e2i+83txOCg4yV2oVXhBo8pYEJ8LT3el6Smxol3C1oFMVdwPgc0v
Tl25XucMcG/ALE/KNY6pqC2AQ6R2ERlVgPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeu
lmCpGSynXNcpZ/06+vofGi/2MlpQZNhHAo8eayMp6FcvNucIpUndo1X8dKMv3Y26
ZQIDAQAB
-----END PUBLIC KEY-----
And this is your X.509 SubjectPublicKeyInfo/OpenSSL PEM public key [2].
Now that you know that the encoding isn't magic, you can write all the pieces needed to parse out the RSA modulus and exponent. Or you can recognize that the first 24 bytes are just added new stuff on top of the original PKCS#1 standard
30 82 01 22 ;SEQUENCE (0x122 bytes = 290 bytes)
| 30 0D ;SEQUENCE (0x0d bytes = 13 bytes)
| | 06 09 ;OBJECT IDENTIFIER (0x09 = 9 bytes)
| | 2A 86 48 86
| | F7 0D 01 01 01 ;hex encoding of 1.2.840.113549.1.1
| | 05 00 ;NULL (0 bytes)
| 03 82 01 0F 00 ;BIT STRING (0x10f = 271 bytes)
| | ...
Those first 24-bytes are "new" stuff added:
30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00
And due to an extraordinary coincidence of fortune and good luck:
24 bytes happens to correspond exactly to 32 base64 encoded characters
Because in Base64: 3-bytes becomes four characters:
30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00
\______/ \______/ \______/ \______/ \______/ \______/ \______/ \______/
| | | | | | | |
MIIB IjAN Bgkq hkiG 9w0B AQEF AAOC AQ8A
That means if you take your second X.509 public key, the first 32 characters corresponds only to newly added stuff:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA61BjmfXGEvWmegnBGSuS+rU9soUg2FnODva32D1AqhwdziwHINFa
D1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBSEVCgJjtHAGZIm5GL/KA86KDp/CwDFMSw
luowcXwDwoyinmeOY9eKyh6aY72xJh7noLBBq1N0bWi1e2i+83txOCg4yV2oVXhB
o8pYEJ8LT3el6Smxol3C1oFMVdwPgc0vTl25XucMcG/ALE/KNY6pqC2AQ6R2ERlV
gPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeulmCpGSynXNcpZ/06+vofGi/2MlpQZNhH
Ao8eayMp6FcvNucIpUndo1X8dKMv3Y26ZQIDAQAB
-----END PUBLIC KEY-----
If you remove the first 32 characters, and change it to BEGIN RSA PUBLIC KEY:
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA61BjmfXGEvWmegnBGSuS+rU9soUg2FnODva32D1AqhwdziwHINFa
D1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBSEVCgJjtHAGZIm5GL/KA86KDp/CwDFMSw
luowcXwDwoyinmeOY9eKyh6aY72xJh7noLBBq1N0bWi1e2i+83txOCg4yV2oVXhB
o8pYEJ8LT3el6Smxol3C1oFMVdwPgc0vTl25XucMcG/ALE/KNY6pqC2AQ6R2ERlV
gPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeulmCpGSynXNcpZ/06+vofGi/2MlpQZNhH
Ao8eayMp6FcvNucIpUndo1X8dKMv3Y26ZQIDAQAB
-----END RSA PUBLIC KEY-----
You have exactly what you wanted - the older RSA PUBLIC KEY format.
I found this website to be a good technical explanation of the different formats: https://polarssl.org/kb/cryptography/asn1-key-structures-in-der-and-pem
"BEGIN RSA PUBLIC KEY" is PKCS#1, which can only contain RSA keys.
"BEGIN PUBLIC KEY" is PKCS#8, which can contain a variety of formats.
If you just want to convert them with the command-line, "openssl rsa" is good for this.
To convert from PKCS#8 to PKCS#1:
openssl rsa -pubin -in <filename> -RSAPublicKey_out
To convert from PKCS#1 to PKCS#8:
openssl rsa -RSAPublicKey_in -in <filename> -pubout
While the above comments regarding 32 byte headers, OID formats and such are interesting, I personally don't see the same behavior, assuming I'm getting the point. I thought it might be helpful to explore this further in what most might think is excessive detail. Nothing exceeds like excess.
To start, I created an RSA private key, and checked it:
>openssl rsa -in newclient_privatekey.pem -check
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4pOYWo+GeAEmU4N1HPZj1dxv70
4hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyozC/zSqcuU6iBrvzDTpyG1zhIG
76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknmLBrtZkLkBhchgYnMswIDAQAB
AoGAQaJ5aivspeEXcpahWavzAFLv27+Tz48usUV+stY6arRhqbBEkV19/N5t8EPA
01U6IGDQ8QIXEIW/rtsHKM6DAZhAbakPDJhJRatcMzJ08ryIkP/c3+onkTquiveG
brw7xzn6Xa8ls04aQ6VQR4jxXUjV5bB72pFZnGRoAmS2NiECQQDUoISbmTGjnHM+
kEfunNTXbNmKklwTYhyZaSVsSptnD7CvLWB4qB/g4h2/HjsELag6Z7SlWuYr7tba
H3nBYn35AkEAykFRudMqlBy3XmcGIpjxOD+7huyViPoUpy3ui/Bj3GbqsbEAt9cR
PyOJa1VFa2JqShta1Tdep8LJv1QvgvY7CwJBAML+al5gAXvwEGhB3RXg0fi2JFLG
opZMFbpDCUTkrtu3MeuVC7HbTVDpTSpmSO0uCed2D97NG+USZgsnbnuBHdECQQCw
S3FWPXdetQ0srzaMz61rLzphaDULuZhpBMNqnTYeNmMaUcPjewagd3Rf52rkKFun
juKE+Yd7SXGbYWEskT5zAkAD7tbNwe5ryD2CT71jrY/5uXMR2yg/A4Ry2ocZkQUp
iGflLrHnODvHO5LYLBlSKpjanBceYHJLuMFNZruf7uBM
-----END RSA PRIVATE KEY-----
(Oh, horrors! I've exposed a private key. Meh...)
I extract and display its public key:
>openssl rsa -in newclient_privatekey.pem -pubout
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4p
OYWo+GeAEmU4N1HPZj1dxv704hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyoz
C/zSqcuU6iBrvzDTpyG1zhIG76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknm
LBrtZkLkBhchgYnMswIDAQAB
-----END PUBLIC KEY-----
It so happens there's another public key output parameter (as is mentioned in an earlier comment). I extract and display the public key using that keyword instead:
>openssl rsa -in newclient_privatekey.pem -RSAPublicKey_out
writing RSA key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAKf86UWTu8tFDp0GI1CS+OeGbik5haj4Z4ASZTg3Uc9mPV3G/vTiGbzR
5hzuHXbFzuhVwMsF0cHIYAYGlB+mOB0/KjML/NKpy5TqIGu/MNOnIbXOEgbvoqty
N1tfo+UoA872v90JGZSKMWFWhSVjrLAaSeYsGu1mQuQGFyGBicyzAgMBAAE=
-----END RSA PUBLIC KEY-----
Well, well. These two public key values aren't the same, though they're derived from the same private key. Or are they the same? I cut and paste the two public key strings into their own files, and then do a modulus check on each:
>openssl rsa -in newclient_publickey.pem -pubin -modulus
Modulus=
A7FCE94593BBCB450E9D06235092F8E7
866E293985A8F867801265383751CF66
3D5DC6FEF4E219BCD1E61CEE1D76C5CE
E855C0CB05D1C1C8600606941FA6381D
3F2A330BFCD2A9CB94EA206BBF30D3A7
21B5CE1206EFA2AB72375B5FA3E52803
CEF6BFDD0919948A316156852563ACB0
1A49E62C1AED6642E40617218189CCB3
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4p
OYWo+GeAEmU4N1HPZj1dxv704hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyoz
C/zSqcuU6iBrvzDTpyG1zhIG76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknm
LBrtZkLkBhchgYnMswIDAQAB
-----END PUBLIC KEY-----
The 'pubin' tells rsa that this really is supposed to be a public key, and don't complain that it's not a private key.
Now we take the RSA public key, display the modulus, and transmogrify it into a plain old 'public key' (again, we have to tell it the input is a public key):
>openssl rsa -in newclient_rsapublickey.pem -RSAPublicKey_in -modulus
Modulus=
A7FCE94593BBCB450E9D06235092F8E7
866E293985A8F867801265383751CF66
3D5DC6FEF4E219BCD1E61CEE1D76C5CE
E855C0CB05D1C1C8600606941FA6381D
3F2A330BFCD2A9CB94EA206BBF30D3A7
21B5CE1206EFA2AB72375B5FA3E52803
CEF6BFDD0919948A316156852563ACB0
1A49E62C1AED6642E40617218189CCB3
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4p
OYWo+GeAEmU4N1HPZj1dxv704hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyoz
C/zSqcuU6iBrvzDTpyG1zhIG76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknm
LBrtZkLkBhchgYnMswIDAQAB
-----END PUBLIC KEY-----
Same modulus, and same 'public key' value displayed. To make things more interesting (for me, anyway), when we tack on the RSAPublicKey_out keyword we get:
>openssl rsa -in newclient_rsapublickey.pem -RSAPublicKey_in -modulus -RSAPublicKey_out
Modulus=
A7FCE94593BBCB450E9D06235092F8E7
866E293985A8F867801265383751CF66
3D5DC6FEF4E219BCD1E61CEE1D76C5CE
E855C0CB05D1C1C8600606941FA6381D
3F2A330BFCD2A9CB94EA206BBF30D3A7
21B5CE1206EFA2AB72375B5FA3E52803
CEF6BFDD0919948A316156852563ACB0
1A49E62C1AED6642E40617218189CCB3
writing RSA key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAKf86UWTu8tFDp0GI1CS+OeGbik5haj4Z4ASZTg3Uc9mPV3G/vTiGbzR
5hzuHXbFzuhVwMsF0cHIYAYGlB+mOB0/KjML/NKpy5TqIGu/MNOnIbXOEgbvoqty
N1tfo+UoA872v90JGZSKMWFWhSVjrLAaSeYsGu1mQuQGFyGBicyzAgMBAAE=
-----END RSA PUBLIC KEY-----
...and when we transmogrify the plain old 'public key' into an RSA public key:
>openssl rsa -in newclient_publickey.pem -pubin -RSAPublicKey_out
writing RSA key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAKf86UWTu8tFDp0GI1CS+OeGbik5haj4Z4ASZTg3Uc9mPV3G/vTiGbzR
5hzuHXbFzuhVwMsF0cHIYAYGlB+mOB0/KjML/NKpy5TqIGu/MNOnIbXOEgbvoqty
N1tfo+UoA872v90JGZSKMWFWhSVjrLAaSeYsGu1mQuQGFyGBicyzAgMBAAE=
-----END RSA PUBLIC KEY-----
...marching on relentlessly, and although we just did this a few commands ago, to make the point we flip things around so the transmogrification is from RSA to plain old 'public key':
>openssl rsa -in newclient_rsapublickey.pem -RSAPublicKey_in -pubout
writing RSA key
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4p
OYWo+GeAEmU4N1HPZj1dxv704hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyoz
C/zSqcuU6iBrvzDTpyG1zhIG76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknm
LBrtZkLkBhchgYnMswIDAQAB
-----END PUBLIC KEY-----
...which takes us right back where we started. What have we learned?
Summary: the keys internally are the same, they just look different. An earlier comment pointed out the RSA key format was defined in PKCS#1, and the plain old 'public key' format was defined in PKCS#8. However, editing one form doesn't turn it into the other. Hopefully I've now beaten this distinction to death.
In case there's still a spark of life left, though, let's flog this a bit more and reference the certificate that was originally generated with the RSA private key so long ago, examining its public key and modulus:
>openssl x509 -in newclient_cert.pem -pubkey -noout -modulus
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn/OlFk7vLRQ6dBiNQkvjnhm4p
OYWo+GeAEmU4N1HPZj1dxv704hm80eYc7h12xc7oVcDLBdHByGAGBpQfpjgdPyoz
C/zSqcuU6iBrvzDTpyG1zhIG76KrcjdbX6PlKAPO9r/dCRmUijFhVoUlY6ywGknm
LBrtZkLkBhchgYnMswIDAQAB
-----END PUBLIC KEY-----
Modulus=
A7FCE94593BBCB450E9D06235092F8E7
866E293985A8F867801265383751CF66
3D5DC6FEF4E219BCD1E61CEE1D76C5CE
E855C0CB05D1C1C8600606941FA6381D
3F2A330BFCD2A9CB94EA206BBF30D3A7
21B5CE1206EFA2AB72375B5FA3E52803
CEF6BFDD0919948A316156852563ACB0
1A49E62C1AED6642E40617218189CCB3
...and they all lived happily ever after: the certificate has the same modulus value as the RSA public key, RSA private key, and plain old 'public key'. The certificate contains the same plain old 'public key' value that we saw earlier, although it was signed with a file marked as an RSA private key. It's safe to say there's a consensus.
There's no 'RSAPublicKey_out' equivalent keyword in the X509 quadrant of the OpenSSL galaxy, so we can't try that, although the modulus value is described as the "RSA key modulus" which I suppose is as close as we'll get.
How this would all look with a DSA-signed certificate, I don't know.
I realize this doesn't answer the original question, but perhaps it provides some useful background. If not, my apologies. At the very least, things not to do and assumptions not to make.
No doubt one has noted the slightly irritating repetition of "writing RSA key", when it's not doing any such thing. I assume what's meant is that the rsa module recognizes the plain old public key as a true RSA key, and that's why it keeps harping on "RSA key" (plus it is the rsa module, after all). If I recall properly, the generic EVP_PKEY structure has a union for all the key types, with each key type having its own special set of values (the helpfully named g, w, q, and other consonants).
In conclusion, I note there was a complaint regarding programming & development; now, every OpenSSL command obviously has corresponding code, and if one wishes to explore all the wonders that is OpenSSL programming today, the command line would seem a reasonable place to start. In this particular case (as I'm using a recent cygwin at the moment) one might start by reviewing \openssl-1.0.2f\apps\rsa.c and (given one has a high tolerance for macros) \openssl-1.0.2f\crypto\pem\pem_all.c
Using phpseclib, a pure PHP RSA implementation...
<?php
include('Crypt/RSA.php');
$rsa = new Crypt_RSA();
$rsa->loadKey('-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA61BjmfXGEvWmegnBGSuS
+rU9soUg2FnODva32D1AqhwdziwHINFaD1MVlcrYG6XRKfkcxnaXGfFDWHLEvNBS
EVCgJjtHAGZIm5GL/KA86KDp/CwDFMSwluowcXwDwoyinmeOY9eKyh6aY72xJh7n
oLBBq1N0bWi1e2i+83txOCg4yV2oVXhBo8pYEJ8LT3el6Smxol3C1oFMVdwPgc0v
Tl25XucMcG/ALE/KNY6pqC2AQ6R2ERlVgPiUWOPatVkt7+Bs3h5Ramxh7XjBOXeu
lmCpGSynXNcpZ/06+vofGi/2MlpQZNhHAo8eayMp6FcvNucIpUndo1X8dKMv3Y26
ZQIDAQAB
-----END PUBLIC KEY-----');
$rsa->setPublicKey();
echo $rsa->getPublicKey(CRYPT_RSA_PUBLIC_FORMAT_PKCS1_RAW);
The base64-encoded stuff appears to match even though the header says BEGIN PUBLIC KEY and not BEGIN RSA PUBLIC KEY. So maybe just use str_replace to fix that and you should be good to go!
The only difference between your pub1 and pub2, besides the header/footer, is this additional string in pub2: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A. If you remove that, the Base 64 is identical to that in pub1.
The extra string corresponds to the algorithm identifier according to this Answer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With