Skip to main content
← Back to lab
SEC401 - Data Security Technologies | Printable command sheet
Lab 4.1 - Hashing and Cryptographic Validation

Lab 4.1 - Hashing and Cryptographic Validation

Cryptography | SEC401 | Apr 2026

Used sha256sum and xxd to prove hashes are content-bound, generated an RSA 3072-bit GPG identity, produced a detached signature, imported Madison Jeffries's public key, flagged a tampered Bankruptcy.docx via a BAD signature from GPG, reviewed the metadata with exiftool, then restored a clean backup copy that verified cleanly.

Tools: sha256sum, xxd, sed, gpg (GnuPG 2.2.27), exiftool

Commands

1. Hash is content-based, not name-based

Created test-file.txt containing 'Hello'. Computed its SHA-256 (66a0...bb35f18), inspected the bytes with xxd (48 65 6c 6c 6f 0a = Hello\n), then renamed the file to renamed-file.txt. Re-hashed: the digest was identical. Hashes are computed over file contents, not metadata.

echo "Hello" > test-file.txt && sha256sum test-file.txt && xxd test-file.txt && mv test-file.txt renamed-file.txt && sha256sum renamed-file.txt
echo "Hello" > file: write 6 bytes (Hello\n) to a file sha256sum: compute SHA-256 digest xxd: hex + ASCII dump mv: rename without changing contents

2. One-byte change, completely different hash

Used sed to change every H to h in place (a single-byte change: 0x48 → 0x68). Re-hashed: the digest went from 66a0...bb35f18 to 5891...6be03, no resemblance to the original. This is the avalanche property of SHA-256: small input changes produce massive output changes.

sed -i 's/H/h/g' renamed-file.txt && sha256sum renamed-file.txt
sed -i: edit file in place 's/H/h/g': substitute H with h, globally

3. Generate an RSA 3072 GPG key

Ran the interactive key generation wizard. Chose RSA and RSA (1), 3072-bit keysize, no expiration, identity sec401 <sec401@sans.org>. GPG generated primary signing/certification (SC) key and an encryption (E) subkey. Entropy-gathering prompt appeared twice because two primes needed to be generated.

gpg --full-generate-key
--full-generate-key: full interactive key generation (vs. quick-generate)

4. Inspect the keyring

Listed public and secret keys. pub rsa3072 2026-04-13 [SC] with fingerprint A2B39B421129567517A5ECEA9B00C9116C092134, trust [ultimate] because it's our own key, plus a matching [E] encryption subkey. The secret-keys listing shows the same fingerprint under 'sec' confirming we hold the private half.

gpg --list-keys && gpg --list-secret-keys

5. Sign a file with a detached ASCII-armored signature

Produced an external .asc signature for renamed-file.txt. Detached sigs are the pattern used for release artifacts: ship the file and the .asc alongside each other. Verified locally and GPG reported 'Good signature from sec401' with the full fingerprint.

gpg --sign --armor --output renamed-file.txt.asc --detach-sig renamed-file.txt && gpg --verify renamed-file.txt.asc
--sign: sign --armor: ASCII-armored output (.asc, not binary .sig) --detach-sig: signature in a separate file

6. Import a third-party public key

Imported Madison Jeffries's public key from the lab backup directory. Post-import, --list-keys shows two pubkeys: our own at [ultimate] trust and Jeffries's (D200...BD90, rsa4096) at [unknown] trust, which is the correct default — GPG doesn't extend trust just because you imported a key.

gpg --import /sec401/labs/4.1/backup/backup-jeffries... && gpg --list-keys

7. BAD signature: tamper detected

Verified a signed Bankruptcy.docx from mounted media. GPG reported 'BAD signature from Madison Jeffries'. Either the document or the signature file has been altered since it was signed. In a real workflow this is the point where you stop reading the file and escalate.

gpg --verify /media/sec401/CDROM/Bankruptcy.docx.asc

8. Surface metadata with exiftool

Pulled metadata off Bankruptcy.docx. ExifTool reported standard DOCX internals plus Application: Microsoft Office Word, Pages: 2, Total Edit Time: 2982555.3 days — an obviously bogus value that on its own is a tampering indicator. Metadata review complements the cryptographic signal: even without a signature, the edit-time field alone warrants investigation.

exiftool /media/sec401/CDROM/Bankruptcy.docx

9. Restore from backup, re-verify

Copied the signature backup to the lab folder. First verify attempt passed the .docx instead of the .asc (GPG rejected with 'no valid OpenPGP data found'). Re-ran against the .asc and GPG confirmed 'Good signature from Madison Jeffries' with a GPG WARNING that the key is not certified with a trusted signature — expected, because we haven't signed Jeffries's key with our own to extend trust.

cp /media/sec401/CDROM/Bankruptcy.docx.asc /sec401/labs/4.1/backup/ && gpg --verify /sec401/labs/4.1/backup/Bankruptcy.docx.asc

Key Findings

  • SHA-256 is content-bound; renaming a file does not change its hash
  • Single-byte edits produce avalanche-level hash changes
  • RSA 3072 is the modern GPG default (2048 is no longer recommended)
  • Detached .asc signatures are the preferred distribution format
  • Bankruptcy.docx on the lab media fails signature verification (tampered)
  • Bankruptcy.docx backup copy verifies cleanly (known-good version)
  • exiftool's 'Total Edit Time: 2982555.3 days' is a tampering red flag on its own

Security Controls

  • File integrity monitoring (hash-based)
  • Code and document signing (GPG, Sigstore, cosign)
  • Artifact verification in CI/CD pipelines
  • Key management and rotation (HSMs, hardware keys)
  • Trust model enforcement (--trusted-key, --trust-model)
  • Metadata-based tamper indicators (exiftool, oletools)