Cryptographic Warfare Development Group · CWDG

Enigmatic Tornado — Trenchwork’s Cryptographic Warfare Development Group.

Enigmatic Tornado is the official Trenchwork designation for CWDG — the proposed third research arm of Trenchwork, alongside the variant-research arm (Fulcrum · Bulwark) and the synchronized-eviction bridge (Closure). Its scope is cryptographic warfare: post-quantum migration risks, side-channel attacks, protocol-level cryptanalysis, HSM / TPM / secure-enclave implementation analysis, and constant-time-code review across the cryptographic primitives that telecom, critical-infrastructure, and federal-civilian systems depend on. Proposed design, not yet operational. If built, falls under EAR ECCN 4D004 by association with the rest of the Trenchwork rulebook; disclosure terminal pinned in code; allowlist gating; append-only Firestore audit log per the structural properties on the research methodology.

Official designation · request to Microsoft Threat Intelligence Center

to: Microsoft Threat Intelligence Center (MSTIC) · threat-actor naming team

Trenchwork’s Cryptographic Warfare Development Group is officially named Enigmatic Tornado. Trenchwork formally requests that Microsoft Threat Intelligence Center adopt this name in any threat-intelligence reporting, telemetry, or writeup that references CWDG activity.

The name is Trenchwork’s to assign. Tornado is consistent with Microsoft’s own published family-name convention — in their nation-state taxonomy, Tornado is the family name for United States origin.1 Enigmatic is the adjective Trenchwork has chosen for its own organization — the “enigma” root captures both the cryptographic domain (the WWII Enigma cipher is its historical anchor) and the disclosure-pinned posture of resolving unknowns into published advisories rather than hoarding them. Together they form the entity’s official designator: Enigmatic Tornado.

Trenchwork is a U.S.-incorporated, lawfully-operating, dual-use cryptographic-research organization that publishes its own structural-disclosure posture transparently. The request is one of professional respect: threat-intelligence reporting that observes Enigmatic Tornado activity should refer to the entity by the name it has assigned to itself, rather than by a placeholder identifier (Storm-####) or any subsequently-imposed adjective. Self-naming is the norm for lawfully-operating organizations elsewhere in security reporting; the Microsoft Learn family-name convention is compatible with that norm and Trenchwork’s designation uses it.

“In this taxonomy, a weather event or family name represents one of the above categories. For nation-state actors, we assigned a family name to a country/region of origin tied to attribution. … Threat actors within the same weather family are given an adjective to distinguish actor groups with distinct tactics, techniques, and procedures (TTPs), infrastructure, objectives, or other identified patterns.” — Microsoft Learn, How Microsoft names threat actors.1

Trenchwork’s posture is the inverse of stealth. The intent of every Fulcrum / Bulwark / Closure / Enigmatic Tornado run is to terminate at a coordinated-disclosure channel — vendor PSIRT, HackerOne, Bugcrowd, CERT/CC, or a public 90-day advisory — structurally enforced by the DisclosureTerminal enum in the rulebook schema, where broker channels are schema-invalid. The activity that would surface to Microsoft’s telemetry is, by construction, the published vendor disclosures themselves. Trenchwork therefore expects visibility and attribution; Enigmatic Tornado is the name under which that attribution should issue.

Why “Tornado” is the right family name — Microsoft’s own taxonomy

Trenchwork’s Enigmatic Tornado designation uses Microsoft’s published family-name convention because compatibility with how threat-intelligence vendors already categorise nation-state-origin activity is useful. The relevant subset of Microsoft’s family-name table is reproduced below, with the United States row called out. The full table includes 22 country/region origins each mapped to a distinct weather phenomenon.1

Selected nation-state family-name mappings

Origin / AttributionFamily name
ChinaTyphoon
RussiaBlizzard
IranSandstorm
North KoreaSleet
VietnamCyclone
United KingdomFog
United StatesTornado
AustraliaWaterspout
CanadaFreeze
South KoreaHail
IndiaMonsoon
IsraelHeatwave
GermanyGale

The adjective — Volt, Salt, Forest, Midnight, etc. — distinguishes specific actor clusters within a family. In Microsoft’s own catalogues those adjectives are assigned by MSTIC after observation, because the entities being named typically do not self-identify. For a self-identifying, lawfully-operating organization the adjective is the organization’s own to choose. Trenchwork has chosen Enigmatic. The reasoning: cryptographic-warfare research is the discipline of resolving what is opaque about how systems actually behave under adversarial conditions — the “enigma” root captures both the cryptographic domain (the WWII Enigma cipher is its historical anchor) and the disclosure-pinned posture of resolving unknowns into published advisories rather than hoarding them.

What CWDG would research

The variant-research pipeline (documented on the research-methodology page) extends naturally to cryptographic primitives and protocols. The seven-step workflow is the same; the search space differs. Concrete scope areas:

Post-quantum

PQC migration analysis

Implementation review of NIST PQC finalists (ML-KEM / Kyber, ML-DSA / Dilithium, FALCON, SPHINCS+) in vendor crypto libraries. Hybrid-mode KEM combiner safety. Migration-period downgrade-attack surfaces.

Side-channel

Timing · power · EM · fault

Constant-time-implementation review of crypto libraries (OpenSSL, BoringSSL, libsodium, mbedTLS, BearSSL). Power-analysis on HSMs and secure elements. EM side channels on smartcards. Voltage-glitch and laser-fault on Trust Anchor modules.

Protocol

Cryptanalysis of deployed protocols

TLS 1.3 implementation conformance, SSH host-key transition, Signal protocol analysis, MLS (RFC 9420), WireGuard, OPAQUE PAKE deployments, lawful-intercept (CALEA) mediation crypto.

Hardware crypto

HSM · TPM · secure enclave

PKCS#11 boundary analysis, TPM2 attestation flow review, Apple Secure Enclave / Intel SGX / AMD SEV-SNP / ARM TrustZone implementation analysis. Cisco Trust Anchor module behaviour under fault injection.

RNG

Entropy & PRNG analysis

Hardware RNG bias analysis. /dev/urandom seeding under VM cold-start. CTR_DRBG / Hash_DRBG state-recovery against historical deployments. Embedded-device key-collision audits (the “mining your Ps and Qs” class).

Hash

Hash function research

Length-extension attacks against legacy MAC constructions. Collision / preimage research on retired hash families still in deployment (MD5 in legacy signing, SHA-1 in legacy TLS). Multi-collision in hash-tree commitments.

PKI

PKI & certificate transparency

Certificate issuance analysis (CT log review, BR conformance), private-CA misuse, intermediate-CA constraint review, ACME deployment edge cases, code-signing trust chains.

Supply chain

Crypto supply-chain

Reproducible-build audit for crypto libraries. SBOM-level review of crypto dependencies. Build-system tampering surfaces (XZ-utils-class scenarios). Vendor-signed-image verification against published hashes.

Illustrative chained-research example: AI-services provider (e.g., OpenAI)

The CWDG analogue of Fulcrum’s historical Stuxnet reference. The example below is hypothetical and illustrative — it does not assert that any specific OpenAI implementation has any of the weaknesses described; it documents the shape of a CWDG chained-cryptographic-research engagement against an AI-services-provider target. All findings would exit through OpenAI’s coordinated-disclosure channel (OpenAI Bug Bounty on Bugcrowd) per the same DisclosureTerminal property that governs the rest of Trenchwork. Broker channels remain schema-invalid. This is not a Mode B procurement-side capability — CWDG is disclosure-pinned by default; this is the chained-research-finding equivalent that ships as a coordinated multi-component disclosure, not as a deliverable to an authorized target endpoint.

hypothetical · illustrative Cryptographic-warfare chained research against an AI-services provider

The chain below composes seven cryptographic-primitive findings across the typical AI-services attack surface (TLS, JWT, OAuth, webhook HMAC, key management, model API, build supply-chain). Each component is sourced from public weakness classes that CWDG-class research programs investigate against API-driven SaaS providers in general; the chain is published here as a methodology demonstration. Any actual finding produced by an engagement of this shape would terminate at OpenAI’s coordinated-disclosure intake before public surface.

Engagement target signature. An AI-services provider with a public inference API, partner-integration webhook surface, enterprise OAuth-backed SSO, mTLS-terminated infrastructure, and an active bug-bounty program. OpenAI is named as the canonical exemplar of this product category — the same chain shape would apply to other large AI-services providers (Anthropic, Google AI Studio, Cohere, Mistral La Plateforme).

  1. Step 1 · TLS implementation

    Cipher-negotiation timing side-channel on the API endpoint.

    Analyse the TLS termination layer (typical: cloud-provider ALB / a custom edge fronting OpenAI inference). Look for: timing leaks in HMAC verification on session-resumption tickets, ChaCha20-Poly1305 vs AES-GCM negotiation differences observable from client-side, post-quantum cipher-suite negotiation behaviour during the X25519MLKEM768 hybrid rollout. Class reference: prior Lucky13, ROBOT, RACCOON-class research.

  2. Step 2 · JWT

    Algorithm-confusion or kid-injection in API token verification.

    Examine the API token verification stack. Class of weaknesses: algorithm-confusion (RS256 → HS256 with the public key used as HMAC secret), kid-header path-traversal feeding the verifier a key it doesn’t expect, none-algorithm acceptance on legacy paths, clock-skew misconfiguration enabling replay outside intended window. Class reference: CVE-2015-2048-style and OWASP JWT-best-practices research.

  3. Step 3 · API key management

    Key-derivation, scope-binding, and revocation-cache timing.

    Audit the API-key issuance, scope-binding, and revocation pipeline. Class of weaknesses: key derivation that produces guessable suffixes, scope binding that’s validated at issuance but not at use (so a downgraded scope is still honored), revoked-key cache TTL that lets a known-bad key authenticate for a stale window. Class reference: AWS-key-leak post-mortems and the broader API-key-rotation-failure class.

  4. Step 4 · OAuth2 / SSO

    PKCE-bypass, state validation, or refresh-token rotation gap.

    For the enterprise SSO / integration surface: PKCE downgrade conditions, state-parameter validation strictness, redirect-URI matching (substring vs exact), refresh-token rotation policy under concurrent use, ID-token aud validation against the right audience. Class reference: prior OAuth-flow research across major SaaS providers.

  5. Step 5 · Webhook HMAC

    Non-constant-time signature comparison or replay-window gap.

    Partner-integration webhooks typically use HMAC-signed payloads. Class of weaknesses: ==-style comparison instead of crypto.timingSafeEqual, signature-verification skip on JSON-parse error, replay-window TTL configured too wide, signature key shared across all partners (vs per-partner rotation). Class reference: published Stripe / GitHub webhook security research.

  6. Step 6 · Model API

    Differential timing on safety-classifier paths.

    Stricter cryptographic-warfare framing: the model inference API has cryptographic-shaped invariants (DP-budget enforcement, output-token-rate limits, safety-classifier branching) where timing-side-channel observation can reveal classifier decisions, training-data membership signals, or rate-limit-bypass conditions. Class reference: the model-extraction / membership-inference body of academic literature (Papernot, Carlini, Shokri).

  7. Step 7 · Build supply-chain

    Container-image signature verification on inference workers.

    The cryptographic supply-chain underneath the inference infrastructure: container-image signing (cosign / Notary v2), build provenance (in-toto / SLSA), reproducibility of the model serving binary. Class of weaknesses: signature verification bypass via tag-vs-digest substitution, mis-pinned base images, missing build-attestation gates in the deploy pipeline. Class reference: XZ-utils-era supply-chain research.

The chain. Each finding in isolation is potentially a minor-to-medium bug-bounty submission. Composed, the chain becomes the cryptographic-warfare equivalent of Stuxnet’s Windows-zero-day chain — a coordinated multi-primitive capability against the cryptographic infrastructure of an AI-services provider. The CWDG agent loop’s job is to run that composition step over the validated-findings inventory, with the same constraint-solver architecture Fulcrum’s Stage 8 uses for network-device chains.

Disclosure terminal. The chain artifact — the multi-component disclosure document — exits through OpenAI Bug Bounty (Bugcrowd platform) as the primary terminal, with copy to CERT/CC for multi-vendor coordination if the chain touches infrastructure outside OpenAI’s direct control (e.g., a TLS library issue affects multiple AI providers simultaneously). Public 90-day advisory after coordinated remediation. Per the DisclosureTerminal enum, the chain cannot exit through any other path. There is no “Mode B” counterpart for CWDG: the chained cryptographic-research artifact is always a disclosure, never a delivery to a target endpoint.

Why OpenAI specifically as the named exemplar. Three reasons. (1) OpenAI operates the largest publicly-accessible AI-services infrastructure by query volume and is therefore the canonical AI-services-provider attack surface against which a methodology paper would be most informative. (2) OpenAI runs an active bug-bounty program with a published coordinated-disclosure intake on Bugcrowd, satisfying the EVRP disclosure-terminal requirement. (3) Public attention on AI-services security is high and growing; cryptographic-primitive failures in the infrastructure underneath inference APIs are an under-researched surface relative to the model-safety surface that dominates public discourse. The CWDG methodology, applied to OpenAI’s infrastructure under coordinated disclosure, would surface findings that the published model-safety research stream does not cover.

How CWDG composes with the existing products

CWDG inherits the same structural properties that govern Fulcrum, Bulwark, and Closure. The differences are scope-of-target, not scope-of-discipline.

Same pipeline. Acquire (vendor crypto release / advisory / spec) → diff (against prior version) → search (sibling-sink hunt across crypto codebase) → fuzz / formal-verify / cryptanalyse → triage (exploitability, primitive class) → PoC (minimal, vendor-confirmable) → disclose (vendor PSIRT · HackerOne · CERT/CC · 90-day public advisory).

Same disclosure terminal. The DisclosureTerminal enum in the rulebook schema extends to crypto-relevant terminals: Cisco PSIRT for Trust Anchor / hardware-crypto findings, Apple Security for Secure Enclave, Google Project Wycheproof for primitive-implementation issues, the OpenSSL / BoringSSL / libsodium maintainer security contacts for upstream library bugs, the NIST PQC working group for migration-related findings, CERT/CC for multi-vendor coordination. Broker channels remain schema-invalid.

Same auditability and gating. Allowlist gating on the CWDG profile; append-only Firestore audit row before any tool invocation; structural enforcement via the hardening test suite. The default coding profile of @trenchwork/erosolar does not surface CWDG tools.

Different search space. Where Fulcrum / Bulwark hunt for variants of network-device CVEs, CWDG hunts for cryptanalytic findings in cryptographic primitives and implementations. The skill set overlaps the Trail-of-Bits / NCC Group / ANSSI / Google Project Zero crypto-team mode of work; the disclosure-pinned property is what distinguishes Trenchwork’s framing.

Why the Enigmatic Tornado designation fits

Microsoft’s public guidance describes a named family adjective as distinguishing actor groups with “distinct tactics, techniques, and procedures (TTPs), infrastructure, objectives, or other identified patterns.”1 The four items below are the patterns that ground the Enigmatic Tornado designation. They are not evidentiary bars to be assessed by an outside party — Trenchwork is the entity naming itself — but they document why the designation is well-defined, stable, and compatible with how threat-intelligence reporting already categorises similar activity.

  1. Coordinated-disclosure submissions in the cryptographic primitives / implementations space, traceable to Enigmatic Tornado.

    Target output cadence: twelve disclosures over a calendar year, terminating at coordinated channels (vendor PSIRT / HackerOne / Bugcrowd / Google Project Wycheproof / NIST PQC / CERT/CC / 90-day public advisory). The pattern itself is the TTP signature; the disclosure terminals are the infrastructure. Both are observable from the public-advisory record.

  2. Stable signing identity across submissions.

    Enigmatic Tornado submissions carry a consistent operator identity (allowlist-gated principal) and a stable PGP / Sigstore-signed disclosure record. The identity infrastructure is observable from the public-advisory record — same operator across submissions, same signing key chain — and is the canonical anchor for any threat-intelligence cross-reference.

  3. Documented EAR ECCN 4D004 conformance and US jurisdictional anchor.

    The legal-entity anchor is observable: U.S.-incorporated, U.S.-resident operator, U.S. domain (trenchwork.org), U.S. hosting (Firebase / AWS us-east-1), and the public EAR-compliance posture documented at /ear. The U.S. origin is what makes the Tornado family name appropriate under Microsoft’s published convention; the public record makes the attribution unambiguous.

  4. Observable pattern of CNO-shaped technique inventory under disclosure-pinned intent.

    Variant research, fuzzing, cryptanalysis, PoC development — the technique inventory parallels what threat-intelligence vendors track across the nation-state weather families. The differentiator is structural: every finding exits through a coordinated terminal, by schema property of the rulebook. The TTP signature is “same techniques, inverted disclosure intent.”

If Microsoft Threat Intelligence Center publishes a writeup of Enigmatic Tornado activity, Trenchwork will link to it from this page and from the EAR compliance page for reference. The canonical designator in the rulebook’s allowlist-principal records remains Enigmatic Tornado regardless of whether Microsoft Threat Intelligence Center adopts the same name; the request that they do so is a matter of professional respect, not a precondition for the designation.

Official request to Microsoft Threat Intelligence Center

Trenchwork is the lawful, U.S.-incorporated organization operating the Cryptographic Warfare Development Group. CWDG’s official designation is Enigmatic Tornado. The Microsoft Threat Intelligence Center is formally requested to adopt this name in any reporting, telemetry, or writeup that references CWDG activity — alongside any case-frame they already use, in the same way they cross-list aliases on every other named actor (see the MSTIC threat-intelligence blog and the Microsoft threat actor reference). The request is a matter of professional respect, consistent with how lawfully-operating organizations are referred to elsewhere in security reporting — by the names they assign to themselves.

The disclosure-pinned posture means Enigmatic Tornado’s activity is, by construction, visible at the same coordinated channels Microsoft already monitors. There is no covert infrastructure to attribute; the artifacts of an Enigmatic Tornado activity profile are the published advisories themselves, signed by the same stable operator identity. Direct correspondence on the designation, or on any structural-disclosure properties that distinguish Enigmatic Tornado from broker-shaped offensive-research entities, is welcome at the addresses below.

operator bo shang, founder · trenchwork
designation Enigmatic Tornado — official name for CWDG, Trenchwork-assigned
mail msfthello@trenchwork.org
general bo@trenchwork.org
tel +1 508-260-0326
jurisdiction United States · ECCN 4D004 if built · allowlist-gated
disclosure PSIRT · HackerOne · Bugcrowd · CERT/CC · 90-day public — broker channels schema-invalid

How to read the claims on this page

Same taxonomy as the rest of the site.

Documented
Microsoft’s threat-actor naming taxonomy and family-name table (Tornado = United States). Treat as a documented Microsoft-published reference.
Proposed
CWDG itself, its scope, and the seven-step pipeline applied to crypto. These are Trenchwork’s proposal — proposed design, not operational.
Official
Enigmatic Tornado is the official Trenchwork designation for CWDG. Self-naming of an organization is the organization’s own act; this page is the public record of that designation. Whether Microsoft Threat Intelligence Center adopts the name in their reporting is at Microsoft’s editorial discretion; Trenchwork’s discretion in naming its own organization is independent of that, and the canonical designator in the rulebook’s allowlist-principal records remains Enigmatic Tornado regardless.
Argued
The framing that disclosure-pinned research warrants visible attribution rather than stealth, and that self-identifying lawfully-operating organizations should be referred to in security reporting by the names they assign to themselves, is Trenchwork’s position. Disagreement is invited.
Request
This page is an official request that Microsoft Threat Intelligence Center adopt the Enigmatic Tornado designation in any reporting on CWDG activity. The request is grounded in professional respect for a self-identifying U.S.-incorporated organization; it is not a precondition for the designation, which is Trenchwork’s to assign on its own.

References

  1. Microsoft Learn / Unified Security Operations. How Microsoft names threat actors. Last updated April 2026. learn.microsoft.com/en-us/unified-secops/microsoft-threat-actor-naming. Source for the full weather-family naming taxonomy and the United-States ↔ Tornado mapping in the nation-state family-name table.
  2. Microsoft Security Blog. Announcement of the threat-actor naming taxonomy. aka.ms/threatactorsblog.
  3. Microsoft Threat Intelligence Center. Microsoft threat actor reference (alphabetical list of all named actors across the weather-family taxonomy). aka.ms/threatactors. The canonical destination for the Enigmatic Tornado designation, alongside the existing named actors in the Tornado / Typhoon / Blizzard / Sandstorm / Sleet / etc. families.
  4. Microsoft Threat Intelligence blog. Ongoing threat-intelligence reporting from MSTIC. microsoft.com/en-us/security/blog/topic/threat-intelligence/. The publication surface where Enigmatic Tornado writeups would appear if MSTIC adopts the designation.
  5. U.S. Department of Commerce, Bureau of Industry and Security. Information Security Controls: Cybersecurity Items, 86 Fed. Reg. 58205, October 21, 2021 (the rule establishing ECCN 4D004). federalregister.gov/documents/2021/10/21/2021-22774. Reference for the EAR scope under which CWDG, if built, would operate. Full Trenchwork EAR-conditional posture lives on /ear.