[144289] in cryptography@c2.net mail archive
Re: SHA-3 Round 1: Buffer Overflows
daemon@ATHENA.MIT.EDU (james hughes)
Tue Feb 24 14:38:49 2009
Cc: james hughes <hughejp@mac.com>, Ian G <iang@systemics.com>,
Cryptography <cryptography@metzdowd.com>,
"R.A. Hettinga" <rah@shipwright.com>, cypherpunks@al-qaeda.net,
gold-silver-crypto@rayservers.com
From: james hughes <hughejp@mac.com>
To: Joachim@Strombergson.com
In-reply-to: <49A402B4.3040303@Strombergson.com>
Date: Tue, 24 Feb 2009 10:53:31 -0800
On Feb 24, 2009, at 6:22 AM, Joachim Str=F6mbergson 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 =20
> 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 =20
significant feat. C is a language where parallelization is possible, =20
but fraught with peril. We have to look past the buffer overflow to =20
the motivation of the complexity.
2) This algorithm -can- be implemented with a small footprint -if- =20
parallelization is not intended. If this algorithm could not be =20
minimized then this would be a significant issue, but this is not the =20=
case.
I would love this algorithm to be implemented in an implicitly =20
parallel language like Fortress.
http://projectfortress.sun.com/Projects/Community
Jim
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
