On 23/2/09 23:41, Jerry Leichter wrote:
On Feb 23, 2009, at 3:44 PM, 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 disagree here. If there's a reason to submit running implementations
at all - and one can certainly argue that there isn't, at least in early
phases where we are nominally looking at the algorithms, not particular
bindings to code - then those implementations should be of reasonable
quality.
How can that be? If you don't know the reason to provide the C, how can
you argue that it has to be of a "reasonable quality" ? What's the
security / business / purpose / anything model here?
In this day and age, most of these errors - buffer overflows,
null dereferences, out-of-bound reads - simply cannot be part of code of
reasonable quality. I can live with memory leaks - at least they don't
affect correctness, and in non-parallel algorithms (which these
presumably are) they can generally be found and fixed later. But the
others represent some fundamental problems with the translation of the
algorithm pseudo-code into actual C code. So we have two presentations
of the "algorithm", one in pseudo-code, one in C - which are different.
Which is "right"? Again, if only the pseudo-code has to be "right",
Well, this is all good and fine if there is a purpose to this code that
needs the above. But this is a *competition for an algorithm.* So far,
quality of code is not anything more than a distraction; if I recall
the last time, the first AES contender was broken out before the end of
its presentation at the first conference!
why
is the C there at all?
OK, I admit here, I do not know why there is C at all. Thinking back to
my Java/AES experiences, I don't recall why there was code, either. I
can only hypothesise that it increased exposure, and gave a little bit
more experience, also a sense of "proving it is at least minimally
practical."
(Luckily, Java makes writing "reasonable quality" code easy, so I didn't
have to answer it. I recall that Rijndael team was very lucky to have
good solid C help though.)
The fact of the matter is that code, once it's
public, takes on a life of its own. People will go look at the reference
implementations for guidance - and in some cases they will find these
initial reference implementations. Further, if the AES competition is
any guide, some of the algorithms proposed but no selected will survive
and see use for multiple reasons, most probably bad, some perhaps
reasonable. The initial reference implementations, in that case, may be
all that ever gets published.
This is their lookout. Frankly, this is taking code and placing it on a
pedestal. If these "people" go download stuff from the net and build it
into security implementations, well, they need to do a little "risk
management" about what stuff found on the net is all about.
It's also been pointed out that performance of actual implementations
will form part of the selection criteria. I can always make my code
faster if I don't have to make it right! Based on this data, we can't
use the current crop of C code for *any* comparisons - not even to
estimate the sizes of temporary data needed for an implementation (since
the cause of one of the memory reference errors is a buffer half the
size it needs to be).
OK, here I can comment: I would predict most of the performance
discussions are likely to be based on hardware issues. They will be
talking about gate counts and so forth, and if they get "soft" they'll
be talking about instruction cycles and register sizes. The C code
won't really help there, and the Java will likely be totally ignored.
(YMMV, of course.)
Putting examples of incorrect code out there for people to look at is
never a good idea! We have way too much of it already.
Then a little more won't hurt :) Let them have their fun; once we get
to the last round (5 algorithms?) then make it better.
iang
Ian G