this analysis does not seem particularly good and seems to be written for maximum hype value instead of correctness.
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.
Thanks for the feedback, appreciate it. I wanted this to more entertaining than informative, but I understand why this might mislead.
- 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.
Check out the RSA spec here: https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2. It's still verification, because all you need is a message and a signature. The message can be constructed from the data in the diploma, presumably. It's just, it's not disclosed to you how to construct the message (maybe it is online somewhere). So a verifier could construct the same message you decrypted, and then run the verification function.
RSA can technically sign any arbitrary data like this -- it's fine, but you run the risk that any arbitrary set of bytes might accidentally look valid. Unpadded encryption/signing is the worst. PKCS padding is better because you at least need to decrypt to `0x00 || 0x01 || PS || 0x00 || <message>`, but the more flexible the data you're signing, even if padded, the less secure it is.
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.
What's described here is called "signature with (total) message recovery" as opposed to the more common "signature with appendix". This is a legitimate technique used when the message payloads are small and can be worked on directly by the cryptographic signature operation rather than being hashed and the signed-hash being appended.
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.
This is great! I haven't come across much in terms of reverse engineering flutter apps specifically, it's good to see something like this can be done with relative ease. Nice work!
There's already a government website to check some diploma (like brevet, bac, etc.), this app and some universities have deployed a blockchain-based system to grant and verify degrees. I wish less public money were spent on N different technological solutions that overlaps with each other's yet not of the them is really finished or complete.
i think the fact that they put a digital signature of any kind on the paper transcript is pretty cool.
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.
Impressive work!
But seeing the references to France makes me think of the (unreasonably limiting) laws. I’m under the impression that decompiling 3rd party software and disclosing the internals is quite illegal, isn’t it?
The world’s most unfalsifiable digital certificate counts for nothing if the data in it isn’t authoritative. A person can’t be identified by his/her name. It can change, and so can the name of the birthplace, not to mention people having the same name.
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.