[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Verifying Toolchain Semantics

From: Mike Gerwitz
Subject: Re: Verifying Toolchain Semantics
Date: Mon, 6 Oct 2014 00:23:23 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Oct 05, 2014 at 12:11:00PM -0400, Ian Grant wrote:
> > As has been stated---your concerns are substantiated and understood,
> I wasn't aware that my concerns _have_ been substantiated. How? I am
> not sure they have been understood, either.

They were substantiated long ago by the very references you've provided.
Your application to the GNU project doesn't make this a novel discussion.

The problem is understood. A proper and **practical** solution to the
problem may be less well understood, but you haven't yet convinced those in
charge of making such decisions that this is a threat (a) greater than all
other threats worth devoting time to protect against; and (b) worthy of such
an enormous time investment at this time.

It is worthy of addressing, and addressing it in the manner that you and
Dijkstra suggest will certainly go a long way to preventing nearly all
problems contributing to (a), but you need to take a different approach if
you're going to incite such change.

> Well my body is getting on for 50 years old, so it doesn't matter so
> much. Here's a "better" example:

I hope very much that using Aaron as an example is to further your argument
that programming is a life-or-death situation, and that it's not a "better"
example of personal neglect or instability. The former has no relation to
the topic at hand, and the latter is---well, let's just hope that you poorly
represented yourself.

> > This argument is not valid---why is it hard to alter a PDF? In fact,
> > PDF manipulation is a dark (and probably cancer-causing) art that's
> > automated by countless businesses worldwide; it is a topic that eats
> > up a significant portion of development time at my employer's office.
> It is valid. If you want to see why, then try to alter one of the PDFs
> I've sent out.
> What will you do when I later send out a series of checksums using a
> checksum algorithm that neither you or anyone else ever heard of
> before?

Your argument favored PDF over plain text. The point that I had made was
that you are unable to verify that two PDFs---unless binary
identical---render text that is unchanged from the original. If I convert
your PDF to a PNG and back to a PDF, it renders the same text. What does
that mean to you? Does that mean that the text has been altered? Do you care
that your work has been distribute in an alternative form? At what point
does it become "modified"? And how can you distinguish reasonable
alterations from unreasonable ones?

What does your checksum algorithm accomplish than existing checksum or
hashing algorithms do not? Why can that same principle not be applied to
plain text---why does the implementation of your checksum make it any more
difficult to modify the PDF? And why is your checksum better than an
established and heavily studied cryptographic standard (e.g. SHA-256)?

> > Have you considered just distributing a GPG/PGP signature with your
> > works, or even signing the work itself? After all, this whole
> > discussion is about proving the unlikelihood of and preventing the
> > modification of data.
> Of course I have thought of that, and rejected it as a pointless waste
> of time! If you read what I've written, on this list

You have written a lot on this list, and there has been an absurd amount of
redundancy. I have not read it all.

> and also in that blog article Mark pointed up, you will see why I think
> this. And even if public key crypto was positively secure, it is worthless
> when I have no rational basis for confidence in the security of the system
> which holds the private keys.

In the case of PGP, you hold your private keys. I suppose if you're worried
about a Thompson virus, you can't even provide yourself assurances of the
security of your own system, but in such a severe case, there is nothing you
do on your system that can be trusted, so surely you must not enter your
password to access your e-mail on any of those systems. Because if you did,
surely someone could just impersonate you to begin with, and there'd be no
point in signing anything cryptographically, because such attempts would
have been preempted.

All that aside, it is still possible to host your private key on a machine
that is wholly segregated from the rest of the world, perform your
cryptographic operation on that, transfer its output (doesn't really matter
how at this point, as long as it's output-only and cannot be used to
compromise the machine---it only matters that the same output is supplied to
each machine) to N machines with N different lineages (even if one is a
PDP-11!), and verify the result of the cryptographic operation on those
machines to ensure that your data were not modified in the process of
applying the cryptographic operation.

But we're not talking about such assurances here, so most of those steps
would be unnecessary---upon receiving your signed request from the machine
hosting your private key, it *does not matter* what its output is: the plain
text is left, well, plain. You can verify it by hand. Then everyone else in
the world with your public key can verify that it is indeed the signature
produced by the same machine that produced the signature for all of your
other archived messages all over the internet (mailing lists, your own blog
entries, etc)---a task that can be trivially automated to scan for

Your checksum would merely state "this PDF has not been modified". This
would say "this PDF has not been modified and I am actually the same person
that wrote all these other articles / e-mail messages, while claiming to be
Ian". And even if you have no trust in the cryptography that links the
signature to the private key, or have no trust in public key cryptography,
the signature *still* contains a hash[0], and so you get the former
assurance for free, assuming a [currently] trusted digest algorithm.

So tell me: how does your yet-to-be-released checksum algorithm provide
any better assurances than this?

Oh, but let's not stop there! Your signature relies on the security of the
hashing algorithm---if a collision is found, what does that mean for
cleartext signing? Well, if you had distributed a plain-text document in
ASCII (and Unicode is almost certainly fine too), it's very highly likely,
unless the hashing algorithm is just brutally and fundamentally flawed, that
the collision will contain a lot of garbage---garbage that would be
immediately noticeable. But if you distribute a PDF, it might be possible to
hide all of that garbage within its constructs.

> PK crypto, in this state we're in, has negative value: it just creates a
> false sense oif security, and _discourages_ people from actually thinking
> about the real problem because they "know" their comms. are secure. They
> don't know that at all.

I certainly hope that developers of systems that use public-key cryptography
understand the obvious, fundamental principle that you described in the
article that Mark linked.[1] Of course, I understand that this is not often
the case, and it's certainly not the case for most *users* of the software.
And that is dangerous, because GPG/PGP/PK-crypto users should certainly be
aware that any message they encrypt, even if the private key is discarded,
may very well one day be broken. And the adversary may be little 10yo Bobby
on his modern-era PC in the not-too-distant future.

But for the purpose of *this* discussion, the integrity of your chosen PK
algorithm isn't entirely relevant. Yes, your identity assurance is nice to
have, but at the *very least*, your signature provides a hash that is

Let's not play the "well the software performing the verification may be
compromised" card---it's still possible to manually perform the verification
if you really felt it to be necessary, if the situation were dire enough.

So again---have you considered distributing a signature with your documents?

> I could ship them as low-res PNG files. But really, it would be much
> better just to get good working PDF viewers. There are _millions_ of
> important documents which are in PDF form. We need to be able to
> reliably verify and reference text within them. These include things
> like the Intel architecture reference manuals.

Certainly, and I'm not arguing that. I'm arguing against your assertion that
PDFs are harder to modify than plain text and somehow provide greater
assurances; I'm arguing the exact opposite.

> I am well aware of this, and it is one reason why we need to be able
> to read PDFs reliably. We can then vary the concrete representation
> and defeat attempts at mass-surveillance and also prevent people from
> using automated methods to edit the files in transit.

Preventing file modifications in transit is a well-understood problem
(and the problems with various implementations understood) unrelated to this

But having a PDF reader that is generated from a formal definition won't
prevent the problems that I described (although it'd prevent the majority of
today's attacks against, say, well-known proprietary readers), because *PDF
exists to present formatted text*, and there are countless ways to present
what appears to be the exact same formatting. So the answer to the
fundamental question "do PDFs X and Y present equivalent content?" is

> And before some smart-ass says "Oh yeah, and how are you going to
> verify the contents with cryptographic checksums?" I warn you to
> _think_ first, because I will metaphorically tear you into fifty thin,
> bloody little strips before you can say "Doh!"!

I don't follow. Surely your method isn't novel.


Mike Gerwitz
Free Software Hacker | GNU Maintainer
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]