[Clarification edit further down.]
To distinguish already existing one-time pad files by their content instead of just their name ...
... is hashing meaningful? Or would the first X bytes (Length the hash would have.) have exactly the same representative value?
My guess is that the answer is
- "yes", if the OTP is flawless, e.g. based on a good physical source.
- "almost yes", if e.g. java.security.SecureRandom.getInstanceStrong() is used.
- the more "no" the less entropic the OTP is.
The reason why I assume the answer is "yes" to the question "Would just using the first X bits of the random file be as representative of the file, as hashing the whole file into X bits of hash?" is this:
512 bits of hash are limited in what they can express. There have to eventually be hash collisions. While these are super unlikely ... how likely is it that a proper random source will generate the same first 512 bits of the file? Same, I believe.
A hashing algorithm is designed to produce as varying hashes as possible for only slightly different source data. This is useful for low entropy data, the most extreme everyday example of which is a human language text file. But in this case here, we're dealing with material that is as close to a hash in nature as it gets: Maximum entropy noise - just the thing that a hash is designed to be, except not random but derived from the source data. But if the source data is also max entropy, then it is also maximally unique, just like the hash.
I want to "uniquely" identify files of identical length, let's say 128 MB. Classically, hashing is used. But the files in this case are one-time pads, so they're "pure noise".
Does it even make sense to hash such a file? Or would the first few bytes (of the same length that the hash would have) serve the purpose on exactly the same level?
In other words, if a file's entropy is as high as can be, do the first 64 bytes represent the whole file as well as a 64 byte hash of the whole file would?