GPG Keyring Workbench - Shield House

Mission 1 — Generate your GPG key pair

Every GPG user starts by generating a key pair. The public key is freely shared so others can encrypt to you or verify your signatures. The private key stays secret forever. The key's fingerprint (a hash of the public key material) lets others confirm they have your genuine key out-of-band.

Objective: generate a real RSA-OAEP-2048 (encryption) key pair and an RSA-PSS-2048 (signing) key pair via the browser's crypto.subtle, then read off the fingerprint that was produced from your public key material. Proceed to Mission 2 once keys are ready.

$ gpg --full-generate-key
Kind: RSA and RSA / Key size: 2048 / No expiration

Note: this workbench models the GPG workflow using the browser's real Web Crypto API (RSA-OAEP + RSA-PSS) for all cryptographic operations. It does not parse or produce RFC 4880 binary OpenPGP packets — the ASCII-armor blocks are illustrative wrappers around real key material and real ciphertext/signatures.

No keys generated yet

Public key fingerprint (SHA-256 of SPKI export)

key fingerprint will appear here after generation

Public key (ASCII-armor excerpt)

-----BEGIN PGP PUBLIC KEY BLOCK----- (generate to reveal)

In real GPG: gpg --fingerprint you@example.com shows your fingerprint. You publish this on your website, business card, or keyserver so contacts can verify they have the genuine key.

Mission 2 — Encrypt to a recipient & decrypt

Alice wants to send Bob a classified message. She encrypts it with Bob's public key. Only Bob's private key can decrypt it — not Alice's, not an eavesdropper's. You'll play both roles to complete the round trip.

Objective: (1) generate Bob's key pair, (2) encrypt Alice's message with Bob's public key (real RSA-OAEP), (3) decrypt with Bob's private key and confirm the round-trip. A wrong or missing key must fail to decrypt.

$ gpg --encrypt -r bob@shield.ops classified.txt
$ gpg --decrypt classified.txt.gpg

Bob has no key yet

Alice (sender)

encrypts with Bob's public key

Her private key is not involved in encryption

Bob (recipient)

decrypts with his private key

Bob's fingerprint — generate to see

Alice's message to Bob

Ciphertext (ASCII-armor style)

-----BEGIN PGP MESSAGE----- (encrypt to produce ciphertext)

Decrypted plaintext

decryption output will appear here

Key rule: encrypt with the recipient's public key, decrypt with the recipient's private key. Alice's private key is irrelevant here. The reverse direction (Bob to Alice) would use Alice's public key instead.

Mission 3 — Sign a message & catch a tampered one

Your Mission-1 keys include an RSA-PSS signing key pair. Sign a field report with your private signing key. Anyone holding your public key can verify the signature proves it came from you and was not altered. Then the lab will present a tampered version — the same signature must now report INVALID.

Objective: (1) sign the field report, (2) verify the genuine report (must be VALID), (3) verify the tampered report (must be INVALID). Both steps are required to complete the mission.

$ gpg --sign report.txt
$ gpg --verify report.txt.gpg # VALID
$ gpg --verify tampered.txt.gpg # INVALID

Field report (message to sign)

SITREP 2024-06-28T0300Z: perimeter clear, all checkpoints secured, no contact. — Operator Hex

Complete Mission 1 first to get your signing key

Digital signature (hex)

sign the report to produce a signature

Signing rule: sign with your private key, verify with your public key. The signature covers the message content; one changed byte flips VALID to INVALID. Tie the public key to a CA-issued certificate and you also gain non-repudiation.

Mission 4 — Key trust & fingerprint verification

A contact named "Agent Morse" sends you their public key over email. Without verification, you cannot know it is genuine — an adversary could substitute their own key (MITM). You call Agent Morse on a secure line and compare fingerprints character-by-character. Only if they match exactly is the key authentic. You then assign a trust level, which determines how GPG weighs their key signatures in the web of trust.

Objective: (1) generate Agent Morse's key (simulating them sending you their public key), (2) compare the fingerprint you see on the key against the one "Morse reads to you on the phone" (the lab shows both; confirm they match), (3) assign the correct trust level for a trusted colleague you have verified in person.

$ gpg --fingerprint morse@shield.ops
$ gpg --edit-key morse@shield.ops
> trust # assign trust level

Waiting for Morse's key

Key on your keyring

from gpg --fingerprint

generate Morse's key to see fingerprint

Morse on the phone

out-of-band verification channel

Morse reads you the fingerprint...

Assign trust level to Agent Morse

Unknown (0) Nothing known about key owner's verification habits

None (1) Known to improperly validate keys — actively distrust

Marginal (2) Probably validates keys before signing; partial confidence

Full (3) Definitely validates carefully; you fully trust their judgment

Ultimate (4) Reserved for your own keys only

GPG web-of-trust rule: 1 fully-trusted signature validates a key; 3 marginally-trusted signatures also validate it. Chains can be at most 5 levels deep. ultimate is reserved for keys you own — never assign it to a contact.

GPG Keyring Certified

You generated real asymmetric keys, encrypted and decrypted a message using the correct public/private key roles, proved authenticity with a digital signature, caught a tampered message, verified a contact's fingerprint out-of-band, and assigned an appropriate web-of-trust level. Those four operations are the complete GPG operational workflow.

Asymmetric encryption · RSA-OAEP Digital signatures · RSA-PSS Fingerprint verification Web of Trust · OpenPGP SY0-701 1.4 · RFC 4880