by Bob Coleman » Fri Jul 20, 2018 12:21 pm
The below is all correct, I think. You and TAC109 are both correct, I think.
The programs contain two types of validate: validate byte for byte and just plain validate.
The points you making are, I think, correct for validate byte for byte especially the point that the original partition(s) which were imaged must be available.
However, as TAC109 says, the programs can perform a validate (not byte for byte) on any image including a copied image. This doesn't involve or require the original partition(s) that were imaged. It doesn't verify that the image being validated is a accurate copy of anything, but it does verify as TAC109 said that the image being validated is internally consistent and complete.
You say "The chance of accidentally finding a different source file with the same MD5 checksum is millions to one". No argument there.
TAC109 and I believe that the chance of an image which is validated to be "internally consistent and complete" also being incorrectly copied and/or corrupt is vanishingly small. I won't attempt to debate whether the chance of this is millions to one.
We are just trying to point out to you that the image programs can perform a type of validate without the original partition(s) that were imaged being available. If you realize that but believe that type of validate is not good enough, fine.
rustleg wrote:
> TAC109 wrote:
> > ...
> > IFL, IFD, and IFW all have the facility to validate an image, whether it consist
> of
> > one file or many files. For example, if you start any of the GUI's (IFL, IFD, or
> IFW)
> > it is right there on the front window, the 'Validate' option.
> >
> > ...
> This validation is possible because at the time of validating the partition you are
> imaging is available and the file that IFL/IFW/IFD has created is also available. So
> the file can be read and checked back against the partition. This protects against
> things like disc errors.
>
> When the image file has been copied on to another PC, the original partition isn't
> available so there's no way to compare the contents of the file against the
> partition.
>
> The only way to perform a validation in this instance is for a checksum (also called
> message digest or hash) such as MD5 to be calculated from the validated image file
> and saved on a text file. MD5 checksums have the property that any change to a byte
> of the source file results in a change in the checksum. The chance of accidentally
> finding a different source file with the same MD5 checksum is millions to one. MD5
> isn't perfect for security purposes but is widely used for file integrity checking -
> see Wikipedia.
>
> If you have a MD5 checksum you don't need the original partition to be available to
> check the integrity of the file. You can store the file on a different computer and
> calculate its MD5. If you get the same answer as the MD5 originally calculated when
> the file was on the original computer you can be sure the file hasn't been changed
> in the process of copying to the other computer. This is not just a theoretical
> requirement. USB sticks can be unreliable and can introduce errors. It has happened
> to me.
>
> Of course its possible that Terabyte can create an image, hash it, then put both
> image and hash into one .tbi file. This would allow them to remotely validate a tbi
> file. But I doubt they have done this or they would have said so and also provided a
> feature in their programs to verify a .tbi file without the original partition being
> there.