[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: SHA-3 Round 1: Buffer Overflows
From:       james hughes <hughejp () mac ! com>
Date:       2009-02-24 18:53:31
Message-ID: E3C6F468-3116-43C1-B29C-98F2FF05987A () mac ! com
[Download RAW message or body]


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@metzdowd.com

[prev in list] [next in list] [prev in thread] [next in thread]