What a Hash Value Proves in a Criminal Case: Integrity, Time and Origin of Digital Evidence
Published
Abstract
Turkish criminal procedure secures digital evidence by fixing a moment and sharing it: a full backup is taken when a computer is seized, and a copy of that backup goes to the suspect, recorded and signed. The hash value is the instrument that ties every later copy to that moment. In practice it is read in two opposite ways, as a seal of authenticity, and, since the MD5 and SHA-1 algorithms were broken, as a number that proves nothing. Both readings misstate the science. A digest answers one question, whether two sequences of bits are identical, and how reliably it answers depends on which property of the algorithm the question needs. Whether a copy has been altered since the digest was recorded rests on second-preimage resistance, which the standards bodies still treat as intact for MD5 and SHA-1. Whether a different file could have been prepared in advance to share the digest rests on collision resistance, which they no longer provide. No digest says anything about what happened before it was computed or about who made the data. The article sets out what the law secures, what each property means, what has been broken, and what a seizure record, an expert report and a court should therefore state.
Keywords: digital evidence, hash value, chain of custody, Code of Criminal Procedure Article 134, collision resistance, second-preimage resistance, expert evidence.
I. Introduction
A seized hard disk is examined through copies: the examination is done on a copy of its data, then on copies of that copy, often by several experts over months or years. What lets a court treat the last copy as the disk that was seized is a short string of characters: the hash value, or digest, computed from the data. The guide of the United States National Institute of Standards and Technology (NIST) on forensic techniques describes the routine in one sentence: "Data integrity verification typically consists of using tools to compute the message digest of the original and copied data, then comparing the digests to make sure that they are the same."2
Two misreadings surround that string. One treats a matching digest as proof that the evidence is genuine, as if it said something about where the data came from. The other, since the MD5 and SHA-1 algorithms were publicly broken, treats any record that carries only those digests as worthless. We argue that both are wrong, and wrong for the same reason: a digest proves one thing, and how well it proves it depends on which security property of the algorithm the question in the case requires. Getting this right matters to every side of a criminal case. It decides whether a defense objection should succeed, whether an expert's conclusion is sound, and what the court may infer from a number in a report.
The statutes were read in the Ministry of Justice's UYAP legislation program and the scientific and standards texts from their publishers, all on October 20, 2026. Translations of Turkish provisions are ours.
II. What the Law Secures
Article 134 of the Code of Criminal Procedure No. 5271 governs the search of computers, the copying of their data and their seizure. Two of its paragraphs carry the weight for the present question. Under paragraph 3, "during the seizure of a computer or computer files, all data in the system are backed up". Under paragraph 4, "a copy is made from the backup taken under the third paragraph and given to the suspect or the suspect's counsel, and this is entered in a record and signed".3 The Regulation on Judicial and Preventive Searches repeats the rule, extends the backup to computer networks, remote files and removable devices, and in its fourth paragraph, as amended in 2016, requires the copy of the backup to be made in electronic form and given to the suspect or counsel.4
The statute does not mention a hash value. What it does is fix two things: the moment at which the data are secured, the seizure, and the means by which the defense can hold the prosecution to that moment, its own copy. The digest is the expert's instrument for linking every later copy to both. Its meaning is therefore a matter for the expert report and for the court's evaluation. Article 67(1) requires the expert to explain "the operations performed and the conclusions reached". Article 217 lets the judge decide only on evidence discussed at the hearing, evaluated freely, and allows the charge to be proved by any evidence obtained lawfully, while Article 206(2)(a) requires the rejection of evidence obtained in breach of the law.5 A court that evaluates a digest freely needs to know what it can and cannot show.
III. Three Properties, Three Questions
A cryptographic hash function turns data of any length into a fixed-length value. NIST's recommendation on hash applications names three properties an approved hash function is expected to have, and the difference between them is the whole of the matter.6
Collision resistance means that it is computationally infeasible to find any two different inputs with the same hash value. The attacker chooses both inputs.
Preimage resistance means that, given a hash value, it is computationally infeasible to find an input that produces it.
Second-preimage resistance means that, given a specified input, it is computationally infeasible to find a different input with the same hash value. The first input is fixed and the attacker must match it.
For an algorithm with an output of L bits, the expected strength is L/2 bits against collisions and L bits against preimages and second preimages. NIST draws the consequence that matters here: "A hash function that is not suitable for one application might be suitable for other cryptographic applications that do not require the same security properties."7 Whether an algorithm is "broken" is therefore not a yes or no question. It is broken for a property.
IV. What Has Been Broken, and What Has Not
MD5. In 2005 Xiaoyun Wang and Hongbo Yu published an attack that found collisions of MD5 "in about 15 minutes up to an hour computation time".8 By 2011 the Internet Engineering Task Force recorded attacks that find an MD5 collision in about a minute on a notebook computer, and reports of ten seconds or less, and concluded that "it is not prudent to use MD5 when collision resistance is required". The same document records that the best preimage attack on MD5 has a complexity of 2123.4, "still pretty high".9
SHA-1. In 2017 Marc Stevens and his co-authors published the first collision for the full SHA-1. They chose the beginning of the colliding messages so that the result is "two distinct PDF documents with the same SHA-1 hash that display different arbitrarily-chosen visual contents", using about 6,500 CPU years and 100 GPU years of computation.10 In 2020 Gaëtan Leurent and Thomas Peyrin computed the first chosen-prefix collision for SHA-1, in which the two colliding messages may begin with any two prefixes the attacker chooses, and put the cost of renting the hardware at about US$11,000 for a collision and US$45,000 for a chosen-prefix collision, concluding that "the same attacks that have been practical on MD5 since 2009 are now practical on SHA-1".11
The standards bodies' position. NIST's transition recommendation of March 2019 disallows SHA-1 for generating digital signatures, but states that "for non-digital-signature applications, the use of SHA-1 is acceptable for applications that do not require collision resistance", and that SHA-256 and the other SHA-2 functions are "acceptable for all hash function applications".12 In December 2022 NIST announced that SHA-1 is to be phased out of its remaining specified uses by December 31, 2030, after earlier telling federal agencies to stop using it "in situations where collision attacks are a critical threat, such as for the creation of digital signatures".13 SHA-256 is specified in the Secure Hash Standard, FIPS 180-4.14
The record is thus precise. For MD5 and SHA-1, collisions are practical. Second preimages are treated differently: the best preimage attack on MD5 that the IETF records stands at 2123.4, and NIST still accepts SHA-1 for uses that do not require collision resistance. Taking an existing file and producing a different file with the same digest is the attack the standards bodies have not recorded as practical.
V. What This Means for Evidence
A. The Integrity of a Copy
The ordinary question in a criminal case is whether the copy the expert examined is the backup taken at seizure. The backup existed first, its digest was recorded, and the question is whether anyone could have made a different copy that matches that recorded value. That is a second-preimage question. On the record of the standards bodies, an MD5 or SHA-1 digest recorded at seizure still answers it. An objection that says only "MD5 is broken, so the image is unproven" confuses the two properties and should fail. It is not the end of the inquiry, however, because the digest proves the copy only against the recorded value, and the next two questions remain.
B. A Twin Prepared in Advance
A collision attack needs the attacker to create both files. It matters wherever someone could shape the content before the digest was fixed: a file handed over by a party, a document whose origin is contested, or data placed on a device before it was seized. In those cases MD5 and SHA-1 cannot exclude that a second file exists that carries the same digest and says something else. The 2017 SHA-1 collision is exactly such a pair, two documents that display differently and share one digest. A SHA-2 digest such as SHA-256 is accepted by NIST for every hash application, collision resistance included. Recording a SHA-256 value beside the MD5 or SHA-1 value closes this question for the future, and where only MD5 or SHA-1 was recorded and the origin of a file is disputed, the court should know that the digest does not answer it.
C. Time and Origin
A digest proves that two sequences of bits are the same from the moment it was computed. It says nothing about what happened before. The moment the law protects is the seizure, so a digest first computed later, in a laboratory, proves the laboratory's copy and not the state of the device when it was taken, unless the seizure record links the two. Nor does a digest say who created, edited or placed the data. Origin is a question for the content itself, its metadata, the system's logs and the chain of custody, and an expert who answers it must explain how, as Article 67 requires.
VI. What the Record, the Report and the Court Should State
From the statute and the science, without any new legislation:
- The digest is computed at seizure, on the full backup, and written into the seizure record that Article 134(4) requires to be signed.
- The record names the algorithm, and a SHA-2 digest stands beside any MD5 or SHA-1 value.
- The copy given to the suspect carries the same digests, so that the defense can verify the prosecution's copies independently.
- The expert report states which question each conclusion answers: the identity of a copy, the exclusion of a prepared twin, or the origin of the data, and on what basis.
- When the origin of a file is disputed, the court does not treat a matching digest as an answer, and when only the identity of a copy is disputed, it does not treat a broken collision property as a reason to doubt it.
VII. Conclusion
Article 134 of the Code of Criminal Procedure secures digital evidence by fixing the moment of seizure and giving the defense its own copy of what was fixed. The hash value is the link between that moment and every later copy, and it is a strong link for the question it was made for. MD5 and SHA-1 have lost collision resistance, while their second-preimage resistance is not recorded as broken, so a digest recorded at seizure still proves that a copy is unchanged, while it can no longer exclude a twin prepared in advance. No digest, of any strength, speaks to the time before it was computed or to the origin of the data. A record that states its algorithms, a report that says which question it answers, and a court that asks which property its inference needs leave the number to prove what it can, and nothing more.
Notes
Attorney at law, registered with the Istanbul Bar, in the legal profession since 2015, LLB of Uludağ University Faculty of Law. A software developer since the MS-DOS years, working with machine learning at code level (g.dev/serka). ORCID: 0009-0003-5903-0220. E-mail: skara@serkankara.av.tr. ↑
Karen Kent, Suzanne Chevalier, Tim Grance and Hung Dang, Guide to Integrating Forensic Techniques into Incident Response, NIST Special Publication 800-86, August 2006, section 3.1.2, doi.org/10.6028/NIST.SP.800-86. ↑
Code of Criminal Procedure No. 5271 (Ceza Muhakemesi Kanunu) of December 4, 2004, Official Gazette of December 17, 2004, No. 25673, Article 134(3) and (4). ↑
Regulation on Judicial and Preventive Searches (Adli ve Önleme Aramaları Yönetmeliği), Official Gazette of June 1, 2005, No. 25832, Article 17, the fourth paragraph as amended in the Official Gazette of April 29, 2016, No. 29698. ↑
Code of Criminal Procedure No. 5271, Articles 67(1), 206(2)(a) and 217. ↑
Quynh Dang, Recommendation for Applications Using Approved Hash Algorithms, NIST Special Publication 800-107 Revision 1, August 2012, section 4.1, doi.org/10.6028/NIST.SP.800-107r1. ↑
Same, section 4.1. ↑
Xiaoyun Wang and Hongbo Yu, "How to Break MD5 and Other Hash Functions", EUROCRYPT 2005, abstract, iacr.org/archive/eurocrypt2005. ↑
S. Turner and L. Chen, Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms, RFC 6151, March 2011, sections 1, 2.1 and 2.2, rfc-editor.org/rfc/rfc6151. ↑
Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini and Yarik Markov, "The First Collision for Full SHA-1", IACR Cryptology ePrint Archive 2017/190, abstract, eprint.iacr.org/2017/190. ↑
Gaëtan Leurent and Thomas Peyrin, "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust", full version of the paper published at USENIX Security 2020, IACR Cryptology ePrint Archive 2020/014, abstract, eprint.iacr.org/2020/014. ↑
Elaine Barker and Allen Roginsky, Transitioning the Use of Cryptographic Algorithms and Key Lengths, NIST Special Publication 800-131A Revision 2, March 2019, section 9 and Table 8, doi.org/10.6028/NIST.SP.800-131Ar2. ↑
NIST, "NIST Retires SHA-1 Cryptographic Algorithm", December 15, 2022, nist.gov (accessed October 20, 2026). ↑
NIST, Secure Hash Standard (SHS), FIPS PUB 180-4, August 2015, doi.org/10.6028/NIST.FIPS.180-4. ↑