0
$\begingroup$

Okay so I've got an assignment for cyberlaw and this could be irrelevant to the question. But I have a situation where someone signed a a will using an advanced electronic signature, but this signature was separate from the will itself. So two different documents: (1) signature.txt and (2)FinalTestament.txt. If these two documents' SHA256 matches, can I assume that there was no interference with the Will or does the SHA256 not have anything to do with the actual content contained in a document? And is just really an identifier that the same person created the two documents? I'm really struggling to grasp SHA256 - so any links to explainers that would help in this context would be great. Thanks!

$\endgroup$
1
  • 1
    $\begingroup$ Is this a law question or a technical question? If the former, then the legal definition of approved and officially recognized hash and digital signature algorithms are involved; otherwise, the folks have it properly answered and you may consider accepting your favorite to earn yourself your first 2 reputation points. $\endgroup$
    – DannyNiu
    Commented Apr 17, 2022 at 12:25

2 Answers 2

1
$\begingroup$

If these two documents' SHA256 matches

then by definition of collision resistance, these two documents are identical, or (including and) SHA-256's collision resistance is broken. There is consensus among experts that SHA-256's collision resistance is not breakable by means available today (that is, no one has the power to create distinct documents with the same SHA-256 hash).

Hence there is expert consensus that these two documents must be identical, under the quoted assumption; which, by far, is the weakest spot in the demonstration, since it depends on how the (necessarily digital) documents are kept and their hash obtained and compared.


The above answers the question as worded, but we are now told something very different:

when the signature.txt (advanced electronic signature) is decrypted using the public key provided, it results in a SHA256 document hash which matches the SHA256 hash of the FinalTestament.txt

That's incorrect terminology: one never deciphers with a public key. The goal of encryption is to transform a piece of data in order to make it unintelligible until is it decrypted by the holder of some secret; and, as it's name implies, a public key is not secret. Here, we do not decrypt. We must read: "signature.txt is verified using the public key provided".

And, it is not correct in general that signature verification rebuilds a hash, then compared to the hash of a document in order to decide if the signature applies to that document. That is correct for textbook RSA signature of the hash¹, RSA-FDH, and (although unusual) can be made correct for RSASSA-PKCS1-v1_5. But it is not the case for many other signature schemes: RSASSA-PSS, ECDSA, EdDSA, DSA, where the hash (or the document to check) must be an input of the signature verification process. Thus we probably should read: "signature.txt is verified against the hash of FinalTestament.txt using the public key provided"

Most importantly: nothing in the problem statement or additional comment tells that the public key is the deceased person's public key, (and if we want to be picky, intended for the signature verification system used). Thus a verification made with that public key is not a technically valid indication that this person approved the will.

Even if we add that the public key is that of the deceased person, there is no indication FinalTestament.txt is the final testament²; that the signature was not made under duress; that the deceased had the legal capability to make a valid testament; that the signature system used is legally binding (rules for that vary).


¹ But textbook RSA signature of a SHA-256 hash is vulnerable to existential forgery, due to the Desmedt and Odlyzko attack.

² Or even the only testament that verifies against signature.txt and public key: some signature systems like the original short Schnorr signature allow the signer to craft very different documents with identical signature. Such signature systems are best avoided in legal contexts!

$\endgroup$
1
  • $\begingroup$ Hi! Thanks for your answer! But I misinterpreted the statement! It is not that the documents SHA256 hash are the same but that, when the signature.txt (advanced electronic signature) is decrypted using the public key provided, it results in a SHA256 document hash which matches the SHA256 hash of the FinalTestament.txt $\endgroup$
    – Phillip
    Commented Apr 17, 2022 at 11:46
0
$\begingroup$

SHA-256 is a cryptographically secure hash function. That means that it exhibits three important properties:

  • Preimage resistance: given a hash value, it is difficult to find any message which has that hash value.
  • Second preimage resistance: given a message, it is difficult to find another message with the same hash.
  • Collision resistance: it is difficult to find two messages with the same hash.

This is summarized in the relevant Wikipedia article. In this context, a "message" is any series of bytes (possibly with an impractically large limit on size). It can be a file, an email, or practically anything else that a computer can store.

Because of these properties, we can generally assume that two messages (files, etc.) with the same SHA-256 hash are the same. (There is an extremely unlikely possibility that that is not the case, but you have much better chances of getting struck by lightning repeatedly.) So in this case, the two files are identical; if one of them had been modified, then the hash would not be the same. Note that anyone can compute the hash of a document: hash algorithms are public and can be computed efficiently by everyone.

When we create a secure digital signature, we take a key pair, which contains a public key (known to all) and a private key (known only to its owner). We hash the message (using a hash like SHA-256) and then sign the hash with the private key. A person who knows the public key can then verify that signature and learn one of two things:

  • The message has not changed and is valid for that public key (that is, the owner signed an identical message); or
  • At least one of those is not the case.

Note that it is possible for an attacker to create a different key pair and signature which also validate the message (sometimes without ever seeing the message), so we must know that the public key is actually part of the key pair for the party in question. Different protocols solve this problem differently.

If we have a signature and the document over which it was signed, those two won't have the same hash. The signature is usually a fixed size depending on the key type, key size, and protocol, and will be that same size (which is relatively small) regardless of the size of the document. We can sign many gigabytes of data with a signature of just 64 bytes.

In the context of the law, a matching hash with a cryptographically secure hash function means that the documents are identical, bit for bit. If you have a document with a secure digital signature, and you have a reliable way to verify the signer's public key, then you can verify that the document was signed by that key and has not been modified since it was signed.

$\endgroup$
1
  • $\begingroup$ Oh yes you right! The signature in found in signature.txt when decrypted using the public key results in a SHA256 hash which matches with the SHA256 has of the document FinalTestament.txt. So its not that the two documents hashes are identical but that the document was signed by the key and has not been modified - correct me, if this interpretation is incorrect. Based my little knowledge and research on the topic, I also found it weird that the two hashes were the same, but I was misunderstanding what was being said because I didn't understand. Thank you so much @bk2204! You are a life saver. $\endgroup$
    – Phillip
    Commented Apr 16, 2022 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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