Re: [ANNOUNCE] GNU fileutils 4.1

[Paul Eggert]

> Date: Thu, 24 May 2001 11:08:36 -0700
> From: cyrus <address@hidden>
> 
> By incorporating checksumming functionality into it, we get to
> piggyback some useful forensics functionality on the coattails of a
> known, trusted utility.

You can't have it both ways.  Either you're using a standard utility
that is codified by POSIX (an ISO standard) and is widely used; or
you're using code that you wrote yourself, for this application.

In this case, it's clearly the latter.  A nonstandard "dd" feature
that was written just for this application is not a "known and
trusted" feature.

> There's no reason to defend code in court.

I was responding to your earlier message complaining about the
difficulty of "Defending a one-off shell script in court".  A shell
script is code.  Anybody who will try to attack your methods in court
will attack all your methods: the source code, the procedures, the
chain of custody, etc., etc.

Your defense will rely on expert witnesses who will look at all those
things.  If you've done your job right, you will have a
well-established procedure that will do many things, only one of which
is invoking "dd".  That procedure can just as easily invoke "md5sum"
as well.  If your expert witnesses cannot defend a procedure that
invokes "md5sum", they won't be able to defend a procedure that
invokes a nonstandard "dd" either.

> Van Oorschot and Wiener's proposed collision attack is infeasible
> in practice (particularly for format-constrained binary data

But a general checksum procedure should be reliable for all data, not
just for format-constrained binary data.  And I'm not sure that the
attack is infeasible even for binary data, at least if one
hypothesizes an attack a few years from now.

> Slightly altering, say, an inode or file meta data would effectively
> render the filesystem broken

Slightly altering a spreadsheet entry can make or break a case.

> MD5 is still a widely-respected algorithm.

It was widely-respected many years ago, but that was before some of
its flaws were discovered.  Its use has been more controversial since
then.  It is an exaggeration to say that it is "widely-respected" now.
It's certainly an important algorithm, and it must continue to be
supported for interoperability, but I wouldn't recommend it for new
applications unless you know what you're doing.

> MD5 is the basis for several accepted industry-standard security
> mechanisms (SSL and IPSEC, for instance, both make extensive use of
> MD5 as a message digest algorithm).

That is a different application area, and there MD5 is more suitable
for several reasons.  E.g.:

 * SSL and IPSEC employ hidden data, whereas this forensic application
   does not.  A Dobbertin-style attack would not work against
   HMAC-MD5; but it might work against md5sum.

 * Those protocols use MD5 for message authentication, and this has a
   transient effect.  Even if I were to find a new algorithm today that
   would break HMAC-MD5 in five seconds on a standard PC, that would
   not attack HMAC-MD5 authentications done in the past.  But a new
   algorithm to break MD5 checksumming in 5 seconds would be a serious
   attack on this forensic application, as it would cast doubt on all
   data archived in the past.

 * MD5 is about twice as fast as SHA1, and CPU performance is much more
   critical when slinging packets around (particularly with low-power
   portable devices) than it is when making forensic copies.

Before investing more of your time on this, I suggest that you run the
proposed algorithms and procedures past one or two first-class
computer security experts.  It is more important to do this than to
worry about whether "dd" or "md5sum" should be modified.  It always
helps to have another set of eyes to look at the problem.


> I also haven't quite heard a good argument for why *not* to put
> this functionality into dd - care to expand on this at all?

The Unix philosophy is to use different tools for different things,
and to not have a single program that does everything.

(Now, if you were talking about an Emacs extension, that would be a
different matter.  :-)