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.

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!

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?

It's always fun to get rick rolled even though fully expecting 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.

It ain't stupid if it works.

> base64 encrypting the data

Groan