0

The RSA_private_encrypt is deprecated in OpenSSL 3.x. It is not clear how to get the same functionality in 3.x without using the deprecated functions. And, before you ask, IEC_62351-9 Section 9.1.3.5.4 requires private key encryption and specifically forbids signing, "Therefore, RSA signatures MUST be encoded as a private key encryption in PKCS #1 format and not as a signature in PKCS #1 format (which includes the OID of the hash algorithm)".

So, is there any way to do this in openssl-3.0.5 without using deprecated functions??? Or did the openssl developers deprecate a function without leaving other means of accessing the same functionality?

1 Answer 1

1

Deprecated functionality or legacy versions are probably the only viable route for you if you need to use the same keypair for anything else, and want to avoid doing some extra work. If you're using a unique keypair here, then the minimal-extra-work version is to simply treat the private key as the public key and vice versa, and using the public key, encrypt the hash in PKCS#1 format. The verification side needs to decrypt the hash and then verify it directly, rather than using any built-in verify function. Presumably you already have code to do this, so it shouldn't be that much of a change.

If you do have to re-use that key pair for anything else, and don't want to use a deprecated function or pre-3.x version, then you'll have to fake to OpenSSL which key is the public vs. the private, and do the above operation again passing the actually-the-private-key as the public key that you're encrypting to. This may require modifying the binary blob representing the keys.

Another variant that requires some work on your part is to sign with the private key normally, then modify the signature blob to remove the hash algorithm and make the blob look like private key encryption instead. You'd need to be able to pick apart, modify, and re-pack the PKCS#1 format, but that should be possible.

Obviously, none of these options are a good idea. Which one is least bad will depend on factors such as how much you trust your (or hopefully, some library's) ability to modify the cryptographic data formats, how important it is to be on the latest version and not using a deprecated function, and so on.


RSA signing without including the hash function is unsafe, unless the signer can guarantee that the verifier will only use one known function (and even that is unsafe, because that means the only allowed hash function will probably some day be deprecated due to weaknesses). OpenSSL has historically been quite cavalier about including unsafe functionality, but frankly, removing this one doesn't seem like a problem to me. People get public-key cryptography wrong constantly, and the API pretending like this is a reasonable thing to ever do doesn't help with that.

The problem is that the IEC standard is, in a word, terrible (based on what you wrote here; it apparently costs hundreds just to read it??) and needs to be updated to use standard cryptographic operations and formats. (Do I dare ask what hash function it wants you to use?) I realize this isn't something you personally can fix but maybe you can yell atwrite a strongly worded letter to the standards committee about it.

3
  • The hash function has already been agreed to in prior messages within the exchange. It is not dictated by the standard. Because it has already been agreed between the two sides, the authors of the IEC specification decided to save a couple of bytes by not including the hash OID in the signature. I'll give it a whirl setting the private key as the public key and vice versa when I verify. Thank you.
    – tstone
    Aug 4, 2022 at 9:14
  • Thank you btw... Your answer is helpful. I will be submitting comments to the IEC regarding this issue.
    – tstone
    Aug 4, 2022 at 9:26
  • Also RFC-2409 section 5.1 contains the same language regarding encrypting versus signing.
    – tstone
    Aug 4, 2022 at 12:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .