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

[Dave Aitel <dave () immunityinc com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We should make them write them in asm then. Or is that basically what
they're doing? The cool thing about having it in (J)VM code is you'd
be able to model the operations to say "Now MOV's to memory where it's
not cached as in my memory model are going to cost me three hit
points" and maybe predict future performance? I dunno. It's just a lot
easier to covert Java code to Python code, so I prefer that cause I'm
selfish.  :>

Someone else pointed out to me that what Fortify didn't say is how
many false positives they got, and how long took to go through and
validate the results with X people. I think "How long did these
results take to generate" would be an interesting number, but not
really relevant to most developer shops. Fortify (and boutique shops
like Immunity) can afford to put a Bas Alberts on the results of a
static analysis run. Few dev shops can do this though. Most devs are
domain experts, and that domain isn't C source code security analysis.
It might be cryptographic design.

Lots of new security technologies look like this:

[some automated process] ---->  [some small team of really skilled
people] ----> results. This is great stuff, but it's not "scalable" in
the sense that the sales team will imply.

- -dave

Halvar Flake 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJoycGtehAhL0gheoRAucJAJ90NCP7lo776enKJhz/SyNZsdqgAACdEG7x
hL0hNXscW4CpSfy103b/RcQ=
=fsKE
-----END PGP SIGNATURE-----

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave