[Top][All Lists]
[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>
- Re: [ANNOUNCE] GNU fileutils 4.1, Dave Dittrich, 2001/05/01
- Re: [ANNOUNCE] GNU fileutils 4.1, Matthew Schalit, 2001/05/01
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/01
- Re: [ANNOUNCE] GNU fileutils 4.1, Jim Meyering, 2001/05/06
- Re: [ANNOUNCE] GNU fileutils 4.1, Dave Dittrich, 2001/05/23
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/23
- Re: [ANNOUNCE] GNU fileutils 4.1, Dave Dittrich, 2001/05/23
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/24
- Re: [ANNOUNCE] GNU fileutils 4.1,
cyrus <=
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/24
- Re: [ANNOUNCE] GNU fileutils 4.1, cyrus, 2001/05/24
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/24
- Re: [ANNOUNCE] GNU fileutils 4.1, Matt Schalit, 2001/05/26
- Re: [ANNOUNCE] GNU fileutils 4.1, cyrus, 2001/05/26
- Re: [ANNOUNCE] GNU fileutils 4.1, Matt Schalit, 2001/05/27
- Re: [ANNOUNCE] GNU fileutils 4.1, Paul Eggert, 2001/05/28
- Re: [ANNOUNCE] GNU fileutils 4.1, Dave Dittrich, 2001/05/28