SECURE DELIVERY
OPENPGP ENCRYPTION TOOLKIT
gpg-tools/ inside the source archive.Contacting FSG-A
FSG-A accepts contact only via PGP-encrypted email. There is no public phone number, no unencrypted email address, and no contact form. This is a deliberate operational-security choice: the author lives in a combat zone, works on systems that affect peer-adversary capabilities, and accepts correspondence only through channels where authentication and confidentiality are cryptographically enforced.
gpg --keyserver keys.openpgp.org --recv-keys B8922A94E35687EFA78F83BC0D0D7A5C62CD468CVerify the fingerprint independently before trusting the key. A fingerprint published on a single website is not a root of trust — cross-reference it against any other channel where FSG-A is verifiable (signed commits, prior correspondence, in-person exchange). If a keyserver returns a key whose fingerprint does not match the one above, do not use it.
To send encrypted email to FSG-A, fetch the key using the command above, write your message, and encrypt it with gpg --encrypt --recipient B8922A94E35687EFA78F83BC0D0D7A5C62CD468C. Deliver the resulting .asc or .gpg file through any channel you prefer — the ciphertext is safe to transmit over unencrypted email, file-sharing services, or messenger apps. Only the holder of the corresponding private key can decrypt it.
Why OpenPGP
Försvarsmakten, FMV, and FOI already use OpenPGP-compatible tooling for secure exchange of unclassified-but-sensitive material. Choosing a standard that evaluators already trust means FSG-A deliveries can be opened with existing workflows — no new software to approve, no new training, no vendor lock-in. OpenPGP has three decades of cryptanalytic scrutiny and is governed by an open IETF standard (RFC 4880bis), which makes it the natural choice when the delivery chain includes government evaluators.
Asymmetric encryption means each recipient holds their own private key and publishes a corresponding public key. You encrypt to the recipient's public key; only their private key can decrypt. This eliminates the classic "how do we share the password" problem that plagues symmetric-key systems. It also composes cleanly with multiple recipients — the same ciphertext can be decrypted by any of several named recipients independently.
Toolkit Contents
FILES IN tools/ (shipped inside fsga-wiki-src.zip)
fsga-gpg-setup.pyfsga-gpg-encrypt.pyfsga-gpg-decrypt.pytest_gpg_toolkit.pyREADME-GPG.mdCryptographic Properties
The toolkit does not invent new cryptography. It delegates all cryptographic operations to GnuPG (version 2.2 or later), which implements RFC 4880-compliant OpenPGP. Session keys for bulk encryption use AES-256 in CFB mode. Session keys themselves are wrapped in either RSA-4096 (legacy-compatible) or Curve25519 / Ed25519 (modern elliptic-curve, preferred for new keys). Message authentication uses modification detection codes (MDC) to detect tampering, and optional digital signatures provide non-repudiation.
SECURITY PROPERTIES
Workflow — End-to-End Delivery
The complete delivery workflow from FSG-A to a Försvarsmakten evaluator proceeds as follows. The sender (FSG-A operator) and recipient (evaluator) each run their half of the workflow on their own machine. No secret material traverses the network in plaintext.
#!/bin/bash
# ─── ONE-TIME SETUP (sender) ────────────────────────────────────
gpg --full-generate-key # Choose RSA 4096 or Curve25519
python3 gpg-tools/fsga-gpg-setup.py --audit # Verify keyring hygiene
# ─── ONE-TIME SETUP (recipient, e.g. FMV evaluator) ─────────────
gpg --full-generate-key
python3 gpg-tools/fsga-gpg-setup.py --export-public \
"evaluator@fmv.se" --out fmv-evaluator.asc
# Send fmv-evaluator.asc to FSG-A via any channel
# ─── FSG-A IMPORTS RECIPIENT'S PUBLIC KEY ──────────────────────
gpg --import fmv-evaluator.asc
gpg --fingerprint "evaluator@fmv.se"
# VERIFY fingerprint with recipient by phone/signal/in-person
# ─── FSG-A ENCRYPTS + SIGNS ─────────────────────────────────────
python3 gpg-tools/fsga-gpg-encrypt.py --batch \
--recipient "evaluator@fmv.se" \
--sign "fsga-operator@example.com"
# Output: fsga-code-v2.zip.gpg, fsga-wiki-dist.zip.gpg,
# fsga-wiki-src.zip.gpg — safe to send via email/cloud/USB
# ─── RECIPIENT DECRYPTS + VERIFIES ──────────────────────────────
python3 gpg-tools/fsga-gpg-decrypt.py --input fsga-code-v2.zip.gpg
# GPG automatically verifies the signature; if invalid, warns loudly
Stress Test Coverage
The toolkit ships with test_gpg_toolkit.py — a 20-test stress suite that exercises every critical path. The suite generates throwaway 2048-bit RSA test keys in an isolated temporary directory and destroys them after the run; the user's real keyring is never touched.
STRESS TEST — 20 SCENARIOS (all passing)
Boundaries — What the Toolkit Does Not Do
Three explicit non-goals limit the toolkit's scope. First, the toolkit does not transmit files. Encryption is local; the sender chooses the transport channel (email, cloud upload, USB drive, physical delivery). Second, the toolkit does not handle your passphrase. gpg-agent and pinentry prompt you directly when your private key needs to be unlocked; no FSG-A script ever sees, logs, or stores the passphrase. Third, the toolkit does not delete plaintext. After verifying that the encrypted output works, the operator manually decides when and how to destroy plaintext originals according to their organisation's data-handling policy.
Hardware Token Support
Operational deployments should use hardware-backed keys rather than software keys stored on disk. A hardware token like YubiKey 5, Nitrokey 3, or a Försvarsmakten-issued smartcard holds the private key on the device itself — the key material never exists in computer memory. Losing a laptop without the token gives an attacker nothing; losing the token requires the attacker to also know the PIN, and after three incorrect PIN entries the key is permanently locked. This is the recommended deployment model for any FSG-A operator who carries operational material on a mobile device.
#!/bin/bash
# Generate key directly on hardware token (YubiKey / Nitrokey / FM smartcard)
gpg --card-edit
gpg/card> admin
gpg/card> generate
# Follow prompts — key never leaves the token
# Verify token holds the key:
gpg --card-status
# Export public key for distribution:
gpg --armor --export > operator-hardware.asc
Integration With Wiki Deliverables
The three main FSG-A archive files can all be encrypted to one or more named recipients using a single batch command. The files are fsga-wiki-dist.zip (the live website), fsga-wiki-src.zip (buildable source including the SDK and validators), and fsga-code-v2.zip (the standalone code bundle with SDK, stress tests, and Fischer 26/26E capability verification). Each corresponds to a different evaluation need — the dist archive serves documentation reviewers, the src archive serves build-and-test evaluators, and the code archive serves engineering acceptance.
Related Chapters
Sources
Standards referenced: RFC 4880 OpenPGP Message Format (IETF); RFC 6637 Elliptic Curve Cryptography in OpenPGP; GnuPG manual (GnuPG project documentation). The toolkit itself is CC BY-SA 4.0, built on top of GnuPG (GPL) and python-gnupg (BSD). Cross-references within the FSG-A wiki — source archive download: download.html; SDK specification and structure: fischer26e-sdk.html; cryptographic primitives used inside the SDK itself (MAVLink HMAC, HKDF daily rotation, DRAM scrubber): cybersecurity-mavlink.html, lisa26-captured-drone.html.