Aloha!
Ian G wrote:
However I think it is not really efficient at this stage to insist on
secure programming for submission implementations. For the simple
reason that there are 42 submissions, and 41 of those will be thrown
away, more or less. There isn't much point in making the 41
On Feb 24, 2009, at 6:22 AM, Joachim Strömbergson wrote:
Aloha!
Ian G wrote:
However I think it is not really efficient at this stage to insist on
secure programming for submission implementations. For the simple
reason that there are 42 submissions, and 41 of those will be thrown
away,
http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1
Off by On
A Software Security Blog
Search:
Friday, 20 February 2009
SHA-3 Round 1: Buffer Overflows
« Gartner Magic Quadrant for Static Analysis | Main
NIST is currently holding a competition to choose a design for the
SHA-3
On 22/2/09 23:09, R.A. Hettinga wrote:
http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1
This just emphasizes what we already knew about C, even the most
careful, security conscious developer messes up memory management.
No controversy there.
Some
of you are saying, so what?
This just emphasizes what we already knew about C, even the most
careful, security conscious developer messes up memory management.
However I think it is not really efficient at this stage to insist on secure
programming for submission implementations. For the simple reason that
there are
