[cryptography] [info] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)
iang at iang.org
Sun Mar 25 22:07:34 EDT 2012
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
OK, slow today :) Stop reading now, following is blabbering.
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
> 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:
> 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
More information about the cryptography