SHA-3 Round 1: Buffer Overflows

[Ian G]

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