bug-fileutils
[Top][All Lists]
Advanced

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

Re: [ANNOUNCE] GNU fileutils 4.1


From: cyrus
Subject: Re: [ANNOUNCE] GNU fileutils 4.1
Date: Thu, 24 May 2001 08:33:00 -0700
User-agent: Mutt/1.2.5i

On Thu, May 24, 2001 at 08:19:09AM -0700, Paul Eggert wrote:
] 
] But if you add one simple options to md5sum to control the location of
] the checksum output, and to make a copy to standard output, you can
] get all the above.  For example, you could do the following:
] 
]    dd if=/big/input/device ibs=whatever |
]    md5sum -C checksum.txt |
]    dd of=/big/output/device obs=whatever
] 
] where '-C FOO' means "put a copy of the checksums in FOO and output a
] copy of the input to standard output".
] 
] > Because of the acceptability requirement for the courts, it is most
] > advantageous to get this into the official dd release, rather than a
] > separate program that may not be widely used.
] 
] But GNU md5sum is just as widely used as GNU dd.  And it seems to me
] that a simpler program like GNU md5sum, dedicated entirely to the
] problem of computing checksums accurately, is more likely to convince
] a court than a more complicated program like GNU dd-with-checksums
] would.
] 
] (My own beef with md5sum and shasum is that the checksum algorithm
] should not be part of the program name; there should just be one
] checksum program, with different algorithms as options.  But that's a
] different story...)

Hey folks, 

        I think Dave is correct, the chances of a court accepting
that "dd if=/big/input/device ibs=whatever | md5sum -C checksum.txt
| dd of=/big/output/device obs=whatever" is a valid way of guaranteeing
the integrity of a copy of data stored on disk is much lower than
the court accepting something like "dd if=/big/dev ibs=x checksum=md5
of=/output obs=y".  Why?  Because the first example, while perhaps
simpler and gentler to our Unix-trained eyes, has more parts (or
at least more visible parts).  To defend the first example as a
reasonable method for guaranteeing the integrity of a disk in court
not only do we have to defend MD5 as an algorithm and "dd" as a
tool, we also have to defend "md5sum" as a tool and we have to
explain and defend Unix pipes.  It may seem silly, but I do believe
Dave's correct when he states that there is tremendous value in
having this all wrapped up in a single, well-understood and
commonly-used tool.  Defending a one-off shell script in court is
going to be much trickier than defending a utility that ships with
every GNU-based operating system.  The courts aren't going to be
reading any code - the elegance or simplicity of a program isn't
going to impress them.  The degree to which they understand how one
party (in this, the forensics team) came to a conclusion or determined
evidence is what will make electronic evidence admissible (or not).

-- 
cyrus.
<address@hidden>



reply via email to

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