[144277] in cryptography@c2.net mail archive
Re: SHA-3 Round 1: Buffer Overflows
daemon@ATHENA.MIT.EDU (Ian G)
Mon Feb 23 16:24:43 2009
Date: Mon, 23 Feb 2009 21:44:31 +0100
From: Ian G <iang@systemics.com>
To: Cryptography <cryptography@metzdowd.com>
Cc: "R.A. Hettinga" <rah@shipwright.com>, cypherpunks@al-qaeda.net,
gold-silver-crypto@rayservers.com
In-Reply-To: <2DDB4C4E-31CE-47AF-B0AF-155086347F3A@shipwright.com>
On 22/2/09 23:09, R.A. Hettinga wrote:
> <http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1>
> This just emphasizes what we already knew about C, even the most
> careful, security conscious developer messes up memory management.
No controversy there.
> Some
> of you are saying, so what? These are reference implementations and this
> is only Round 1. There are a few problems with that thought.
> Reference implementations don't disappear, they serve as a starting
> point for future implementations or are used directly. A bug in the RSA
> reference implementation was responsible for vulnerabilities in OpenSSL
> and two seperate SSH implementations. They can also be used to design
> hardware implementations, using buffer sizes to decide how much silicon
> should be used.
It is certainly appreciated that work is put in to improve the
implementations during the competition (my group did something similar
for the Java parts of AES, so I know how much work it can be).
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?
iang
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
