Dailydave mailing list archives
Re: It jerked and it berked but the thing really worked!
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Tue, 24 Feb 2009 18:48:06 +0100
To conclude, this is not production code, and was not intended to be. What the fortify guys did is cute - a nice reminder of how easy it is to mess up in C- and has no relevance to what the NIST process is about.The point is that often code that's not intended to be production quality ends up being used in production environments, especially when we're talking about the implementation of a crypto algorithm.
Well, on one hand, buffer management glitches are tangential to the quality of evaluated algorithms, so it is a bit unfortunate that the flaws managed to attract more PR attention than the actual crypto design itself. On the other, there are too many real-world examples of sloppy reference implementations being reused in production code. Fortify mentions RSAREF bugs in OpenSSL; another example off the top of my head is RFC 4627 (which provides a "secure" JSON parser that, well, isn't all that secure, and ends up exposing some sites to attacks). So, bringing up the issues at this stage was a prudent decision; we can perhaps debate whether it would be more productive to reach out to authors / organizers directly, but looking at news feeds, it does not seem that Fortify tried to make much of a PR deal out of these findings? ... As for the choice of languages, the original topic that started the discussion - the algorithms boil down to bit shifting, and their straightforward implementations in assembly, C, C++, Java, Pascal, or BASIC would be very similar - and in C++, definitely not benefiting from any additional range or exception checking unless specifically designed to incorporate checks - something that could be done in C just as easily, just neglected in this case. Java would benefit from mandatory range checking in most cases, but only until the algorithm is backported 1:1 to C or C++. Naturally, in languages such as C++ or Java, the binary arithmetic behind the algorithm could be also expressed in a more convoluted (but maybe less error-prone) way, making use of the abstraction layers built into these languages. But then, they would be complex, clunky, and difficult to express in imperative languages that lack some of these layers. In fact, the "one notch above assembly" seems to be just the right approach for expressing performance-critical, low-level algorithms of this nature. They should not have trivial bugs in them, too, but that's a different topic (and the reason why they are submitted to expert scrutiny). /mz _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- It jerked and it berked but the thing really worked! Dave Aitel (Feb 23)
- Re: It jerked and it berked but the thing really worked! Halvar Flake (Feb 23)
- Re: It jerked and it berked but the thing really worked! Dave Aitel (Feb 23)
- Re: It jerked and it berked but the thing really worked! David Molnar (Feb 25)
- Re: It jerked and it berked but the thing really worked! romain (Feb 28)
- Re: It jerked and it berked but the thing really worked! Dave Aitel (Feb 23)
- Re: It jerked and it berked but the thing really worked! silky (Feb 23)
- Re: It jerked and it berked but the thing really worked! Tal Garfinkel (Feb 23)
- Re: It jerked and it berked but the thing really worked! Alexander Sotirov (Feb 24)
- Re: It jerked and it berked but the thing really worked! Chris Eng (Feb 24)
- Re: It jerked and it berked but the thing really worked! romain (Feb 24)
- Re: It jerked and it berked but the thing really worked! Michal Zalewski (Feb 24)
- Re: It jerked and it berked but the thing really worked! Tal Garfinkel (Feb 24)
- Re: It jerked and it berked but the thing really worked! Halvar Flake (Feb 23)
- Re: It jerked and it berked but the thing really worked! Adam Shostack (Feb 24)