Dailydave mailing list archives
Re: It jerked and it berked but the thing really worked!
From: Tal Garfinkel <talg () stanford edu>
Date: Tue, 24 Feb 2009 09:57:35 -0800
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
Current thread:
- Re: It jerked and it berked but the thing really worked!, (continued)
- 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)