4
$\begingroup$

Let's say I have a text file (crypto.txt). Let's assume the checksum function can be any type of function (MD5, SHA-1, anything else). Is there a way that the checksum value IN the file (crypto.txt contains a string that could be a possible checksum), when put through a checksum program, outputs the exact same value as the content inside the text file?

In case I lost you, here's a quick breakdown:

crypto.txt contains a viable checksum value (said value = x)
checksum of crypto.txt = x

Is this even possible? Is there math that proves it wrong/right?

|improve this question
$\endgroup$
  • 2
    $\begingroup$ Does your "checksum" have to be cryptographically secure? $\endgroup$ – yyyyyyy Feb 27 '17 at 14:14
  • 2
    $\begingroup$ Welcome to Crypto.SE, Pat! To clarify: MD5, SHA-1, and the lot are “cryptographically secure hashes”, not “checksums”. Which of the both do you mean? $\endgroup$ – e-sushi Feb 27 '17 at 14:18
  • 1
    $\begingroup$ Relevant: Is it theoretically possible to construct a string that contains its own hash value? $\endgroup$ – otus Feb 27 '17 at 16:42
  • $\begingroup$ otus That answers my question, thanks! yyyyyyy It doesn't really matter to me. And e-sushi, thanks for the welcome! I meant checksums, but as you may be able to tell, I'm not well educated in this, so my apologies. $\endgroup$ – Pat Feb 28 '17 at 13:37
1
$\begingroup$

For a checksum such as CRC16 or CRC32 it is very much possible to have a value over a text that contains the same CRC value (in whatever format, be it binary, hexadecimals or base 64). The proof of this is simple: you can simply put e.g. 32-48 bits counter at the end of the text and wait until you find a CRC. But in practice you can just calculate the value you need to prefix, append or anything in between and get the right CRC - if it is included or not. Checksums such as CRC are not secure.

For secure hash functions this is not possible. It is even computationally not possible to find any message $m$ where the hash value is $h$, for any chosen $h$ (that is not a known hash value). This is a much stronger presumption than the one you are proposing. It is not possible to find $x = \operatorname{H}(a | \operatorname{encode}(x) | b)$ even if you can chose any special value of $a$ and $b$, and any $\operatorname{encode}$ operation.

It is not possible to prove above completely for the simple fact that the security of hash functions cannot be proven. SHA-1 was thought to be secure for a long time, but by now it might be possible to create a text where the hash value is included.

|improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.