On Feb 24, 2009, at 6:22 AM, Joachim Strömbergson wrote:


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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to