How to prove a text message was not edited

You handed over a file of text messages, or you are about to, and somebody has suggested that you could have changed them. Maybe they said it outright. Maybe it arrived as a question about whether the export is complete. Either way the conversation has moved off what the messages say and onto whether the file can be trusted at all.

That is a different problem from producing the messages, and almost nothing sold for producing messages actually solves it. This page explains what would settle the question, in plain terms, and how to check a file yourself.

The question behind the question

When somebody doubts an export, they are usually asking one of three separate things, and the three have very different answers. Sorting out which one you are facing saves a great deal of wasted effort.

• Did you edit this file after you made it? This is a question about the file, and it is the one that can be answered cleanly.
• Did you leave things out? This is a question about selection, and no seal or signature addresses it.
• Did the messages really say this in the first place? This is a question about the original device, and it is answered by the device, not by the export.

Most products that mention authenticity are quietly answering only the first question, which is fine, as long as nobody is told it covers all three. Be clear with yourself about which one is actually in dispute before you go looking for a tool.

Why a file date proves almost nothing

The first instinct is to point at the file. It says it was created on the twelfth, so it was created on the twelfth. Unfortunately the modification date on a file is written by the computer that holds it, and it is trivially changeable. On a Mac a single command line instruction sets it to any date you like. Nothing about that is exotic or requires special software.

The same applies to a PDF that prints a date in its own header, or a report that states when it was generated. That date is text the program chose to write. It is a claim by the thing being questioned, which is the one kind of evidence that carries no weight in a dispute about trust.

A record that vouches for itself is not proof. The whole question is whether to believe it, and repeating the claim inside the file does not help.

What a hash actually does

A cryptographic hash is a fingerprint of a file. Feed the file through a standard function such as SHA-256 and you get a fixed string of characters. Change one byte anywhere in the file, including a single character in a single message, and the resulting string is completely different. There is no known way to work backwards, and no practical way to construct a different file that produces the same fingerprint.

That gives you something genuinely useful: a short value that stands in for the whole file. If you have the fingerprint from before, and you recompute it now, matching values mean the file has not changed by so much as a comma.

The catch is in those four words, from before. A fingerprint on its own only proves the file matches itself. If you generate the file and the fingerprint at the same moment, you have proved nothing to anybody, because you could have edited the messages first and hashed the edited version. The hash needs to be pinned to a moment in time by somebody who is not you.

The part that does the work: an independent timestamp

There is a long established standard for this, RFC 3161, and it exists precisely because self-asserted dates are worthless. It works like a postmark.

1. Your computer calculates the fingerprint of the export.
2. It sends only that fingerprint to an independent timestamp authority. The messages themselves never leave your machine, because the authority does not need them and never sees them.
3. The authority signs a statement to the effect that it saw this fingerprint at this date and time, using its own certificate.
4. That signed statement travels with your file.

The result is a claim that does not depend on believing you, and does not depend on believing the software vendor either. An outside organisation with its own reputation has attested that this exact file existed at that moment. If the file is altered afterwards, the fingerprint no longer matches and the mismatch is obvious to anybody who checks.

This is the difference between a report that says when it was made and a record that can be tested. The first asks for trust. The second offers a check.

A provenance page is not the same thing

Several tools now include a page in their output listing where the data came from: the source filename, a processing time, how many messages were counted. This is a reasonable thing to include and it helps a reader understand what they are looking at.

It is worth being clear about what it is, though. Every line on that page was written by the same program that wrote the messages, at the same moment, with no outside party involved. If the underlying data had been changed before processing, the provenance page would faithfully describe the changed data. It documents the process. It does not independently attest to anything, and it will not answer somebody who has already suggested the file was altered.

Both things can be useful in the same document. Just do not reach for the one that documents when you need the one that attests.

How to check a sealed export yourself

If somebody hands you a file and says it is sealed, you should be able to test that claim without asking them for anything and without taking any vendor’s word for it. Here is how, using tools already on your Mac.

1. Open Terminal, from Applications and then Utilities.
2. Type shasum -a 256 followed by a space, then drag the file onto the Terminal window so the path fills in, then press Return.
3. You get a long string of letters and numbers. That is the file’s fingerprint, computed by your own machine with software that came with the operating system.
4. Compare it against the fingerprint recorded in the seal. If the two match, the file is byte for byte the one that was sealed. If they differ at all, something changed after sealing.

Nothing in that sequence involves trusting the company that produced the file. That is the point. A verification route that only works through the vendor’s own website is a weaker claim than one you can reproduce with a standard command.

What none of this can do

Worth saying plainly, because the gap between these two ideas is where people get caught out.

• A seal does not prove the conversation was complete. If messages were deleted from the phone before the export was made, the export is a faithful record of what was left.
• A seal does not prove who typed anything. It covers the file, not the human at the keyboard on the day.
• A seal does not prove the messages were true. People write false things in texts, and a timestamp on the file does not comment on that.
• A seal cannot be applied retroactively in any meaningful way. Sealing a file today attests to today, not to the year the messages were sent.

What it does cover is narrow and it is the thing actually in dispute when somebody says you changed the file. Narrow and honest beats broad and unprovable, particularly in a setting where somebody is looking for a reason to doubt you.

Where Message Archive fits

Message Archive keeps your iMessage and SMS history in a searchable archive on your own Mac, and its exports carry a cryptographic seal with an RFC 3161 timestamp from an independent authority. Anyone can check one at our verify page, free, with no account and without sending us the file.

The honest limits: it runs on macOS only, it is $47 a year per Mac, and it cannot recover messages that are already gone from every source on your machine. If your messages were pruned two years ago and no backup holds them, no archiving tool brings them back, and you should be suspicious of anything that says otherwise.

It is also worth knowing that the other tools in this category are not doing nothing here. iMazing, for one, computes SHA-256 checksums and can sign exported PDFs, and markets that for chain of custody. The difference worth understanding is that its signature uses a certificate the user selects or creates, with no independent timestamp authority involved, and signing sits on its Business tier. If you already own it, use what it gives you. The narrower thing we add is the outside attestation and a free way for the other side to check it.

The short version

• Work out which of the three questions is actually being asked. Only one of them is about the file.
• A file date proves nothing. It is set by the computer holding the file and is trivially changed.
• A hash is a fingerprint that catches any change, but on its own it only proves the file matches itself.
• An RFC 3161 timestamp pins that fingerprint to a moment, attested by somebody who is not you and not the vendor.
• A provenance page documents a process. It does not attest to anything independently.
• Test any sealed file yourself with shasum -a 256. If you can only verify through the vendor, that is a weaker claim.