Re: Compared to this...
Good try, but expecting amateurs to fix industrial strength cryptography code is a bit much. I understand the principles involved, but none of the maths.
The only maths needed to understand or fix Heartbleed is basic arithmetic. It's a read past the end of an array.
The hard part about Heartbleed was finding it - and even that shouldn't have been hard, if the commit had been reviewed in the first place, or if anyone was fuzzing new OpenSSL features as they were added.
Heartbleed happened because:
1) The code in question was written by a typical C programmer, i.e. one who prefers ad hoc, terse, poorly-structured code to the carefully considered and properly-designed sort. In that it matches the rest of the OpenSSL source base. I have much respect for Eric Young and Steve Henson, for their technical accomplishments and knowledge, but the fact is that their code is an ugly mess. As is most of the C I've seen (and I've been working with the language since the mid-80s).
2) The DTLS Heartbeat code wasn't properly reviewed when it was submitted. That may be partly because it was written by the author of the spec; it's probably mostly because the OpenSSL team was badly understaffed and undercompensated at the time. But this is what happens when you accept patches without thorough review.
3) Despite OpenSSL's widespread use, no one tested the feature thoroughly when it was added - at least no one interested in publishing the vulnerability. OpenSSL is widely used, but mostly because people need to tick off a "secure communications" checkbox. It's used grudgingly, not because it makes anyone's life easier. And so people don't want to test it. They just hope it works.
Once Heartbleed was announced, it was quite easy to identify the mistake, and fixing it was trivial.