[cryptography] Reply to Zooko (in Markdown)

Nico Williams nico at cryptonector.com
Sat Aug 17 17:20:45 EDT 2013

On Sat, Aug 17, 2013 at 12:50 PM, Jon Callas <jon at callas.org> wrote:
> On Aug 17, 2013, at 12:49 AM, Bryan Bishop <kanzure at gmail.com> wrote:
> > Would providing (signed) build vm images solve the problem of distributing
> > your toolchain?

A more interesting approach would be to use a variety of independently
sourced disassemblers to compare builds and check that object code
differences from one build to the next can be accounted for by
corresponding changes to the source code or build systems.  This is
not really tractable when you change compilers or their settings, but
at least you can get a pretty good idea as you develop of what object
code is being produced.  This is terribly time-consuming, but you can
automate the comparison process and archive results for post-mortems
as a deterrent.  You'd have to do this on multiple machines handled by
different people, and so on...

It's not too farfetched, see http://illumos.org/man/1onbld/wsdiff
(Solaris release engineering used to use this tool, and I imagine that
they still do).

> I *cannot* provide an argument of security that can be verified on its own.
> This is Godel's second incompleteness theorem. A set of statements S cannot
> be proved consistent on its own. (Yes, that's a minor handwave.)

No one can.  We're in luck w.r.t. the Thompson attack: it needs care
and feeding, as it will rot if not kept up to date.  Any effort to
make it clever enough to keep up with a changing code base is likely
to lead to the attack being revealed.  Any effort to maintain it risks
detection too.  Any effort to use it risks detection.  And today a
Thompson attack would have to hide from a multiplicity of disassemlers
(possibly run on uncompromised systems), decompilers, and, of course,
tracing and debugging tools that may work at layers that the generated
exploit cannot do anything about (e.g., DTrace) without the bugged
compiler having been used to build pretty much all of those tools.
That is, I wouldn't worry too much about the Thompson attack.

> All is not lost, however. We can say, "Meh, good enough" and the problem is
> solved. Someone else can construct a *verifier* that is some set of policies
> (I'm using the word "policy" but it could be a program) that verifies the
> software. However, the verifier can only be verified by a set of policies
> that are constructed to verify it. The only escape is decide at some point,
> "meh, good enough."

Yes, it's turtles all the way down.  You stop worrying about far
enough turtles because you have no choice (and hopefully they are too
"far" to really affect your world).

> I hope I don't sound like a broken record, but a smart attacker isn't going
> to attack there, anyway. A smart attacker doesn't break crypto, or suborn
> releases. They do traffic analysis and make custom malware. Really. Go look
> at what Snowden is telling us. That is precisely what all the bad guys are
> doing. Verification is important, but that's not where the attacks come from
> (ignoring the notable exceptions, of course).

Indeed, the vulnerabilities from the plethora of bugs we
unintentionally create, overwhelm (or should, in any reasonable
analysis) any concerns about turtles below the one immediately holding
up the Earth.


More information about the cryptography mailing list