[openssl-users] RSA Public Key error

Mon Dec 17 10:41:20 UTC 2018

Bonjour,

Without knowing what functions you’re calling when you try to encrypt data using the key Key3_wo16, I can only guess. And I’m guessing that you’re calling a function that expects to find a public key encoded in a SubjectPublicKeyInfo structure, and since this Key3_wo16 object is not such a structure, the function fails.

What you can do is :

  *   Take your public keys (for example Key2_w16)
  *   Check that the first 16 bytes are what you expect to have
  *   Pass the remainder of the file to the d2i_RSAPublicKey() function
  *   Use the resulting RSA public key the way you want

Cordialement,
Erwann Abalea

De : prithiraj das <prithiraj.das at gmail.com>
Date : lundi 17 décembre 2018 à 08:23
À : Erwann Abalea <Erwann.Abalea at docusign.com>, "openssl-users at openssl.org" <openssl-users at openssl.org>
Objet : Re: [openssl-users] RSA Public Key error

Hi Erwann/All,

Thank you for your earlier response. I have done a couple of tests on the originally generated 2048-bit RSA public key (let's say Key1_org) and the key file containing 16 byte custom information after removing 24 bytes from the originally generated key file and prepending those 16 bytes (let's say Key2_w16). For my experiment(s), I also removed those 16 bytes from the key Key2_w16 (which contains custom information) and the rest of the bytes were written into a file. Lets name this keyfile Key3_wo16. I believe the presence of custom 16 byte information resulted in asn1parse encoding/decoding errors as mentioned in the previous mail..

So now, Key3_wo16  =  Key2_w16 - the first 16 bytes  =   Key1_org - the first 24 bytes. And  I performed asn1parse on Key3_wo16. The output of asn1parse on this key is shown in the image file asn1parse of 24 byte removed.jpg which is attached in the mail. And I also performed 2 asn1parse strparse opertions on the originally generated public key Key1_org with strparse offsets 19 and 24. I have attached screenshots of the same with names asn1parse strparse 19.jpg and asn1parse strparse 24.jpg respectively. The outputs in all cases are the same. In the screenshots, the (removed/blurred) respective INTEGER values in all screenshots are the same.

What I want to know is why is OpenSSL throwing an error when try to encrypt data using the key Key3_wo16? The same command used for encryption works when the key Key1_org is used. I believe the INTEGER values contain the modulus and exponent information and so, I was expecting the encryption to be successful but OpenSSL fails to accept this key.

Can anyone please tell me what is going wrong here? Apart from the solution suggested by Erwann , can anyone please suggest an alternative solution as we need to work with the Key2_w16 ( the key containing the custom 16 byte information after removing the originally present first 24 bytes)? That is the only keyfile received by us.

Thanks and Regards,
Prithiraj

On Wed, 12 Dec 2018 at 12:32, Erwann Abalea via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> wrote:
Bonjour,

Assuming the first 24 bytes you’re talking about are the very beginning of the SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), that means you’ve replaced up to the first byte of the BITSTRING containing the public key (this byte indicates the number of unused bits) for a 2048bits RSA key with 16 custom bytes.
That’s perfectly normal for OpenSSL to refuse to load that beast, and for asn1parse to return errors (the first bytes do not represent a correct DER encoding of anything).
Think of it as « I took a Jpeg file, replaced some bytes at the beginning by my own, and now I can’t open the file again ». Those bytes are there for a reason.

A quick solution would be to *add* your 16 bytes before the public key, and remove them when passing the rest of the bytes to OpenSSL.

Cordialement,
Erwann Abalea

De : openssl-users <openssl-users-bounces at openssl.org<mailto:openssl-users-bounces at openssl.org>> au nom de prithiraj das <prithiraj.das at gmail.com<mailto:prithiraj.das at gmail.com>>
Répondre à : "openssl-users at openssl.org<mailto:openssl-users at openssl.org>" <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Date : mercredi 12 décembre 2018 à 08:08
À : "openssl-users at openssl.org<mailto:openssl-users at openssl.org>" <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Objet : [openssl-users] RSA Public Key error

Hi,

I have a RSA public key(PKCS 1v1.5) that I have obtained from somewhere. That key has been obtained after removing the first 24 bytes from the originally generated RSA public key. Those 24 bytes are being replaced by some custom 16 byte information which is being used as some sort of identifier in some future task and those 16 bytes are playing no role in encryption. OpenSSL fails to read this key. asn1parse shows some parsing error and most importantly RSA encryption in OpenSSL using this key fails. The untampered version of the RSA public key generated from the same source and containing the original 24 bytes at the beginning of the key is successfully read by OpenSSL and the RSA encryption using that key is also successful in OpenSSL. But our requirement is to use the first key containing the custom 16 byte information.

My understanding is that the first 24 bytes of RSA public key following PKCS standards doesn't contain the modulus and exponent details required for RSA encryption.  But OpenSSL seems to require these 24 bytes for encryption. Can someone please confirm what kind of information is present in the first 24 bytes of RSA Public key and/or why does OpenSSL need it? If possible, please suggest a solution to work with that RSA public key containing custom 16 byte information at the beginning of the key.

Thanks and Regards,
Prithiraj
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181217/d0b19786/attachment-0001.html>