Re: It jerked and it berked but the thing really worked!

[Tal Garfinkel <talg () stanford edu>]

I think Halvar did a good job of explaining the purpose of specifying
the algorithms in C as
opposed to some other language - and as  he noted, for these purposes,
speed and algorithmic correctness
are the important considerations for this particular input to the process.

To step up a level:

At this point there are two questions to be answered about these
designs by the NIST process.

1) How much confidence do we have in the algorithm?
2) How fast can the algorithm be made to run in practice for many
classes of devices?

To answer question 1, you look at the written specification, then draw
on your many years of
cryptanalysis experience. To answer question 2, you look at the
written specification, draw on your
many years of experience building software and hardware,  futz with
and measure the C code, and as you see some
teams doing, go beyond this and implement it and measure it in
hardware, where its easier (and possible)
to exploit  more parallelism.

To conclude, this is not production code, and was not intended to be.
What the fortify guys did is cute - a nice reminder of how easy
it is to mess up in C- and has no relevance to what the NIST process is about.

Cheers,
Tal



On Mon, Feb 23, 2009 at 1:37 PM, Halvar Flake <halvar () gmx de> wrote:
> Hey all,
>
> no offense Dave, but a Java or C# implementation of a hash function is
> for most
> purposes useless. Hash functions are used in a lot of environments where
> interpreters for Java or C# are not available (nor desirable), and such
> code would
> make performance evaluations unnecessarily difficult.
>
> Also, hash functions are very much tailored to the CPUs they run on
> (hence the
> proliferation of add/xor/rol constructs in the SHA-3 contest) --
> building a hash
> function optimized for the JVM would probably use different building blocks.
> I have no idea which instructions in the JVM are "faster" than others, and
> what the effects of the JIT compiler are -- could anyone clue me in ?
>
> Thirdly, "optimizing a hash function at a higher level" ... *cough* ...
> there's no
> data structures to speak of, and each hash function just churns through
> bunch of bits.
> This sounds like having drunk too much HLL coolaid. "Don't worry about a
> thing,
> optimize the high level bits of your algorithm" ... doesn't fly when
> there is nothing
> to optimize at the high level, and you still need to calculate an HMAC
> for each
> packet passing through.
>
> Anyhow, your post served it's purpose ... as flamebait ;)
>
> Anyhow, back to work.
> Cheers,
> Halvar
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave