HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
guidovranken
cryptofuzz
HISTORICAL RECORD2019–2021
guidovranken / cryptofuzz · Not publicly available

cryptofuzz

Discover this repository through its Hacker News conversations.

Explore on GitHubRead Hacker News discussions
3Distinct people
8Mentions
0Explicit recommenders
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month8 dated mentions

Observed mentions: 2019-05-25 07:14:29 UTC to 2021-07-25 20:53:49 UTC.

0122019-05-01 00:00:00 UTC to 2019-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMay 20192019-06-01 00:00:00 UTC to 2019-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-07-01 00:00:00 UTC to 2019-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-08-01 00:00:00 UTC to 2019-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-09-01 00:00:00 UTC to 2019-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-10-01 00:00:00 UTC to 2019-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-11-01 00:00:00 UTC to 2019-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-12-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2020-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-02-01 00:00:00 UTC to 2020-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-03-01 00:00:00 UTC to 2020-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-04-01 00:00:00 UTC to 2020-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-05-01 00:00:00 UTC to 2020-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-06-01 00:00:00 UTC to 2020-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 20202020-07-01 00:00:00 UTC to 2020-08-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-08-01 00:00:00 UTC to 2020-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-09-01 00:00:00 UTC to 2020-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-10-01 00:00:00 UTC to 2020-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-11-01 00:00:00 UTC to 2020-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-12-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2021-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-02-01 00:00:00 UTC to 2021-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-03-01 00:00:00 UTC to 2021-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-04-01 00:00:00 UTC to 2021-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-05-01 00:00:00 UTC to 2021-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-06-01 00:00:00 UTC to 2021-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-07-01 00:00:00 UTC to 2021-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJul 2021

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
May 20192019-05-01 00:00:00 UTC2019-06-01 00:00:00 UTC101
Jun 20192019-06-01 00:00:00 UTC2019-07-01 00:00:00 UTC000
Jul 20192019-07-01 00:00:00 UTC2019-08-01 00:00:00 UTC000
Aug 20192019-08-01 00:00:00 UTC2019-09-01 00:00:00 UTC000
Sep 20192019-09-01 00:00:00 UTC2019-10-01 00:00:00 UTC000
Oct 20192019-10-01 00:00:00 UTC2019-11-01 00:00:00 UTC101
Nov 20192019-11-01 00:00:00 UTC2019-12-01 00:00:00 UTC000
Dec 20192019-12-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
Jan 20202020-01-01 00:00:00 UTC2020-02-01 00:00:00 UTC000
Feb 20202020-02-01 00:00:00 UTC2020-03-01 00:00:00 UTC000
Mar 20202020-03-01 00:00:00 UTC2020-04-01 00:00:00 UTC000
Apr 20202020-04-01 00:00:00 UTC2020-05-01 00:00:00 UTC000
May 20202020-05-01 00:00:00 UTC2020-06-01 00:00:00 UTC000
Jun 20202020-06-01 00:00:00 UTC2020-07-01 00:00:00 UTC000
Jul 20202020-07-01 00:00:00 UTC2020-08-01 00:00:00 UTC202
Aug 20202020-08-01 00:00:00 UTC2020-09-01 00:00:00 UTC101
Sep 20202020-09-01 00:00:00 UTC2020-10-01 00:00:00 UTC000
Oct 20202020-10-01 00:00:00 UTC2020-11-01 00:00:00 UTC000
Nov 20202020-11-01 00:00:00 UTC2020-12-01 00:00:00 UTC000
Dec 20202020-12-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
Jan 20212021-01-01 00:00:00 UTC2021-02-01 00:00:00 UTC101
Feb 20212021-02-01 00:00:00 UTC2021-03-01 00:00:00 UTC000
Mar 20212021-03-01 00:00:00 UTC2021-04-01 00:00:00 UTC000
Apr 20212021-04-01 00:00:00 UTC2021-05-01 00:00:00 UTC000
May 20212021-05-01 00:00:00 UTC2021-06-01 00:00:00 UTC000
Jun 20212021-06-01 00:00:00 UTC2021-07-01 00:00:00 UTC000
Jul 20212021-07-01 00:00:00 UTC2021-08-01 00:00:00 UTC101

What Hacker News says

8 sources
guidovranken·Jul 25, 2021
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/g
Read the rest
uidovranken/cryptofuzz#bugs-found-by-cry...
In An Empirical Study of Vulnerabilities in Cryptographic Libraries
guidovranken·Jan 17, 2021
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
In Cyber Security; Beginner Roadmap
_urga·Dec 18, 2020
Here are some ways to learn deeply and be relevant: 1. Pick a data structure (such as a hash table or LSM-Tree) then read all the literature there is to read, every single paper that's great, following the best conferences year after year, and implement a 10x faster or more scalable version for the std lib of your favorite language. 2. Pick a fault model (such as storage faults, network faults, cryptography faults) then read all the literature there is to read, every single paper that's great, following the best conferences year after year, and write a fault injection or fuzzing harness to break some of the most respected storage/network/cryptography systems (for examples, see the work done by Remzi and Andrea Arpaci-Dusseau on storage faults, Kyle Kingsbury on Jepsen, and Guido Vranken on Cryptofuzz: https://github.com/guidovranken/crypt
Read the rest
ofuzz). 3. Pick a software field (such as web applications, mobile applications, native applications, file formats such as Office Open XML, or protocols such as SMTP, MIME, HTTP, QUIC) then read as many CVE reports and bug bounty reports as you can find, and then start participating in bug bounty programs within this field. Pick a target and give yourself a goal, e.g. DoS, RCE or read/write access, and do the work to make it happen. Chain as many steps as you can. Automate and enumerate. You'll find a way in if you keep at it. There's nothing like crafting an exploit to change the way you think about programming. As you gain experience in data structures, storage/networking/cryptography, and security, you'll find this translates well to most software engineering work. You'll gain a speed/safety/security way of thinking, you'll have fun being curious and learning along the way (and hopefully you'll earn a bounty or two and get some CVEs under your name).
In John Carmack: Career Advice
guidovranken·Aug 3, 2020
SEEKING WORK | Netherlands | REMOTE ONLY I find bugs and vulnerabilities in source code. This is my exclusive focus. - Strong focus on fuzzing - Integration into OSS-Fuzz or other fuzzing services for durable protection - Specialized in C/C++ but demonstrable experience in finding Java/JavaScript/Go/Objective-C bugs - Dozens of memory safety bugs in mature C/C++ code bases is not uncommon - Other types of bugs: denial-of-service, serialization asymmetry, spec non-conformity, path traversal, ... Proprietary code OK, NDA OK, background check OK, payment in crypto OK. Past work (small selection): https://freeradius.org/security/fuzzer-2017.html https://www.zdnet.com/article/openvpn-audit-misses-serious-r... https://thenextweb.com/hardfork/2018/06/05/hacker-eos-crypto... https://thehackernews.com/2020/03/openwrt-rce-vulnerability.... https://
Read the rest
github.com/guidovranken/cryptofuzz#bugs-found-by-cry... Contact: guido@guidovranken.com Website: https://guidovranken.com/
In Ask HN: Freelancer? Seeking freelancer? (August 2020)
DyslexicAtheist·Jul 17, 2020
> but not TLS, X509, ASN1 etc (yet) then this may interest you: https://blog.doyensec.com/2020/05/14/asn1fuzz.html ^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G etc and doesn't get enough love in other domains. It's a high learning curve but once you get beyond the "standardese" language in the docs it's opening doors to opportunities in so many industries. > BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC the openSSL codebase is notorious but I think it's also because it has been in existing for so long. if I look around today I see 2 camps: cryptographers and software engineers. letting sw-engineers do crypto is usually a bad idea but it's often worse when cryptographers start coding.
Read the rest
it's almost like a variation of the old joke of "the 2 most dangerous things in Tech are a sw-engineer with a soldering iron and a hw-engineer with a sw-patch" ... apart from complexity leading to bugs I'd also say there is another downside which is stronger in openssl: people end up using it wrongly which makes it a proverbial foot-gun for implenters. > [1] https://github.com/guidovranken/cryptofuzz very cool thanks!!
In What changed in OpenSSL after heartbleed
guidovranken·Jul 17, 2020
I've been doing differential fuzzing of many major cryptographic libraries. It currently tests symmetric crypto, some elliptic curve crypto, bignum arithmetic, message digests and MACs, KDFs, but not TLS, X509, ASN1 etc (yet). The list of bugs it has found so far can be viewed here [1]. The bug count per library can not be used as an absolute metric and not all bugs are security vulnerabilities (though many can be under specific circumstances). BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC: BoringSSL is smaller in terms of functionality (# of message digests, ciphers, ...) than LibreSSL, which is smaller than OpenSSL. OpenSSL sometimes commits new buggy code whereas BoringSSL does not, but OpenSSL has a higher commit
Read the rest
frequency than BoringSSL, and BoringSSL might be aiming for a production-safe master branch where OpenSSL might not. So it's not easy to derive a reliable metric from this, but with that said, you can't really go wrong with BoringSSL if it offers what you need. [1] https://github.com/guidovranken/cryptofuzz#bugs-found-by-cry...
In What changed in OpenSSL after heartbleed
guidovranken·Oct 24, 2019
I've posted this once before but it failed to get traction. I'm reposting this with the permission of HN admins. In a nutshell: This open-source project provides a framework for fuzzing cryptographic libraries. It can find both memory bugs and implementation errors. So far it has found about 35 bugs of varying severity in the stable releases of major cryptographic libraries. The fuzzers run continually on Google's OSS-Fuzz platform which helps detect bugs before they end up in stable releases. The article describes the technical details of the software. Here you can find a summary of the bugs it has found: https://github.com/guidovranken/cryptofuzz#hall-of-fame
In Show HN: Differential Fuzzing of Cryptographic Libraries
_urga·May 25, 2019
"Fix: Run code on all inputs" Another way to think like this is to approach testing using fuzzing, but in a way that is designed to have 100% coverage of invariants. Basic fuzzing generates random inputs looking for a crash, without asserting invariants along the way. Invariant fuzzing, on the other hand, is concerned not just with the inputs to a function but also the outputs. For example, if a function is expected to throw exceptions for bad inputs, then use invariant fuzzing to test that all exceptions are thrown for a variety of bad inputs. Writing an invariant fuzz test like this often takes less code than writing hundreds of unit tests, which have significantly less coverage. Another example, and this is how we found CVE 2019-1543 in OpenSSL [1]. For all the AEAD ciphers in OpenSSL that we wanted to support, we fuzzed [2] and round-
Read the rest
tripped various combinations of {key, iv, plaintext/ciphertext, aad, tag}, comparing against an independent interface, while also randomly corrupting bytes in {key, iv, ciphertext, aad, tag} to ensure that AEAD authenticity invariants were being kept by OpenSSL. We needed the "A"s in the AEADs so we tested them. Adding this AEAD authenticity invariant test to our fuzz test took 25 lines of code and found the CVE in literally a second. After the CVE was found, OpenSSL added a test vector. This was 8 lines of code, and tested authenticity only for a single test vector, without covering the entire range of IV lengths, which was the root of the issue that the CVE uncovered. All this effort, for little gain, when the whole spectrum could have been tested across a few thousand vectors in the same amount of code. If you are interested in this kind of thing, Guido Vranken is taking the same approach to the next level for multiple crypto libraries [3]. [1]: https://nvd.nist.gov/vuln/detail/CVE-2019-1543 [2]: https://github.com/ronomon/crypto-async#tests [3]: https://github.com/guidovranken/cryptofuzz
In Does open-source cryptographic software work correctly? [pdf]

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.