Pad computation results to the required length.

[gabi-250]

I noticed pk.finalize() occasionally (and for no apparent reason) returns an UnsupportedParameters error, instead of the Ok result I would expect.

I don't have a minimal reproducible example I can share yet, but here are the steps I took to reproduce the issue:

• use pk.blind() to create a blinded message for a recipient whose public key is pk
• get the recipient to produce a blinded signature and use it to create a BlindedSignature
• call pk.finalize(...) <--- this will occasionally fail the verification:
  • first the message is unblinded to produce the signature of the original message: https://github.com/jedisct1/rust-blind-rsa-signatures/blob/622b6a5949544a35c9d5913ddb599a7fe6de5cfa/src/lib.rs#L342-L344
  • the signature then fails the verification because sig.len() != modulus_bytes (in my case, sig.len() = 511 and modulus_bytes = 512): https://github.com/jedisct1/rust-blind-rsa-signatures/blob/622b6a5949544a35c9d5913ddb599a7fe6de5cfa/src/lib.rs#L357-L359

This is what I think happens:

• these initial checks pass, so I know blind_sig.len() == modulus_bytes
• according to the RFC, the resulting unblinded signature should have [the same length] as the blinded signature
• somehow this other length check fails, despite the fact that blind_sig.len() == modulus_bytes at the beginning of finalize()!
• the problem seems to be this: converting a vector of bytes to and fromBigUint, with some transformations in between (i.e. unblind), doesn't guarantee the output vector has the same length as the input one, because BigUint will strip away any leading zeroes from the representation of the number: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=80d02761702f676119fedbb9a5ddd845

This patch fixes the problem for me (the solution seems to be to pad any vectors obtained using to_bytes_be to have a length of modulus_bytes).

[jedisct1]

Good catch.

The Zig implementation doesn't have this issue since it defines a bn2binPadded() function for this.

Instead of adding zero_left_pad() calls, maybe it would be less error-prone to do something similar, and define a to_bytes_be_padded() function instead. That can be implemented as a trait.

[gabi-250]

@jedisct1 Thank you for the review!

I addressed your comment in a separate commit, but I'm happy to squash it before merging.

[jedisct1]

Looking good!

Thank you so much for this, Gabi!