-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for signing with RSA-FDH and PKCS#1 1.5 without ASN.1 prefix #11386
Comments
What is the motivation for this? Is there a modern protocol that makes use of it? |
The idea initially comes from my personal project involving message signing and verifying between a server and an embedded device. The server runs Python. The embedded device runs C on bare metal and I have to implement the signing scheme (whatever used) there by hand. It does have RSA acceleration support in the chip (in the raw no-padding form). If sticking to the PKCS#1 signing scheme, I have two choices:
While with the proposed RSA-FDH or PKCS#1 1.5 without ASN.1 prefix scheme, plus a sufficiently long hash (e.g. XOF), it's more secure (compared to RSASSA-PKCS1-v1_5), and easier to implement right (meaning less bugs then again more secure).
I have on idea. |
The goal of this library is to support building secure applications using cryptography. To do that, we, of course, provide security algorithms. But equally as important, we don't provide algorithms that are prone to misuse or provide limited benefits. Therefore a question we ask, particularly when dealing with more exotic algorithms is: Is this an algorithm someone might need to use (because it's part of an existing protocol), or one they're merely choosing to use. |
RSA Full Domain Hash is secure and can be used in combination with XOFs such as SHAKE.
PKCS#1 1.5 without ASN.1 prefix, aka LTC_PKCS_1_V1_5_NA1, is a padding scheme that only prepends
00 01 FF FF ... FF 00
to the hash digest, no AlgorithmIdentifier etc. This gives the possibility to use hash algorithms that don't have an OID (such as blake2x). Users can make the hash algo fixed in code or prepend their own domain separators.As far as I know, there is proof for the security of PKCS#1 1.5 signing scheme, only if the hash is long enough.[1] If people want to use longer hash with RSA, it's not even possible with the current state of this library. Maybe just implement #2735 and let people have the possibility.
[1] On the Security of the PKCS#1 v1.5 Signature Scheme
The text was updated successfully, but these errors were encountered: