On 26/03/12 12:22 PM, Seth David Schoen wrote:
ianG writes:
On 26/03/12 07:43 AM, Jon Callas wrote:
This is precisely the point I've made: the budget way to break crypto is to buy
a zero-day. And if you're going to build a huge computer center, you'd be
better off building fuzzers than key crackers.
point of understanding - what do you mean by fuzzers?
Automatically trying to make software incur faults with large amounts of
randomized (potentially invalid) input.
Thanks. That's what I thought Jon meant.
Ok, so Jon's point is that the attacker is better off searching for
weaknesses using fuzzers. Than trying to exploit crypto. With a huge
data center. Which costs gigabux, whereas fuzzing just costs centibux
in power.
OK, slow today :) Stop reading now, following is blabbering.
https://en.wikipedia.org/wiki/Fuzz_testing
Side anecdote. Funnily enough, when I was a 4th year thesis student
back in 1983, I had two choices - Ada operating systems research, and a
sort of reverse parser (inverse yacc) to generate random stuff to some
defined description. The purpose I imagined for my reverse parser idea
was two-fold; one was to generate large D&D maps without spending more
time on them than the game itself, and the other was to generate feeds
into programs to test them with.
(I chose the first direction for my thesis and it was a monumental
failure. Doh!)
If you get an observable fault you can repeat the process under a
debugger and try to understand why it occurred and whether it is an
exploitable bug. Here's a pretty detailed overview:
https://www.blackhat.com/presentations/bh-usa-07/Amini_and_Portnoy/Whitepaper/bh-usa-07-amini_and_portnoy-WP.pdf
When it was first invented, fuzzing basically just consisted of feeding
random bytes to software,
In my use of fuzzing, all protocol or data classes have a function that
generates a random example object. Then, a test harness calls this, and
uses that random example to network-send-and-recover the object. Then,
the object-compare function is used to test the result. This process is
of course recursive, and also cross-implementation. In my experience
this strategy has reduced simple protocol bugs by around two orders of
magnitude, leaving more or less only semantic bugs.
but now it can include sophisticated
understanding of the kinds of data that a program expects to see, with
some model of the internal state of the program.
Curious that they see it as externally created data wisdom. My first
impression is that this would be quite inefficient because it creates
two centers of knowledge for one class.
It's a bit like the 1980s idea of putting the documentation inside the
source - that had a dramatic effect in improving the quality of doco,
because it reduced the centers of knowledge to one.
I believe there are
also fuzzers that examine code coverage, so they can give feedback to the
tester about whether there are parts of the program that the fuzzer isn't
exercising.
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
