SHA-256

How it works

The sender publishes the 64 hex characters. The recipient recomputes them. A match means the bytes match. SHA-256 is the current default. MD5 is not, for adversarial cases. The hash must travel on a channel the attacker does not control if the threat is substitution.

A 4 GB firmware file's SHA-256 is in the same mail as the link, and also on a site reached by a pinned bookmark. The download matches both. A mirror that matched the mail and not the site is rejected.

How it differs

SHA-256 is not encryption. It does not hide the file. It names it.

Hashing a decompressed copy against a hash of the gzip will fail.

Hash the same bytes you ship.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For sha 256, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive sha 256 files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.