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

[Tal Garfinkel <talg () stanford edu>]

> 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. Let's say that in a few years I'm
> given the task of migrating a system to use SHA-3. I'm not a crypto expert,
> so I would take the reference implementation and use it with as few
> modifications as possible to avoid weakening the crypto by changing something
> important.
>
> If Fortify hadn't looked at the code, what are the chances that a buffer
> overflow would have found its way into a number of other software projects?
> Even if the bug was fixed later, what are the chances of somebody finding
> the old reference code with Google and using it?
>
> At what point in the NIST process (or any other development process) do we
> start caring about secure coding practices? I believe the right answer is:
> before any code is released.

Submissions are not reference implementations intended for production
use. Again, what is important
for this purpose is that they be fast and correct. The NIST process is
not a software development
process, it is an algorithm selection process.

I think the point you are raising is different from the one I was
making, and equally valid. That often
people grab code and use it for purposes it was not originally
intended -- a problem not unique
to this context.

There are multiple solutions one could suggest to this.

One is to discourage people from releasing crypto code that is not
production quality in forums where
 there may be ambiguity about its intended use. I see the merits in
this approach. That said, its also
 important to be clear that this point is something of an aside from
the task at hand.

Another approach is to encourage (or require) that in places like the
NIST process where there
is even the possibility of confusion that all submissions that are not
yet production quality
have a disclaimer attached in their comments, require a
-DNOT_FOR_PRODUCTION_USE
flag to compile, etc. This approach has its own benefits and drawbacks as well.

Cheers,
Tal
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave