

Buffer Overflows in a few of the prospective SHA-3 algorithms (including MD6). - tsally
http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1

======
jjguy
I don't understand why this keeps getting passed around.

Buffer overflows in the hash reference implementations have zero relevance on
the algorithm's hashing effectiveness. Fortify posted the results of their
static analysis tool to the web as an academic exercise and PR stunt.

That it continues to propagate the web is merely amplifying the FUD.

~~~
jrockway
The article does not use the buffer overflows to conclude anything about the
algorithm -- it concludes that writing software that manages memory correctly
is very difficult. This is why you should all stop using C, and people should
stop telling other people to use C.

(Anything I would use C for, I now use Haskell for. Everything runs as fast,
and the language and libraries are much better.)

~~~
tptacek
That's nice. Almost nobody _is_ using C anymore --- especially for the web
apps we talk about here. But everyone drops to native code for
encoding/decoding; in Python, Perl, or Ruby, you're calling OpenSSL to get
your crypto primitives, an OpenSSL is gnarly C code.

~~~
neilc
No one is using C anymore, except for trivial things like kernels, database
systems, and VMs.

~~~
tptacek
RDBMS's seem like the next likely C stronghold to fall; they're I/O bound and
feature-laden.

~~~
timf
Isn't there a lot of pointer arithmetic in RDBMS land?

~~~
jrockway
Well, it's written in C. That's what everything written in C does.

~~~
timf
My point was that database performance goes far beyond "waiting for the disk."
The data is laid out in specific ways with specific widths, there are decades
of implementation experience behind making queries and inserts fast because of
this.

Among many other things, controlling which part of the disk based data to mmap
in. These are things that a higher level language's runtime can't just
optimize for you.

~~~
tptacek
What part of laying things out in specific widths prohibits an implementation
in a high level language?

From 2001-2005, at Arbor Networks, I worked on a codebase that basically had
to bucket the entire Internet, as seen from (say) the core routers at British
Telecom, on varying timescales. Obviously, we wrote it in C. It was not
optimal. What's worse, changing it was a huge nightmare. Most of the
performance improvements we came up with (at least in my first year) were
design issues (like messing with precision, storing runs of zeroes, things
like that). Most of the bugs we has were textbook C issues, like failing to
address shared memory properly.

I'm totally not sold that high speed disk I/O demands C.

~~~
timf
" _What part of laying things out in specific widths prohibits an
implementation in a high level language?_ "

Nothing, mechanically. I was more referring to the efficiency of doing it (OK,
one thing I'm learning on HN is that I can't just think of it as a casual
chatroom, need to flesh comments out more). And note the original question was
an actual _question_ and also I'm sympathetic to what you're saying.

I was taught that with raw pointers and memory control, the database
implementation would chunk all the right stuff efficiently in and out from the
disk and it could get directly to any row/column naturally with pointer
arithmetic. I thought DBs even managed the disk directly and had their own
buffer cache like in the kernel.

 _This part of things_ doesn't look like a high level language task to me,
especially because of garbage collection. And I'm sure, like with most things
where I lack implementation experience, this is only the most cursory view of
the field.

My preferred mode of work is to use Python and if there's a true
bottleneck/limitation from the language features then break it out into a C
module. Maybe something like this would be more appropriate here instead.

------
tptacek
This is pretty retarded. The code in crypto competition submissions is
invariably crappy; nobody is expected to use it outside of the contest.

Unfortunately, Fortify's core customers are enterprise IT development teams,
who will be impressed by this. That real security professionals will ding them
for the misleading post matters not at all.

------
neilc
As the article makes clear, these are not buffer overflows in the _algorithms_
themselves, they are just overflows in the reference implementations.

