Verify before you trust.

An onion address is derived from the service's public key. A network attacker cannot impersonate a correct address, so the entire risk sits in how you came by the address in the first place.

Read it here, then read it again on docs.guardtalk.io and on guardtalk.io. Compare all three character by character. Onion addresses are long and deliberately unmemorable, and a substituted one is designed to survive a glance.

Never accept an address from a search result, a forum post, a message or a code someone scanned for you. Those are the delivery paths a substituted service needs, and they are cheaper to attack than the service itself.

Fetch two small files from the releases onion before you fetch anything large: SHA256SUMS and the detached signature over it. Fetch both in the same session, over Tor.

Verify the signature against the fingerprint you already held before you arrived. Compare the fingerprint, not the key file. A key delivered alongside the artefact it signs proves only that the same party produced both, which is exactly what an attacker can arrange.

This is the step that makes the next one meaningful. Without it, SHA256SUMS is a text file, and whoever can replace an image can replace the hash list too.

Compute the SHA-256 digest of every file you fetched, and compare each one to its line in the SHA256SUMS you verified in step two. The list is only worth comparing against because of that signature.

Compare the whole digest. A matching first eight characters is not a match, and a difference of one character is a total difference. Tools that print an abbreviated hash are convenient and are not what this step is for.

A file with no line in SHA256SUMS was not published by us. Do not flash it because the rest of the fetch looked correct. A mixed set is the shape a substitution takes when only one image was the target.

The trust anchor is avb_pkmd.bin: the public-key metadata for a key pair you generate and keep. You flash that blob into the bootloader's custom-key slot, flash the signed images, then lock the bootloader again.

Once locked, the bootloader refuses to boot an image your key did not sign. At boot the device reports the hash of the key it is enforcing. That hash has to be the hash of your key. The check is the whole reason the slot exists, and skipping it leaves you trusting whoever handed you the device.

This is the step whose workflow is not final. The state of the mechanism is alpha and the enforcement state per release has not been confirmed against the build tree.

This step does not exist yet. It is listed because its absence is a limit, and a limit belongs on the page rather than in a roadmap nobody reads.

When it exists, an independent builder takes the published source, builds it in the documented environment, and reaches images with the same digests. The source is taken at the release tag. That is what turns a hash from this is our artefact into this artefact is that source.

Until then, steps two and three prove provenance and say nothing about content. See the reproducible-build target for what it will mean and how it will be checked.