Living Cryptographic, Wallet & Anti-Tracking Security Advisories

CalyxOS v7.2.2.0 Production Relaunch Under Open-Source HSM Code-Signing Governance

Summary: Following a multi-month OTA freeze triggered by 2025 leadership transitions at the Calyx Institute, CalyxOS resumed production builds in July 2026 with version 7.2.2.0 (Android 16) signed by a newly provisioned open-source Hardware Security Module (HSM) infrastructure. Legacy pre-pause installations require verified key-lineage migration, while GrapheneOS retains exclusive Armv9 MTE memory hardening.

Key Governance Overhaul & Signing Lineage Transition

In mid-2025, following simultaneous departures of founding leadership and release-signing maintainers at the Calyx Institute, the CalyxOS project responsibly halted Over-The-Air (OTA) firmware distributions rather than shipping builds signed by keys with ambiguous custodial separation. Over the ensuing year, the engineering team redesigned its release infrastructure around an auditable, quorum-controlled open-source Hardware Security Module (HSM) signing pipeline, culminating in the July 2026 production release of CalyxOS v7.2.2.0 (Android 16).

Operational Guidance for Existing & Prospective Users

• Mandatory Update Check on Legacy Pre-2026 Devices: Any handset still running frozen 2025 CalyxOS builds lacks nearly a year of monthly Android Linux kernel, baseband, and Chromium WebView patches (high exploit risk). Owners must immediately verify their build number under Settings -> About Phone and follow the official CalyxOS v7.2.2+ flashing/key-migration procedure so Android Verified Boot (AVB 2.0) enrolls the new HSM root of trust with a re-locked bootloader.
• Architectural Posture vs. GrapheneOS: While CalyxOS v7.2.2+ restores timely monthly AOSP security patch delivery alongside turnkey Datura firewall and microG convenience, it does not incorporate GrapheneOS's custom hardened_malloc slab allocator, system-wide Armv9 Memory Tagging Extension (MTE) enforcement, JIT-less Vanadium defaults, or unprivileged Sandboxed Google Play. High-threat journalists, executives, and cryptocurrency multisig signers on Pixel 8, 9, and 10 hardware should review the full side-by-side matrix on our Hardened Mobile Operating Systems & Browsers Hub.

Primary Filing: CalyxOS Project | Canonical Spec: /privacy/hardened-os-browsers

Active Exploitation of Ethereum Pectra EIP-7702 (0x04 SET_CODE) Delegations by Automated Sweeper Contracts

Summary: Following Ethereum's Pectra upgrade, wallet-drainer syndicates weaponized EIP-7702 type-0x04 SET_CODE authorization tuples to attach persistent malicious smart-contract code (0xef0100 || address) directly onto victim Externally Owned Accounts. Signing a single off-chain authorization with chain_id = 0 allows attackers to sweep ETH and ERC-20 deposits automatically across every EVM chain simultaneously.

Attack Mechanics: 0xef0100 Persistent EOA Code Delegation

Introduced in the Ethereum Pectra hard fork (May 2025), EIP-7702 defines transaction type 0x04 allowing an Externally Owned Account (EOA) to sign an off-chain authorization tuple MAGIC (0x05) || rlp([chain_id, address, nonce]) that writes a 23-byte delegation designator (0xef0100 || target_address) into the EOA's account code field. Crucially, the victim does not even need ETH for gas: a third-party relayer controlled by a drainer syndicate can bundle the victim's signed authorization tuple and pay gas to activate the takeover!

Telemetry across mainnet and major L2s (Arbitrum, Base, Optimism, BSC) shows over 80%+ of early unsolicited EIP-7702 delegations traced to automated sweeper contracts (Inferno and successor drainer kits, analyzed in full inside our EIP-7702 Sweeper Delegations Post-Mortem):

• Wildcard Cross-Chain Replay (chain_id = 0): When chain_id inside the 0x04 tuple is set to 0, the signature becomes valid on every EIP-7702-compatible EVM chain where the EOA's nonce matches (notably nonce = 0 on fresh L2 accounts).
• Instant Inbound Deposit Sweeping: Because the EOA now executes attacker fallback() / receive() logic on every incoming ETH transfer, sending extra ETH to the compromised wallet to "pay gas for token rescue" instantaneously forwards that ETH to the attacker.

Immediate Verification & Revocation Controls

1. Never Blind-Sign 0x05 / 0x04 Prompts: Reject any dApp or wallet prompt requesting raw message/hash signing or Set Code delegation to an unverified implementation contract; inspect raw hex payloads offline in DT.gl's Calldata & Signature Auditor.
2. Revoking an Existing Malicious Delegation: Because EIP-7702 code lives on your own EOA keypair, if your 12/24-word seed phrase itself was not leaked, you can overwrite the delegation back to 0x0000000000000000000000000000000000000000 by submitting a sponsored/relayed type-0x04 transaction from a separate clean gas-payer account (never send gas ETH directly to the infected EOA first!).

Primary Filing: Ethereum EIP-7702 Specification | Canonical Spec: /crypto-wallets/self-custody-privacy

FTC Final Enforcement Orders Against Gravy Analytics / Venntel & Mobilewalla + California DROP Launch

Summary: Landmark Federal Trade Commission enforcement orders against Gravy Analytics, its subsidiary Venntel, and Mobilewalla prohibit the unlawful sale of non-consensual mobile advertising SDK location trails and mandate deletion of historic geolocation archives. Paired with California's 2026 Delete Request and Opt-Out Platform (DROP), statutory remedies now reinforce OS-level mobile sensor and ad-ID lockdown.

Enforcement Findings: Real-Time Bidding (RTB) Bidstream Harvesting

Following years of congressional oversight (including the July 2022 U.S. House Judiciary Committee record citing warrantless federal purchases of commercial cell-phone location feeds), the Federal Trade Commission finalized landmark enforcement actions against Gravy Analytics, its government-contracting subsidiary Venntel, and Mobilewalla. Investigations confirmed that commercial brokers ingested billions of daily latitude-longitude coordinates siphoned from ordinary consumer weather, flashlight, prayer, and gaming apps via embedded ad-exchange SDKs and real-time bidding (RTB) auctions without informed affirmative consent.

Key technical obligations imposed by these orders alongside the California Privacy Protection Agency's 2026 Delete Request and Opt-Out Platform (DROP, Cal. Civ. Code Section 1798.99.86):

• Mandatory Historic Dataset Deletion & Sensitive-Location Bans: Covered brokers are barred from selling, licensing, or transferring geolocation trails tied to healthcare clinics, religious houses of worship, domestic shelters, labor halls, and schools, and must purge illegally collected historic location corpora.
• Single-Request Statutory Cascading Deletion (DROP): Registered data brokers operating in California must poll the centralized DROP system at least every 45 days to honor verified consumer deletion directives rather than forcing citizens to complete 500+ deceptive individual opt-out webforms.

Why Endpoint OS Hardening Remains Mandatory

Legal prohibitions bind compliant domestic corporations; they do not stop offshore unregulated RTB exchanges, breached archive leaks (such as the 2025 Gravy Analytics S3 bucket breach), or cross-indexed people-search databases that expose cryptocurrency holders to physical home-invasion risk. Pair statutory deletion notices generated offline in our Location & Data-Broker Exposure Auditor with technical zeroing/deletion of mobile advertising IDs (AAID/IDFA), carrier CPNI PIN locks, and per-app Sensors + Network permission revocation on Hardened Mobile Operating Systems.

Primary Filing: Federal Trade Commission & California CPPA | Canonical Spec: /anti-tracking/data-brokers-telemetry

NIST Selects Code-Based HQC as Fifth Post-Quantum Standard Alongside IR 8547 Deprecation Milestones

Summary: NIST selected Hamming Quasi-Cyclic (HQC) from Round 4 candidates as its fifth post-quantum cryptographic standard, providing a code-based Key-Encapsulation Mechanism independent of structured algebraic lattices. ML-KEM (FIPS 203) remains the primary production default across TLS 1.3 and OpenSSH, while HQC establishes cryptanalytic defense-in-depth ahead of NIST IR 8547's 2030 classical deprecation deadline.

Technical Scope & Mathematical Orthogonalization

Both FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) derive their post-quantum security from structured algebraic module lattices (Module-LWE and Module-SIS). To eliminate single-family mathematical risk across global public-key infrastructure, NIST evaluated three non-lattice Round 4 KEM finalists (BIKE, HQC, and Classic McEliece) and selected HQC (Hamming Quasi-Cyclic) for standardization as a general-purpose backup KEM.

Unlike ML-KEM, HQC reduces security to the hardness of Syndrome Decoding of quasi-cyclic linear error-correcting codes in the Hamming metric (QC-SD): a well-studied coding-theory problem dating back more than half a century with thoroughly characterized decryption failure rates (DFR < 2^-128 at Category 1) and clean Fujisaki-Okamoto (FO) IND-CCA2 transforms.

Wire-Size Trade-Off vs. ML-KEM-768

• Primary Default Unchanged (ML-KEM-768): Production TLS 1.3 (X25519MLKEM768, codepoint 0x11EC), OpenSSH (mlkem768x25519-sha256), and age file encryption should continue deploying ML-KEM-768 (1,184-byte public key + 1,088-byte ciphertext) now rather than delaying migration for HQC's finalized FIPS text.
• HQC Bandwidth Footprint: At NIST Category 1 (HQC-128), public keys measure 2,249 bytes and ciphertexts measure 4,481 bytes (~3x the total handshake byte budget of ML-KEM-768, yet still dramatically smaller than Classic McEliece's 261,120-byte public keys).
• Cryptographic Agility Requirement: Protocol architects designing multi-decade key-wrapping formats, HSM firmware interfaces, and NIST IR 8547 (2030 deprecation / 2035 disallowance of RSA/ECDSA/X25519) compliance roadmaps should ensure key-share length fields accommodate 8 KB+ ciphertexts without fixed-buffer truncation so HQC can drop in seamlessly if structured lattice assumptions ever weaken.

Primary Filing: NIST Computer Security Resource Center | Canonical Spec: /privacy/post-quantum-cryptography-fips