Allow RSA signing with raw data (without a DigestInfo)

[jahkosha]

This fixes #3713 and #10226.

Instead of using the script written by @misterzed88 in #10226 to generate modified tests vectors, I did directly implement the same logic in the test infrastructure, so we can reuse directly the NIST (or others...) vectors stored in the tests.

[alex]

I haven't reviewed in depth -- but I don't think we should use None to signify this, I think we should have a dedicated sentinel, Raw<Something> perhaps. None looks like a reasonable default, but this is the opposite of that :-)

@reaperhulk wdyt?

[jahkosha]

@alex yeah that is a fair concern 👍 in some early attempt I did add a NoHash hashes instead of using None, but I was afraid that would cause even more confusion so eventually I went with None.

I'll be happy to apply what you folks think is the best, if possible, please provide pointers where in the code-base a similar pattern is used so I can take inspiration from it.

[misterzed88]

I haven't reviewed in depth -- but I don't think we should use None to signify this, I think we should have a dedicated sentinel, Raw<Something> perhaps. None looks like a reasonable default, but this is the opposite of that :-)

@reaperhulk wdyt?

I would like to highlight that the API already uses None for this purpose (for the RSA signature recover functionality, ref. issue #5495). So whatever you decide, you may want to use the same method in all the API functions to make them symmetric.

[reaperhulk]

Hmm, the inconsistency is a bit unfortunate. I'd be inclined to do a RawNoDigestInfo (or perhaps just NoDigestInfo?) sentinel here and then also add that as an option on the signature recovery method while retaining None for backwards compatibility. So this signature would look like sign(value, PKCS1v15(), RawNoDigestInfo()) or sign(value, PKCS1v15(), NoDigestInfo()).

[jahkosha]

@alex @reaperhulk I did add a sentinel NoDigestInfo and support it also on recover_data_from_signature

Please have an other look and let me know what you think

[reaperhulk]

We also need docs for this new value in RSAPrivateKey.sign

[reaperhulk]

We need to document this in the same section as Prehashed

[reaperhulk]

I'd prefer we used SHA256 for the tests here because otherwise we'll increasingly have coverage challenges as more and more things disable SHA1.

[reaperhulk]

We need to document that recover_data_from_signature now takes this new argument.

[reaperhulk]

Same SHA1 concern