SHA-3 Round 1: Buffer Overflows

[james hughes]

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 majordomo at metzdowd.com