Re: It jerked and it berked but the thing really worked!

[Michal Zalewski <lcamtuf () coredump cx>]

> > 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