Security Research & Architecture Investigación y Arquitectura de Seguridad

Eduardo
Camarillo

Independent security research focused on applied cryptography, zero-trust architecture, and secure systems engineering. Each project is fully documented with public audits and verifiable fixes. Investigación independiente en seguridad centrada en criptografía aplicada, arquitectura zero-trust e ingeniería de sistemas seguros. Cada proyecto está completamente documentado con auditorías públicas y correcciones verificables.

Research Investigación

15 articles across 4 projects 15 artículos en 4 proyectos

View GitHub → Ver GitHub →

Research Project Proyecto de Investigación

Protocolo
PHANTOM

Private, Highly Anonymous, Non-Interactive Transport with Obfuscated Metadata. Post-quantum asynchronous transport protocol over Tor Hidden Services. Formal security research employing a 7-phase methodology — currently in Phase 1 (Research Questions). All artifacts are produced under a strict evidence hierarchy (Level 1–7) with mandatory human verification.

Private, Highly Anonymous, Non-Interactive Transport with Obfuscated Metadata. Protocolo de transporte asíncrono post-cuántico sobre Tor Hidden Services. Investigación de seguridad formal bajo metodología de 7 fases — actualmente en Fase 1 (Preguntas de Investigación). Todos los artefactos se producen bajo una jerarquía de evidencia estricta (Niveles 1–7) con verificación humana obligatoria.

Repository Access — Initial Phase Acceso al Repositorio — Fase Inicial

The research repository, technical specifications, and Tamarin/ProVerif models are currently in initial consolidation within a private environment. Source code, formal models, and complete specifications will be made publicly available upon stabilization of the research baseline. The project is in an early and active phase of formal definition.

El repositorio de investigación, especificaciones técnicas y modelos Tamarin/ProVerif se encuentran en fase inicial de consolidación dentro de un entorno privado. El código fuente, modelos formales y especificaciones completas se harán públicos una vez alcanzada la estabilización de la línea base de investigación. El proyecto se encuentra en una fase temprana y activa de definición formal.

• 01. Specification

Protocol architecture & cryptographic stack.

Arquitectura y stack criptográfico.

• 02. RQ Matrix

8 Research Questions & validation status.

8 Preguntas de Investigación y estado.

• 03. Findings

Open problems & preliminary results.

Problemas abiertos y resultados preliminares.

• 04. Audit

Baseline hash & integrity chain.

Hash de línea base e integridad.

• 05. Repository

Progress by phase & pending artifacts.

Progreso por fase y artefactos pendientes.

1. Architectural Foundation & Adversary Model 1. Fundamentos Arquitectónicos y Modelo de Adversario

The PHANTOM Protocol replaces generic, idealized security assumptions with a strict, concrete threat parameterization. Rather than postulating theoretical "unconditional state-level anonymity," the protocol models an adversary possessing active network interception, control over up to 30% of overlay mixnet nodes (Tor Hidden Services / Loopix circuits), and continuous traffic capture capabilities under the Harvest-Now-Decrypt-Later (HNDL) paradigm. El Protocolo PHANTOM reemplaza las suposiciones de seguridad genéricas e idealizadas con una parametrización de amenaza concreta y estricta. En lugar de postular una "anonimización teórica incondicional", el protocolo modela a un adversario con capacidad de intercepción de red activa, control de hasta el 30% de los nodos de superposición (Tor Hidden Services / circuitos Loopix) y captura continua de tráfico bajo el paradigma Harvest-Now-Decrypt-Later (HNDL).

// ADVERSARY CAPABILITIES MATRIX (SPEC-000 §1.1)

Infrastructure Control Up to 30% malicious mixnet/relay nodes

Cryptographic Capability Cryptographically Relevant Quantum Computer (CRQC)

Traffic Analysis Transformer-based Inter-Arrival Time (IAT) Classifiers

Data Capture Indefinite storage of global encrypted streams

2. Cryptographic Stack & Hybrid Primitives 2. Stack Criptográfico y Primitivas Híbridas

To survive post-quantum transition windows, PHANTOM enforces a dual-layered, hybrid cryptographic architecture. Key encapsulation combines post-quantum lattice constructions (ML-KEM-768, FIPS 203) with established elliptic curve operations (X25519, RFC 7748). Long-term identities and initial handshake assertions rely on post-quantum lattice signatures (ML-DSA-87, FIPS 204), while symmetric payload transport leverages authenticated encryption via ChaCha20-Poly1305 (RFC 8439) with domain-separated key expansion executed through HKDF-HMAC-SHA3-256. Para garantizar la supervivencia durante la ventana de transición post-cuántica, PHANTOM implementa una arquitectura criptográfica híbrida de doble capa. El encapsulamiento de claves combina construcciones de reticulados post-cuánticos (ML-KEM-768, FIPS 203) con operaciones de curvas elípticas consolidadas (X25519, RFC 7748). Las identidades a largo plazo y las afirmaciones del handshake inicial se basan en firmas post-cuánticas (ML-DSA-87, FIPS 204), mientras que el transporte simétrico emplea cifrado autenticado mediante ChaCha20-Poly1305 (RFC 8439) con expansión de clave por separación de dominio vía HKDF-HMAC-SHA3-256.

Layer / Function	Primitive Instantiation	Standard	Evidence Level
PQ Key Encapsulation	ML-KEM-768	FIPS 203	Level 1 (NIST Standard)
Classic Remnant KEM	X25519	RFC 7748	Level 3 (IETF RFC)
Post-Quantum Signatures	ML-DSA-87	FIPS 204	Level 1 (NIST Standard)
Symmetric Transport	ChaCha20-Poly1305	RFC 8439	Level 3 (IETF RFC)
Domain-Separated KDF	HKDF-HMAC-SHA3-256	RFC 5869 / FIPS 202	Level 3 (IETF RFC)

3. Handshake v2 & Key Compromise Impersonation (KCI) Defense 3. Handshake v2 y Defensa Contra Suplantación por Compromiso de Clave (KCI)

The initial session setup resolves a critical flaw present in preliminary specifications (v0.1.0): the absence of active post-quantum origin authentication. In Handshake v2, Alice acquires Bob's PrekeyBundle_B (totalling 8,437 bytes) containing his static identity keys and ephemeral parameters. Alice derives three classical Diffie-Hellman exchanges (dh1, dh2, dh3) alongside a post-quantum encapsulation (ct_PQ_B, ss_PQ_B), asserting her identity via an ML-DSA-87 signature. El establecimiento de sesión inicial resuelve una vulnerabilidad crítica presente en especificaciones preliminares (v0.1.0): la falta de autenticación de origen post-cuántica activa. En el Handshake v2, Alice obtiene el PrekeyBundle_B de Bob (con un total de 8,437 bytes) que contiene sus claves de identidad estáticas y parámetros efímeros. Alice deriva tres intercambios Diffie-Hellman clásicos (dh1, dh2, dh3) junto con un encapsulamiento post-cuántico (ct_PQ_B, ss_PQ_B), afirmando su identidad mediante una firma ML-DSA-87.

// MASTER SECRET DERIVATION FLOW (SPEC-000 §3.2)

ikm = dh1 || dh2 || dh3 || ss_PQ_B || ss_PQ_A
PRK = HKDF-Extract(salt=zeros(32), ikm)
root_key = HKDF-Expand(PRK, "PHANTOM-v2.0.0" || "ROOT-INIT", 32)

4. The PHANTOM Split Ratchet Mechanism 4. El Mecanismo del Split Ratchet de PHANTOM

Executing post-quantum asymmetric key generation for every discrete message introduces unbearable bandwidth and latency amplification. To eliminate this penalty, PHANTOM introduces a turn-based Split Ratchet. During continuous unidirectional transmission streams, the protocol relies exclusively on symmetric HKDF chain advances—reducing packet overhead to zero bytes. Asymmetric post-quantum ratcheting is triggered strictly upon directional turns in the communication flow. Ejecutar la generación de claves asimétricas post-cuánticas para cada mensaje discreto introduce una amplificación de ancho de banda y latencia inaceptable. Para eliminar esta penalización, PHANTOM introduce un Split Ratchet basado en turnos. Durante la transmisión unidireccional continua de flujos, el protocolo depende exclusivamente de avances de cadena simétricos HKDF—reduciendo el overhead por paquete a cero bytes. El trinquete asimétrico post-cuántico se activa estrictamente durante cambios de dirección en el flujo de comunicación.

// SYMMETRIC CHAIN ADVANCE (SPEC-000 §4.2)

MK = HKDF-Expand(sending_chain_key, "PHANTOM-v2.0.0" || "MESSAGE-KEY", 32)
sending_chain_key = HKDF-Expand(sending_chain_key, "PHANTOM-v2.0.0" || "CHAIN-ADVANCE", 32)

5. Private Storage Network & Obfuscated Padding 5. Red de Almacenamiento Privado y Padding Ofuscado

To decouple sender and recipient online presence, messages are deposited on an untrusted relay network governed by Time-Structured Frozen Epochs (Δt = 300 s). Recipients query frozen database matrices using Private Information Retrieval (SimplePIR), guaranteeing the server cannot determine which record is fetched. At the network layer, all payloads are morphed into uniform cell sizes (S_cell = 2048 bytes) and injected via a Laplace Differential Privacy engine operating at discrete time slots (T_slot = 50 ms) to dismantle side-channel traffic analysis. Para desacoplar la presencia en línea del remitente y destinatario, los mensajes se depositan en una red de relays no confiable gobernada por Epochs Congelados Estructurados en el Tiempo (Δt = 300 s). Los destinatarios consultan las matrices de bases de datos congeladas mediante Recuperación de Información Privada (SimplePIR), garantizando que el servidor no pueda determinar qué registro se obtiene. En la capa de red, todos los payloads se transforman en celdas de tamaño uniforme (S_cell = 2048 bytes) e inyectan mediante un motor de Privacidad Diferencial de Laplace en intervalos discretos (T_slot = 50 ms) para desmantelar el análisis de tráfico por canales laterales.

// TRANSPORT PARAMETERS & BOUNDS (SPEC-000 §5–6)

FIXED CELL SIZE 2048 Bytes (S_cell)

PADDING INTERVAL 50 ms (T_slot)

DP BUDGET TARGET ε ≤ 1.0, δ = 2^-32

Research Questions — Phase 1 Validation Matrix

Preguntas de Investigación — Matriz de Validación Fase 1

Cross-validated against SPEC-000 v0.2.0. Evidence levels L1–L5. Verification targets V1 (Bibliographic) → V4 (Tamarin symbolic).

Validación cruzada contra SPEC-000 v0.2.0. Niveles de evidencia L1–L5. Objetivos de verificación V1 (Bibliográfico) → V4 (Tamarin simbólico).

Action Priority

CRITICAL

RQ-005 (Argon2id DoS)

HIGH

RQ-001 (KCI), RQ-004 (OOB Formal)

MEDIUM

RQ-003 (DP), RQ-006 (PCS), RQ-002 (PIR)

LOW

RQ-007 (SAS), RQ-008 (DPI)

ID	Research Question	Validity	Evidence	Verification Target	Status
RQ-001	KCI & Deniability in PQ Handshake SPK_B omission enables impersonation via CRQC adversary	Partial	L1, L2, L5	V4 — Tamarin	OPEN / HIGH
RQ-002	SimplePIR Hint Overhead & Epoch Viability 121 MB hint per 1 GB DB unsustainable on mobile	Conditional	L5	V3 — Simulation	OPEN / MED
RQ-003	DP Budget Depletion (ε, δ) under Continual Obs. Naive composition depletes budget in minutes at 50 ms slots	Valid as problem	L5	V2 — Analytical	OPEN / MED
RQ-004	OOB State Machine Deadlock Freedom No timeout/retry defined — session stuck at AWAITING_VERIFICATION	Valid w/o reservation	L5	V4 — Tamarin	OPEN / HIGH
RQ-005	DoS Memory Exhaustion via Argon2id Relay consumes 64 GB RAM/s at 1,000 concurrent StoreRequests	Valid w/o reservation	L2, L3, L5	V3 — Benchmark	OPEN / CRIT
RQ-006	PCS Bounds in Split Ratchet Unidirectional bursts — compromise propagates until direction change	Valid w/o reservation	L2, L5	V2 — Analytical	OPEN / MED
RQ-007	8-Digit SAS Entropy & MitM Bounds 10^-8 collision probability — depends on OOB adversary model	Conditional	L3, L5	V1 — Bibliographic	OPEN / LOW
RQ-008	Multimodal DPI Resistance Transformer IAT classifiers vs. 2048 B fixed cells + Laplace engine	Pending	L2, L5	V3 — LLMix Bench	OPEN / LOW

Evidence Base — Sources per RQ

Base de Evidencia — Fuentes por RQ

L1 Sources (NIST Standard)

2 total
FIPS 203, FIPS 204

L2 Sources (Protocol Spec)

4 total
PQXDH, Tor PoW, PQ3, SPQR

L3 Sources (IETF RFC)

2 total
RFC 9106, RFC 6189

L5 Sources (Peer-Reviewed)

15 total
SimplePIR, Cryspen, Loopix, …

Preliminary Findings — Phase 1 Open Problems

Hallazgos Preliminares — Problemas Abiertos Fase 1

Technically substantiated findings from RQ-001–008 analysis. All pending formal verification. Status: PENDING HUMAN VERIFICATION.

Hallazgos técnicamente fundamentados del análisis RQ-001–008. Todos pendientes de verificación formal. Estado: PENDIENTE DE VERIFICACIÓN HUMANA.

FINDING-001 RQ-001 · SPEC-000 §3.2

REQUIRES TAMARIN VERIFICATION

SPK_B Omission Enables Active Impersonation

Omisión de SPK_B Habilita Suplantación Activa

SPEC-000 §3.2 defines Alice's signature transcript as: Sig_A = ML-DSA-87.Sign(PQ_IK_A, IK_A || EK_A || ct_PQ_B || PQ_PK_A). SPK_B is absent from this transcript. A Dolev-Yao adversary controlling up to 30% of overlay nodes (SPEC-000 §1.1) can intercept PrekeyBundle_B, substitute SPK_B with a controlled SPK_B', re-encapsulate ct_PQ_B', and Alice's resulting Sig_A remains valid since SPK_B' does not appear in the signed transcript. Adversary derives dh1 and dh3 from the substituted key.

SPEC-000 §3.2 define el transcript firmado por Alice como: Sig_A = ML-DSA-87.Sign(PQ_IK_A, IK_A || EK_A || ct_PQ_B || PQ_PK_A). SPK_B está ausente de este transcript. Un adversario Dolev-Yao controlando hasta el 30% de nodos de superposición puede interceptar PrekeyBundle_B, sustituir SPK_B por un SPK_B' controlado, y el Sig_A resultante de Alice permanece válido. El adversario deriva dh1 y dh3 de la clave sustituida.

# Proposed minimal fix — SPEC-000 §3.2 correction (Sub-RQ 1.3, Option C)

Sig_A = ML-DSA-87.Sign(PQ_IK_A, IK_A || EK_A || ct_PQ_B || SPK_B || PQ_PK_A)
# Zero byte overhead · Zero latency penalty · Closes attack vector

FINDING-002 RQ-001 Sub-RQ 1.2 · V1 Confirmed

CONFIRMED BIBLIOGRAPHIC

ML-DSA-87 Eliminates Legal Deniability

ML-DSA-87 Elimina la Negación Legal

ML-DSA-87 (FIPS 204, EUF-CMA) generates non-repudiable signatures: any third party holding PQ_IK_A can verify Sig_A was produced by Alice. Deniability bits = 0. In the HNDL threat model (SPEC-000 §1.1), an adversary capturing handshake traffic today retains the ability to attribute the session to Alice upon acquiring a CRQC. This contrasts fundamentally with X3DH/PQXDH implicit authentication. Signal PQXDH §6 (L2) and Cryspen (L5) both confirm this tradeoff. Documented design decision pending ADR-001.

ML-DSA-87 (FIPS 204, EUF-CMA) genera firmas no repudiables: cualquier tercero con PQ_IK_A puede verificar que Sig_A fue producida por Alice. Bits de negación = 0. En el modelo de amenaza HNDL (SPEC-000 §1.1), un adversario que capture el tráfico del handshake hoy podrá atribuir la sesión a Alice al obtener un CRQC. Contrasta fundamentalmente con la autenticación implícita de X3DH/PQXDH. Signal PQXDH §6 (L2) y Cryspen (L5) confirman este tradeoff. Decisión de diseño documentada pendiente en ADR-001.

FINDING-003 RQ-005 · RFC 9106 · CRITICAL

VALIDATED — L3 EVIDENCE

Argon2id Symmetric Memory Exposes Relay to Trivial DoS

Memoria Simétrica de Argon2id Expone al Relay a DoS Trivial

RFC 9106 specifies Argon2id as a symmetric memory-hard function: verifier must allocate the same memory as the generator. With SPEC-000 §8 parameters (m=65536, t=3, p=4 → 64 MB per operation), a relay processing 1,000 concurrent StoreRequests must allocate 64 GB RAM simultaneously. This is a trivially achievable memory exhaustion vector requiring no cryptographic capability — only network throughput.

RFC 9106 especifica Argon2id como función de memoria dura simétrica: el verificador debe asignar la misma memoria que el generador. Con los parámetros de SPEC-000 §8 (m=65536, t=3, p=4 → 64 MB por operación), un relay procesando 1,000 StoreRequests concurrentes debe asignar 64 GB RAM simultáneamente. Es un vector de agotamiento de memoria trivialmente alcanzable sin capacidad criptográfica.

Concurrent req/s

1,000

RAM per req

64 MB

Relay RAM/s

64 GB

FINDING-004 RQ-002 · Henzinger et al. USENIX '23

SEVERITY INDETERMINATE

SimplePIR Hint Overhead May Be Unsustainable on Mobile

Overhead de Hint de SimplePIR Puede Ser Insostenible en Móvil

SimplePIR achieves 10 GB/s/core server throughput but requires the client to download an offline hint matrix of ~121 MB per 1 GB of database (Henzinger et al., USENIX Security 2023). In PHANTOM's rotating epoch architecture (Δt = 300 s), the client must refresh this hint each epoch cycle. SPEC-000 §5 does not define expected message volume per epoch, leaving severity indeterminate. Candidates for evaluation: DoublePIR (reduced hint via two-server PIR), YPIR (high-throughput single-server), Piano (sublinear server computation).

SimplePIR logra 10 GB/s/core de throughput en servidor pero requiere que el cliente descargue una matriz de hint offline de ~121 MB por 1 GB de base de datos (Henzinger et al., USENIX Security 2023). En la arquitectura de epochs rotatorios de PHANTOM (Δt = 300 s), el cliente debe refrescar este hint cada ciclo de epoch. SPEC-000 §5 no define el volumen de mensajes esperado por epoch, dejando la severidad indeterminada. Candidatos para evaluación: DoublePIR, YPIR, Piano.

FINDING-005 RQ-003 · Dwork et al., LLMix

COMPOSITION UNDEFINED

DP Budget Depletes Under Naive Composition at 50 ms Slots

Presupuesto DP se Agota con Composición Naïve a Slots de 50 ms

Under naive basic DP composition theorem, each T_slot = 50 ms injection event consumes ε_slot of the total budget. At 20 slots/s and a target of ε_total ≤ 1.0, the per-slot budget is ε_slot = 1.0/86,400×20 ≈ 5.8×10^-7. SPEC-000 §6 does not define the composition mechanism (Rényi DP or zCDP), leaving the 24-hour budget sustainability question formally unanswered. Under LLMix (2025) quantification, even optimized Loopix-style networks show non-trivial privacy erosion under sustained traffic analysis.

Bajo el teorema de composición naïve de DP, cada evento de inyección con T_slot = 50 ms consume ε_slot del presupuesto total. A 20 slots/s y objetivo ε_total ≤ 1.0, el presupuesto por slot es ε_slot ≈ 5.8×10^-7. SPEC-000 §6 no define el mecanismo de composición (Rényi DP o zCDP). Bajo cuantificación LLMix (2025), incluso redes estilo Loopix optimizadas muestran erosión de privacidad no trivial bajo análisis de tráfico sostenido.

Artifact Traceability Chain

SPEC-000 (v0.2.0) → RQ-001..008 (Phase 1) → LR-001..002 (Phase 2) → ADR-001..008 (Phase 3)

RQ-001 → LN-001 → LR-001 → FIPS 203/204, PQXDH, Cryspen

RQ-002 → LN-002 → LR-001 → SimplePIR, DoublePIR, YPIR, Piano

RQ-003 → LN-003 → LR-001 → Continual DP, Price of DP, Loopix, LLMix

RQ-004 → LN-004 → LR-001 → PQ3 Formal, Signal Formal

RQ-005 → LN-005 → LR-002 → RFC 9106, Equihash, Tor Prop. 327

RQ-006 → LN-006 → LR-002 → PCS (Cohn-Gordon), SPQR

Repository Integrity & Baseline Hashing

Integridad del Repositorio y Hash de Línea Base

Cryptographic anchoring of research artifacts. Baseline established 2025-07-25. All research commits are Ed25519-signed.

Anclaje criptográfico de artefactos de investigación. Línea base establecida 2025-07-25. Todos los commits de investigación son firmados con Ed25519.

SPEC-000_phantom_v020.md — Frozen Baseline SHA-256 REGISTERED

6a515447ec5c07a9ff23ab02d38d4890acf330852f3e66d87dd6641c9be77de6

Recalculated SHA-256 after full English translation of the technical specification. Formally registered in STACK.md as BASELINE-2025-07. Any future modifications to protocol architecture are recorded exclusively in SPEC-001+ or ADR-XXX artifacts — SPEC-000 is declared BASELINE_IMMUTABLE_EVALUATION.

SHA-256 recalculado tras la traducción completa al inglés de la especificación técnica. Registrado formalmente en STACK.md como BASELINE-2025-07. Cualquier modificación futura a la arquitectura del protocolo se registra exclusivamente en SPEC-001+ o ADR-XXX — SPEC-000 se declara BASELINE_IMMUTABLE_EVALUATION.

Commit Signing — Ed25519 SSH ACTIVE

All commits in the private research repository are cryptographically signed using an Ed25519 key bound to the research identity. The signing key is independent from the development key to enforce separation of concerns between research artifacts and portfolio infrastructure.

Todos los commits en el repositorio privado de investigación son firmados criptográficamente con una clave Ed25519 vinculada a la identidad de investigación. La clave de firma es independiente de la clave de desarrollo para separar los artefactos de investigación de la infraestructura del portafolio.

Identity 278573086+Noir0x63@users.noreply.github.com

Key Type ssh-ed25519

Fingerprint SHA256:2NIVQLiBNha2Rh0p7Fiz8bvlKBHaHfpv9DHSciI1FOM

Format gpg.format=ssh · commit.gpgsign=true

Research Governance GOVERNANCE.md

All research artifacts are produced under a formal governance framework defining 7 research phases, an evidence hierarchy (L1–L7), verification targets (V1–V4), and mandatory human reviewer sign-off before any artifact is promoted from DRAFT to VERIFIED status.

Todos los artefactos de investigación se producen bajo un marco de gobernanza formal que define 7 fases de investigación, una jerarquía de evidencia (L1–L7), objetivos de verificación (V1–V4), y la firma obligatoria de un revisor humano antes de que cualquier artefacto sea promovido de estado DRAFT a VERIFIED.

Current Phase

Phase 1
Research Questions

RQs Defined

8 / 8
All OPEN

ADRs Pending

8 ADRs
Phase 3 target

Specifications

SPEC-000
v0.2.0 frozen

Repository Structure — 7-Phase Lifecycle Progress

Estructura del Repositorio — Progreso del Ciclo de 7 Fases

Deterministic artifact lifecycle: each phase requires formally satisfied exit criteria before advancing. No artifact may be promoted to VERIFIED without human review and a cataloged primary source.

Ciclo de vida determinístico: cada fase requiere criterios de salida formalmente satisfechos antes de avanzar. Ningún artefacto puede ser promovido a VERIFIED sin revisión humana y una fuente primaria catalogada.

RQ-XXX → LN-XXX → LR-XXX → ADR-XXX → TM-XXX → SPEC-XXX → VER-XXX / EXP-XXX → PUB-XXX

PHASE 1 — ACTIVE

Research Questions

Preguntas de Investigación

8 / 8 defined

01_research_questions/

RQ-001 ✓

KCI & Deniability
13,903 bytes
4 Sub-RQs

RQ-002 ✓

SimplePIR Hints
2,156 bytes
1 question

RQ-003 ✓

DP Budget (ε,δ)
2,162 bytes
1 question

RQ-004 ✓

OOB Deadlock
1,869 bytes
1 question

RQ-005 ✓

Argon2id DoS
2,113 bytes
CRITICAL

RQ-006 ✓

PCS Bounds
1,866 bytes
1 question

RQ-007 ✓

SAS Entropy
1,791 bytes
1 question

RQ-008 ✓

DPI Resistance
1,840 bytes
Pending val.

Exit criteria status: All 8 RQs formally defined with mandatory exit criteria (mathematical proof, empirical simulation, evidence link). Status PENDING HUMAN VERIFICATION on all. RQ_VALIDATION_MATRIX.md cross-validated. Phase complete — ready to advance to Phase 2 when human verification is done.

Estado criterios de salida: Las 8 RQs definidas formalmente con criterios de salida obligatorios (prueba matemática, simulación empírica, enlace de evidencia). Estado PENDING HUMAN VERIFICATION en todas. RQ_VALIDATION_MATRIX.md validada cruzadamente. Fase completa — lista para avanzar a Fase 2 cuando se complete la verificación humana.

PHASE 2 — PARTIAL

Literature Reviews & Reading Notes

Revisiones de Literatura y Notas de Lectura

10 / 10 drafted

02_literature_reviews/

notes/ — Reading Notes (LN-XXX)

LN-001Handshake KCI — 1,484 BPENDING VER.

LN-002SimplePIR Hints — 1,762 BPENDING VER.

LN-003DP Privacy — 1,802 BPENDING VER.

LN-004OOB Formal Verif. — 1,465 BPENDING VER.

LN-005Argon2id Equihash — 1,657 BPENDING VER.

LN-006PCS SPQR — 1,365 BPENDING VER.

LN-007SAS Vaudenay-Pasini — 1,409 BPENDING VER.

LN-008DPI Resistance — 1,467 BPENDING VER.

reviews/ — Literature Reviews (LR-XXX)

LR-001Handshake, PIR, DP, Formal — 2,811 BPENDING VER.

LR-002Argon2id, PCS, SAS, DPI — 2,410 BPENDING VER.

Missing: Primary source annotations (actual paper reads). All LN/LR files are AI-assisted drafts flagged PENDING HUMAN VERIFICATION. Must be reviewed against each primary source before Phase 2 is complete.

Faltante: Anotaciones de fuentes primarias (lecturas reales de los papers). Todos los archivos LN/LR son borradores asistidos por IA marcados como PENDING HUMAN VERIFICATION. Deben ser revisados contra cada fuente primaria antes de que la Fase 2 sea completa.

PHASE 3 — NOT STARTED

Architectural Decision Records

Registros de Decisión Arquitectónica

0 / 8 drafted

03_architectural_decisions/

Directory: empty

[ ]ADR-001 — ML-DSA-87 vs. DVS deniability tradeoff (RQ-001)

[ ]ADR-002 — SimplePIR vs. DoublePIR / YPIR / Piano selection (RQ-002)

[ ]ADR-003 — Rényi DP vs. zCDP composition mechanism (RQ-003)

[ ]ADR-004 — OOB timeout / retry policy (RQ-004)

[ ]ADR-005 — Argon2id vs. Equihash / Tor Prop. 327 (RQ-005)

[ ]ADR-006 — PCS bound limit N in Split Ratchet (RQ-006)

[ ]ADR-007 — SAS digit count vs. adversary model (RQ-007)

[ ]ADR-008 — DPI countermeasure strategy (RQ-008)

Blocked on: Phase 2 human verification complete. Each ADR requires an actively investigated "Evidence Against" section per GOVERNANCE.md §4.

Bloqueado en: verificación humana de Fase 2 completa. Cada ADR requiere una sección "Evidence Against" activamente investigada según GOVERNANCE.md §4.

PHASE 4 — NOT STARTED

Threat Models

Modelos de Amenaza

0 / N drafted

04_threat_models/

Directory: empty

[ ]TM-001 — Extended Dolev-Yao + CRQC adversary model (formalizes §1.1)

[ ]TM-002 — HNDL (Harvest-Now-Decrypt-Later) threat surface

[ ]TM-003 — Global passive adversary with Transformer traffic analysis

[ ]TM-004 — Sybil attack surface on anonymous relay

PHASE 5 — BASELINE FROZEN

Technical Specifications

Especificaciones Técnicas

1 / N filed

05_technical_specifications/

SPEC-000 PHANTOM Protocol v0.2.0 — 9,677 B BASELINE_IMMUTABLE

Pending SPEC-001+ (post-ADR corrections)

[ ]SPEC-001 — Corrected transcript binding (SPK_B in Sig_A)

[ ]SPEC-002 — DP composition mechanism formal definition

[ ]SPEC-003 — Rate limiting redesign (asymmetric PoW)

SPEC-000 is frozen and immutable as evaluation baseline. All architecture corrections will be filed as SPEC-001+ after Phase 3 ADRs are complete.

SPEC-000 está congelada e inmutable como línea base de evaluación. Todas las correcciones arquitectónicas se archivarán como SPEC-001+ tras completar los ADRs de Fase 3.

PHASE 6 — NOT STARTED

Scientific Verifications

Verificaciones Científicas

0 artifacts filed

06_scientific_verifications/

formal_proofs/tamarin/

Directory: empty

[ ] phantom_kci_spkb.spthy

[ ] phantom_oob_liveness.spthy

[ ] phantom_kem_auth.spthy

experiments/

Directory: empty

[ ] EXP-001: SimplePIR benchmark

[ ] EXP-002: Argon2id DoS simulation

[ ] EXP-003: DP budget depletion

reports/

Directory: empty

[ ] VER-001: KCI verification report

[ ] VER-002: PoW asymmetry proof

[ ] VER-003: PCS bound proof

Blocked on: Phases 3–5. Tamarin models require finalized SPEC-00X to encode protocol. Experiments require ADR selection of alternatives (e.g., which PIR scheme to benchmark against).

Bloqueado en: Fases 3–5. Los modelos Tamarin requieren SPEC-00X finalizada para codificar el protocolo. Los experimentos requieren la selección de alternativas en ADR (p. ej., qué esquema PIR comparar).

PHASE 7 — DRAFT ONLY

Publications

Publicaciones

1 monograph draft

07_publications/

PUB-000 Research Monograph — 29,794 B — DRAFT NOT READY

PUB-000 is a research monograph outline produced as a roadmap artifact. It is not a submission-ready publication. Final publication requires complete Phase 6 verification results and formal proof closures before any venue submission (USENIX Security, IEEE S&P, or similar).

PUB-000 es un esquema de monografía de investigación producido como artefacto de hoja de ruta. No es una publicación lista para envío. La publicación final requiere resultados completos de verificación de Fase 6 y cierres de prueba formal antes de cualquier envío a una sede (USENIX Security, IEEE S&P, o similar).

Overall Progress Summary

Phase	Artifact Type	Exists	Verified	Missing / Blocked by
Phase 1	RQ-001..008	8 / 8	0 / 8	Human review sign-off on all RQs
Phase 2	LN-001..008, LR-001..002	10 / 10	0 / 10	Primary source read-throughs + human annotation
Phase 3	ADR-001..008	0 / 8	0 / 8	Blocked: Phase 2 verification complete
Phase 4	TM-001..00N	0 / N	0 / N	Blocked: Phase 3 ADRs complete
Phase 5	SPEC-000 (frozen) / SPEC-001+	1 / N	Baseline	SPEC-001+ blocked on Phase 3 ADRs
Phase 6	Tamarin .spthy / EXP / VER	0 / N	0 / N	Blocked: Phases 3–5 complete
Phase 7	PUB-000 (draft)	1 (outline)	Not ready	Blocked: Phase 6 verification results

Eduardo Camarillo

ProtocoloPHANTOM

1. Architectural Foundation & Adversary Model 1. Fundamentos Arquitectónicos y Modelo de Adversario

2. Cryptographic Stack & Hybrid Primitives 2. Stack Criptográfico y Primitivas Híbridas

3. Handshake v2 & Key Compromise Impersonation (KCI) Defense 3. Handshake v2 y Defensa Contra Suplantación por Compromiso de Clave (KCI)

4. The PHANTOM Split Ratchet Mechanism 4. El Mecanismo del Split Ratchet de PHANTOM

5. Private Storage Network & Obfuscated Padding 5. Red de Almacenamiento Privado y Padding Ofuscado

Research Questions — Phase 1 Validation Matrix

Preguntas de Investigación — Matriz de Validación Fase 1

Evidence Base — Sources per RQ

Base de Evidencia — Fuentes por RQ

Preliminary Findings — Phase 1 Open Problems

Hallazgos Preliminares — Problemas Abiertos Fase 1

SPK_B Omission Enables Active Impersonation

Omisión de SPK_B Habilita Suplantación Activa

ML-DSA-87 Eliminates Legal Deniability

ML-DSA-87 Elimina la Negación Legal

Argon2id Symmetric Memory Exposes Relay to Trivial DoS

Memoria Simétrica de Argon2id Expone al Relay a DoS Trivial

SimplePIR Hint Overhead May Be Unsustainable on Mobile

Overhead de Hint de SimplePIR Puede Ser Insostenible en Móvil

DP Budget Depletes Under Naive Composition at 50 ms Slots

Presupuesto DP se Agota con Composición Naïve a Slots de 50 ms

Artifact Traceability Chain

Repository Integrity & Baseline Hashing

Integridad del Repositorio y Hash de Línea Base

Repository Structure — 7-Phase Lifecycle Progress

Estructura del Repositorio — Progreso del Ciclo de 7 Fases

Research Questions

Preguntas de Investigación

Literature Reviews & Reading Notes

Revisiones de Literatura y Notas de Lectura

Architectural Decision Records

Registros de Decisión Arquitectónica

Threat Models

Modelos de Amenaza

Technical Specifications

Especificaciones Técnicas

Scientific Verifications

Verificaciones Científicas

Publications

Publicaciones

Overall Progress Summary

ProtocoloOMEGA

E2EE Confidentiality Protocol

Protocolo de Confidencialidad E2EE

Core Mechanism

Mecanismo Central

Deployment

Despliegue

Protocol Topology & Data Flow V3.1 Topología y Flujo de Datos V3.1

Documentation& Articles Documentacióny Artículos

Get inTouch Contáctame

Eduardo
Camarillo

Protocolo
PHANTOM

Protocolo
OMEGA

Documentation
& Articles Documentación
y Artículos

Get in
Touch Contáctame