e.g.:
> The first issue is the absolute disregard for any of the standards related to RSA key usage. Encrypting with the private key and decrypting with the public key is usually only done in the context of signing/verifying.
but... you are doing a verification at this stage. this is how public-key encryption works. but since the data is so short, the "signature" is just the data itself instead of a (essentially) a hash of it.
the stuff about pkcs#1 1.5 likewise is irrelevant. there's no way to get a padding oracle, and the Bleichenbacher '06 signature forgery scheme seems to be an attack on a bad signature verification algorithm and not an issue with the primitive. but we're not using signature verification here.
- I agree that the section on pkcs#1 is at this point irrelevant, I left it in just to mention that fact. But I will probably take it out now :)
- Concerning the part of misusing RSA: My understanding is that you usually append the signature at the end, after a copy of the data which is not done here. I believe they are misusing it here because no library for RSA supports this use case, to decrypt using a public key you always have to provide the message and signature. This isn't possible here because the message is encrypted. So I think they are misusing RSA.
Nonetheless, please keep writing! It was an entertaining read for me.
Salutations du Luxembourg :-)
It's far more secure to sign a hash and prepend that to the data itself because that means you need to have a very specific number of padding bytes that match, and you need a way to generate data with arbitrary hashes. This is pretty difficult.
If you're just signing arbitrary data, there is a real risk that someone can construct something that yields valid data.
Where you get killed is that technically, every 256 bytes decrypts to a message -- it's the proportion of valid to invalid messages (and how usable an arbitrary valid message is) that really defines the security of the system.
In this case, you just need something that decrypts to a string having N pipes and a string of M digits. Based on some very basic napkin math, that should happen in under or around a billion trials. Inserting your name and an arbitrary degree -- that's going to be a lot more expensive!
Also thank you for the insight on RSA functionality, that makes a lot of sense! I didn't realise why hashing is used.
The issue with generating a valid string is, as detailed at the very end of the post, that you need at least a pipes before and b pipes after the digits which need to be between to pipes. That narrows the possibilities down quite a bit.
In this case, PKCS #1 v1.5 is used for an RSA signature. The choice of PKCS #1 v1.5 is perfectly adequate for the digital signature scenario and was proven secure in 2018 ref. https://eprint.iacr.org/2018/855.pdf
EDIT: eh, PKCS #1 v1.5 is proven secure for a set of assumptions that I don't think apply to this case.
I think the security strength of this signature with message recovery approach is limited by the extent to which the maximum message length exceeds the signature size. You can choose random signatures until you get one that verifies to a syntactically-valid PKCS #1 padded string, which "only" requires an initial 88 bit match, based on the required minimum padding length.
You won't get a syntactically valid (per the apparent specification for the certificate) result, but it would be broken at the cryptographic level.
I mean, realistically, it's probably fine but, yeah.
would be kinda neat if there were a combined standard where there were a deterministic scheme for ocr'ing the text (specifically its ordering) as well as an accompanying signature so that the signature actually signed the text that appears on the document.
https://www.forbes.com/sites/danielfisher/2012/12/14/the-pat...
Groan