TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Reverse Engineering the Verification QR Code on My Diploma

77 pointsby obrhubr11 months ago

11 comments

pxx11 months ago
this analysis does not seem particularly good and seems to be written for maximum hype value instead of correctness.<p>e.g.:<p>&gt; 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&#x2F;verifying.<p>but... you <i>are</i> doing a verification at this stage. this <i>is</i> how public-key encryption works. but since the data is so short, the &quot;signature&quot; is just the data itself instead of a (essentially) a hash of it.<p>the stuff about pkcs#1 1.5 likewise is irrelevant. there&#x27;s no way to get a padding oracle, and the Bleichenbacher &#x27;06 signature forgery scheme seems to be an attack on a bad signature verification algorithm and not an issue with the primitive. but we&#x27;re not using signature verification here.
评论 #40878660 未加载
mmastrac11 months ago
RSA can technically sign any arbitrary data like this -- it&#x27;s fine, but you run the risk that any arbitrary set of bytes might accidentally look valid. Unpadded encryption&#x2F;signing is the worst. PKCS padding is better because you at least need to decrypt to `0x00 || 0x01 || PS || 0x00 || &lt;message&gt;`, but the more flexible the data you&#x27;re signing, even if padded, the less secure it is.<p>It&#x27;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.<p>If you&#x27;re just signing arbitrary data, there is a real risk that someone can construct something that yields valid data.<p>Where you get killed is that technically, every 256 bytes decrypts to a message -- it&#x27;s the proportion of valid to invalid messages (and how usable an arbitrary valid message is) that really defines the security of the system.<p>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&#x27;s going to be a lot more expensive!
评论 #40878960 未加载
NovemberWhiskey11 months ago
What&#x27;s described here is called &quot;signature with (total) message recovery&quot; as opposed to the more common &quot;signature with appendix&quot;. 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.<p>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. <a href="https:&#x2F;&#x2F;eprint.iacr.org&#x2F;2018&#x2F;855.pdf" rel="nofollow">https:&#x2F;&#x2F;eprint.iacr.org&#x2F;2018&#x2F;855.pdf</a><p>EDIT: eh, PKCS #1 v1.5 is proven secure for a set of assumptions that I don&#x27;t think apply to this case.<p>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 &quot;only&quot; requires an initial 88 bit match, based on the required minimum padding length.<p>You won&#x27;t get a syntactically valid (per the apparent specification for the certificate) result, but it would be broken at the cryptographic level.<p>I mean, realistically, it&#x27;s probably fine but, yeah.
评论 #40879079 未加载
评论 #40880608 未加载
Dragon86311 months ago
This is great! I haven&#x27;t come across much in terms of reverse engineering flutter apps specifically, it&#x27;s good to see something like this can be done with relative ease. Nice work!
评论 #40878888 未加载
gwervc11 months ago
There&#x27;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&#x27;s yet not of the them is really finished or complete.
a-dub11 months ago
i think the fact that they put a digital signature of any kind on the paper transcript is pretty cool.<p>would be kinda neat if there were a combined standard where there were a deterministic scheme for ocr&#x27;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.
评论 #40879126 未加载
404mm11 months ago
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?
评论 #40879009 未加载
评论 #40878890 未加载
changexd11 months ago
It&#x27;s always fun to get rick rolled even though fully expecting it.
dogaar11 months ago
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&#x2F;her name. It can change, and so can the name of the birthplace, not to mention people having the same name.
m00011 months ago
It ain&#x27;t stupid if it works.
hamburglar11 months ago
&gt; base64 encrypting the data<p>Groan
评论 #40878732 未加载