1

How do I acquire the means to prove in the future that I had possission of a file now, without relying on the integrity of a single entity? (I believe one way of doing it would be to put the file through SHA1, and send a minimal amount of Ether (0.001) to the resulting Ethereum address (both SHA1 hashes and Ethereum addresses being 40 hexadecimals). But perhaps there are cheaper and more secure ways of doing it? Would this sort of proof be practical in a court of law? (I suppose a ``computer expert'' would have to testify.) I see time-stamping services being mentioned; but these seem to have 2 problems I'd like to avoid: (1) they require trust in a single entity; (2) they only work as long as the service is maintained.)

(This post has been edited after some of the answers and comments were made.)

  • 1
    Timestamping services exist for this reason. Symantec has(had?) a timestamping server that you could use to cryptographically timestamp hashes in order to prove existence of it at that time. – user Apr 04 '22 at 14:07
  • 1
    Do you want proof that a file existed at a certain time, or are you looking for validation of this specific and highly contrived process? Some people just attach the file to an email and send it to themselves. Then they forward the email to whomever wants proof... Why are you focused on ethereum, or cryptocoins, or blockchain? There are very simple and free ways to accomplish your goal. – schroeder Apr 04 '22 at 14:54
  • @schroeder, i don't understand how your suggestion proves anything. dates in emails can be altered. if there really are simple and free ways of doing what i want, please elaborate. – Callaeschrus Apr 04 '22 at 15:02
  • OP, you might want to consider taking a SHA256 hash (not SHA1) of the file, then storing the hash in the op_return field of a bitcoin transaction. Then, you can prove later that the file existed at the point in time when the bitcoin transaction was made, without disclosing the contents of the file. See https://security.stackexchange.com/questions/220247/how-to-prove-you-created-ip-using-a-notary for more info. – mti2935 Apr 04 '22 at 15:45
  • @schroeder, yes, sorry, i don't care about cryptocurrency; i just want the proof – Callaeschrus Apr 04 '22 at 15:50
  • 1
    So, you've set up an [XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). If you don't care about your specific implementation, then don't include it. Describe what you want to achieve, your resources, constraints, and context. Who needs the proof? What's an acceptable level of proof? How can this proof be delivered? – schroeder Apr 04 '22 at 15:52
  • 1
    I still don't know why you are holding on to this Ethereum implementation. I would simply say "put the file and its hash on the blockchain" and bypass the analysis of the minutia of the specific of your side idea. – schroeder Apr 04 '22 at 16:18
  • 1
    @schroeder, i thought an example would make it clearer what i mean – Callaeschrus Apr 04 '22 at 16:20
  • A more generic example, like I provided, would avoid getting lost in specific details. – schroeder Apr 04 '22 at 16:22
  • 1
    WRT to suggestion by @schroeder of emailing the file to yourself - this works well if you send the message through a service (e.g. Gmail) that DKIM-signs messages. The signature is over a hash of all of the message content (including attachments) and a timestamp placed on the message by the provider. So, these cannot be altered without breaking the signature, and signature can be verified using provider's public DKIM key, which can be obtained from their DNS. See https://support.cartika.com/portal/en/kb/articles/what-is-dkim-everything-you-need-to-know-about-digital-signatures for more info. – mti2935 Apr 04 '22 at 16:55
  • @mti2935, isn't it possible to generate a signature with a fake timestamp? – Callaeschrus Apr 04 '22 at 17:26
  • 1
    @Callaeschrus That is why you need a trusted third party creating the signature (Symantec timestamping or similar services). – user Apr 04 '22 at 18:08
  • 1
    @Callaeschrus If you are referring to the DKIM method that I described above - the provider (e.g. Gmail) puts a timestamp in the message headers, then that (along with other material) is signed using the provider's private key. So, faking the timestamp would require collusion on the part of the provider. If you are referring to the blockchain method that I described above, this is very difficult to fake, because it would require an enormous amount of hashing power (similar to a 51% attack). – mti2935 Apr 04 '22 at 21:03

3 Answers3

4

As @user mentions, there have been public services for this pretty much since the beginning of the internet; they are called Time Stamping Authorities (TSAs).

From a quick google search shows that there's a bunch of free and commercial TSAs.

TSAs are an important part of the Windows code signing ecosystem. Open any signed binary and you'll see that part of the code signature is a timestamp showing that the binary has not been modified since the date shown.

firefox.exe signature timestamp

So I think you have re-invented a technology that has existed basically since the beginning of modern computing.

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • but this requires trust in a single ``authority'', right? the advantage of the blockchain method is that it doesn't rely on the integrity of a single entity. moreover, what guarantee is there that these services will remain in existence? – Callaeschrus Apr 05 '22 at 07:24
  • @Callaeschrus The services don't need to stay up: once a timestamp signature is produced, it can be validated offline even decades later (which makes sense for code signing since the machine you're installing it onto might not have internet access, or you may be installing a driver necessary for accessing the internet). – Mike Ounsworth Apr 05 '22 at 20:34
  • As for distributed trust: it's true that this is not the fully decentralized blockchain, but notice in the screenshot that the timestamping Countersignatures field is a list? So even Microsoft expects that people will want to distribute trust over multiple timestamping authorities run by different operators. – Mike Ounsworth Apr 05 '22 at 20:36
  • 1
    This is the cheapest, and most reliable way to do this. You just need a list of TSA’s you sign it with, not just a single one. The block chain doesn’t add anything to the problem…. Since it’s just a distributed ledger, that is slow and quite expensive to add data to. (By design). Basically it’s a thirst model with either known parties or unknown parties, and the known parties obviously have a higher trust value. (Blockchain has the unknown parties). In both cases there should be transparent and public records (Certificate Transparency for the TSA and the Block chain for any Cryptocurrency. ) – LvB Jul 07 '22 at 08:41
0
  1. The collision resistance of SHA1 is under attack. So yes, it is a problem for this usage. Maybe not this week. I wouldn't, without a data center of GPUs, claim I can find a collision for a SHA1 hash. But on a long enough timeline I don't expect this proof to stand, esp with no metadata.
  2. I feel as though any data can be put in the payload of ETH. It will just cost more gas. So I don't understand the SHA1 limit. 100 bytes (typical ETH submission size) is enough for filename, SHA3-256/512, file size and checksum. The increased hash length and metadata greatly limits the possibility of a collision. Depending on file size, possibly to zero.
foreverska
  • 1,115
  • 11
  • would it be enough to create a collision; wouldn't one have to be able to generate a file with a given hash, so that one could claim that the file in question were modified to fit the hash after the time of the stamp? – Callaeschrus Apr 05 '22 at 08:01
  • You seem to be alluding to the usefulness of a collision. Without knowing what you're trying to do I'll guess some sort of magic trick. "I can tell the future, I commit to this prediction by it's hash." With an infinite amount of data there is probably a file with the opposite prediction and most likely some junk data elsewhere in the file. The junk could be hidden in metadata so it doesn't look weird to a verifier. Sha-1 has a pretty nasty chosen-prefix collision attack known ($100K USD attack today) so I would not expect this to stand for any real period without mitigation. – foreverska Apr 05 '22 at 14:02
-1

If my answer is in line with your context. You need a way to validate and prove that you had a file at a set time. If a computer expert can testify as you say then you can do full system image as backup of your drive. And as such you can keep the hashes of the file as evidence. Most like computer forensics knowledge will be needed.

Sha256/sha512 would be better in this case.

geek
  • 1
  • 2
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Apr 05 '22 at 07:28
  • Any data gathered by system forensics can also be *altered* by system forensics ... – schroeder Apr 05 '22 at 13:20
  • I don't undermine the fact that a computer forensics can alter evidence as required that it why it would be wise for the user to keep hash of the original image for authenticity (without relying on the integrity of a single entity). – geek Apr 05 '22 at 14:11