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

["Chris Eng" <ceng () Veracode com>]

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

Absolutely.  Nobody is going to rewrite the reference code based on the
algorithm spec unless they are trying to optimize or adapt it to a
specific processor or language.  Reference code sticks around.
Wondering aloud -- I'm curious how much of the code in popular libraries
such as OpenSSL are taken directly from reference implementations. 

This scenario is analogous to sample code released with an application
server or similar platform to demonstrate how to code up certain tasks.
The sample apps aren't intended to be deployed as-is, but anybody who's
done a code review knows that sample code is copied and pasted into real
apps with alarming frequency.

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

Or to put a finer point on it: as early as possible in the development
process.


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