crypto: sign/verify support for RSASSA-PSS

[wolfie82]

It would be good if the crypto.createSign / crypto.createVerify implementations supported different openssl padding schemes instead of the default PKCS1.5. Specifically, I'm interested in PSS and PSS with MGF1.

RSA_padding_add_PKCS1_PSS
RSA_padding_add_PKCS1_PSS_mgf1

I found the following forum post that may help in the development effort.

http://openssl.6102.n7.nabble.com/RSA-sign-and-verify-td44219.html

I'm a bit out of my depth with C++, however I'm willing to help implement if someone could point me in the right direction with crypto.cc.

Thanks

[wolfie82]

I did a bit more digging. It might be easier to update node_crypto.cc to use the later OpenSSL EVP API's.

EVP_Sign* & EVP_Verify* to EVP_DigestSign* & EVP_DigestVerify*

Then it should be a matter of calling EVP_PKEY_CTX_set_rsa_padding() with 'RSA_PKCS1_PSS_PADDING' & EVP_PKEY_CTX_set_rsa_pss_saltlen()

The only thing I'm a bit unsure of is MGF1.

[James-Firth]

+1 I would appreciate this feature, and it would help keep node compatible with more products in the future as adoption grows.

[Trott]

@nodejs/crypto Any thoughts on this? Specifically, is this a reasonable feature to include in core? And given as the issue is more than a year old, has anything changed that might make this issue obsolete? ("Oh, we already added support for that six months ago!")

[bnoordhuis]

No strong opinion. I think it could be retrofitted onto crypto.createSign() and crypto.createVerify().

PSS appears to be rare. Not a reason to reject it but it is arguably a reason to not spend too much effort on it. I'd be interested in hearing use cases.

It might be easier to update node_crypto.cc to use the later OpenSSL EVP API's.

Not strictly necessary. They're aliases for their EVP_Digest counterparts in OpenSSL 1.1.0.

[mwain]

Is there any movement on this? I have a requirement to use SHA256withRSA/PSS but its not supported in node crypto.

[bnoordhuis]

@mwain No movement whatsoever.

[mwain]

Would it be considered if i put something together?

[bnoordhuis]

If it's not too intrusive I don't see why not. I'm curious what your use case is though.

[mwain]

Ok, you mentioned it might be able to be retrofitted into crypto.createSign() / crypto.createVerify() but they have an extra param options which is passed to stream.Writable, which is not documented :/

So i was thinking of adding an extra function to each to set padding type and option padding length?

[bnoordhuis]

That sounds reasonable. Documenting and extending options is probably acceptable too.

[tniessen]

I'm curious what your use case is though.

@bnoordhuis Just one possible use case I recently stumbled upon: The WebCrypto API specifies two algorithms for RSA-based signatures, RSASSA-PSS and RSASSA-PKCS1-v1_5. I think it would be nice to provide interoperability with as many of the operations defined as part of the WebCrypto API as possible, including RSASSA-PSS.

It might be easier to update node_crypto.cc to use the later OpenSSL EVP API's.

Not strictly necessary. They're aliases for their EVP_Digest counterparts in OpenSSL 1.1.0.

Could you elaborate on this? EVP_VerifyInit_ex and EVP_VerifyUpdate are aliases for EVP_DigestInit_ex and EVP_DigestUpdate, but as far as I know, EVP_VerifyFinal has its own implementation in both OpenSSL 1.0.2 and 1.1.0 (crypto/evp/p_verify.c) which does not allow to specify padding parameters. (It creates a temporary EVP_PKEY_CTX which it does not expose to the caller, making it impossible to use EVP_PKEY_CTX_set_rsa_padding.) Correct me if I am wrong.

Then it should be a matter of calling EVP_PKEY_CTX_set_rsa_padding() with 'RSA_PKCS1_PSS_PADDING' & EVP_PKEY_CTX_set_rsa_pss_saltlen()

@patbaker82 The new API (EVP_Digest*, see crypto/evp/m_sigver.c) supports such parameters, but expects a public key during initialization (EVP_DigestVerifyInit) instead of finalization as the old API (EVP_VerifyFinal, now EVP_DigestVerifyFinal) did. Assuming that it is unacceptable to change the node.js crypto API accordingly, we would need to find a way to avoid specifying the key during initialization. Maybe it is possible to get the EVP_Digest* API to work with an existing message digest?

The only thing I'm a bit unsure of is MGF1.

I am by no means an expert when it comes to RSA, but isn't MGF1 the default MGF for RSASSA-PSS?

[bnoordhuis]

EVP_VerifyFinal has its own implementation in both OpenSSL 1.0.2 and 1.1.0 (crypto/evp/p_verify.c) which does not allow to specify padding parameters.

You're right, good point.

[tniessen]

@bnoordhuis Is it okay to add an optional options argument to Sign.sign and Verify.verify? I guess that wouldn't cause any incompatibilities. I think it does not really make sense to ask for those options before accepting the public/private key as OpenSSL doesn't allow to do so either.

[bnoordhuis]

@tniessen Yes, I think that would be alright.

[Abhishek2kr]

Is there any movement on this? I have a requirement to use SHA256withRSA/PSS but its not supported in node crypto.

Can you help me to use SHA256withRSA/PSS ? @mwain