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, more or less. There isn't much point in making the 41 secure;
better off to save the energy until "the one" is found. Then
concentrate the energy, no?
I would like to humbly disagree. In case of MD6 the fix meant that a
bugger had to be doubled in size (according to the Fortify blog). This
means that the memory footprint and thus its applicability for
embedded
platforms was (somewhat) effected.
That is, secure implementations might have different requirements than
what mighty have been stated, and we want to select an algorithm based
on the requirements for a secure implementation, right?
Two aspects of this conversation.
1) This algorithm is designed to be parallelized. This is a
significant feat. C is a language where parallelization is possible,
but fraught with peril. We have to look past the buffer overflow to
the motivation of the complexity.
2) This algorithm -can- be implemented with a small footprint -if-
parallelization is not intended. If this algorithm could not be
minimized then this would be a significant issue, but this is not the
case.
I would love this algorithm to be implemented in an implicitly
parallel language like Fortress.
http://projectfortress.sun.com/Projects/Community
Jim
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
