writeups VS cryptofuzz

See: https://github.com/p4-team/ctf/tree/master/2016-03-12-0ctf/peoples_square and also https://github.com/TFNS/writeups/tree/master/2020-06-05-DefenitCTF/spn (this one is not AES but some toy SPN, but the idea is exactly the same and maybe easier to understand)

Not exactly purely in Python because with sage and also the goal was breaking SIDH, but: https://github.com/TFNS/writeups/tree/master/2020-04-17-PlaidCTF/sidhe

I'm not even mentioning big stuff like https://research.nccgroup.com/2021/11/08/technical-advisory-arbitrary-signature-forgery-in-stark-bank-ecdsa-libraries/ which interestingly enough is actually a vulnerability very similar to what exists in Java since the dawn of time -> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DSA.java#L358 (see: https://github.com/TFNS/writeups/tree/master/2020-10-03-TastelessCTF/petition )

The same issue exists in Java JDK for quite a while (see: https://github.com/TFNS/writeups/tree/master/2020-10-03-TastelessCTF/petition ) ;) I suspect there are many more libraries with similar problem.

Seems like the same problem as exists in Java JDK in DSA -> https://github.com/TFNS/writeups/tree/master/2020-10-03-TastelessCTF/petition

Check my writeup https://github.com/TFNS/writeups/tree/master/2021-10-23-ASIS-quals/madras if you need to understand where this come from.

See an example: https://github.com/TFNS/writeups/tree/master/2021-03-13-UTCTF/sleeves

There is also the cryptofuzz

2) There's a popular fuzzing technique, called "differential fuzzing" that works especially well for cryptographic libraries. The idea is to have the fuzzer look for both memory safety issues (like buffer overflows, even if they're too small to cause a crash AddressSaniziter can detect) and actual logic bugs in the cryptography implementation (e.g. the output of one implementation not matching the output of another, given the same state/inputs).

I understand that they base their research on CVE data because it offers normalized quantifiers of severity and scope, but in my experience vendors by and large don't bother with CVE's for API bugs even when the affected primitive is clearly malfunctioning (memory or correctness issues).

I've been deeply fuzzing cryptographic libraries for a few years and found about 130 bugs [1]. The vast majority of these did not receive a CVE. Now some of these are merely theoretical, others will only manifest under particular circumstances like specific calling sequences, others were caught in the development phase before landing in stable releases, but a number of them are outright vulnerabilities. The usefulness of CVE incidence is questionable when it is so strongly influenced by the vendor's propensity for reporting these.

[1] https://github.com/guidovranken/cryptofuzz#bugs-found-by-cry...

[1]: https://guidovranken.com/2019/05/14/differential-fuzzing-of-...

I don't have any certs (apart from malformed X509 files..) so I can't speak of their effectiveness. What has worked for me is having a strong presence in open source. I just show people one of my projects like [1] and nobody asks about certs or education, ever. I spend most of my free time on these projects so cultivating a sizeable project might not be a suitable route for anyone who has a life outside of computers, though having some kind of publicly available utility where a prospective employer can check out your coding style and skills is probably a decent way to stand out amidst a sea of applicants.

[1] https://github.com/guidovranken/cryptofuzz