Support for signing with RSA-FDH and PKCS#1 1.5 without ASN.1 prefix

[zwhfly]

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

[alex]

What is the motivation for this? Is there a modern protocol that makes use of it?

[zwhfly]

What is the motivation for this?

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:

• RSASSA-PKCS1-v1_5, which does not have provable security, unless using longer (>= half the RSA key length) hash, which is not doable in the current state of cryptography library (no suitable hash).
• RSASSA-PSS, which does have provable security, but this scheme is very complex thus hard to implement correctly, especially in an embedded environment.

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).

Is there a modern protocol that makes use of it?

I have on idea.
I believe this library is meant for use not only by upper level protocol implementers, but also in personal Alice-Bob-like scenarios. Right?

[alex]

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.