[Research] Steganographic Point Obfuscation via Inverse 2-Isogenies for BLS12 Curves (DPI Censorship Resistance)

1

TL;DR

Public keys and signatures on standard BLS12 curves are deterministically structured, making them vulnerable to Deep Packet Inspection (DPI) censorship at the networking layer. Point-to-Uniform obfuscation (like Elligator Squared) mitigates this, but applying it to BLS12-381 creates a massive computational bottleneck for receiving validators due to its heavy 11-isogeny bridge.

By utilizing an optimized BLS12-479+ curve with an even cofactor, we can implement an explicit inverse 2-isogeny bridge. This reduces the deobfuscation overhead on the receiver’s end to just ~73,000 CPU cycles (<30 µs) — a 19.7x speedup, ensuring near-zero latency during mass block broadcasting.

The Problem: EIP-2537 and the 11-Isogeny Bottleneck

Censorship resistance requires hiding cryptographic material within uniform random strings. In a One-to-Many gossip protocol, a validator (sender) obfuscates a signature once, but tens of thousands of nodes (receivers) must deobfuscate it to verify the packet.

As standardized in EIP-2537, the Fp-to-G1 mapping for BLS12-381 relies on an 11-isogeny, requiring the evaluation of 11th and 15th-degree polynomials. While suitable for basic hash_to_curve operations, using this monolithic bridge for Elligator Squared deobfuscation costs ~1,439,000 cycles. This is unacceptably heavy for high-throughput gossipsub propagation.

The Solution: Constructive 2-Isogeny Inversion

Instead of relying on monolithic polynomial root-finding, I have modeled a steganographically optimized curve (BLS12-479+). Its even cofactor natively supports a mathematically trivial 2-isogeny bridge.

Using explicit VĂ©lus formulas, the inverse mapping is evaluated strictly as a sum of rational poles. The heavy lifting (solving quadratics for obfuscation) is strictly offloaded to the block proposer (sender). The network receivers only execute the lightweight forward isogeny.

Hardware Benchmarks (Magma Implementation)

Metric BLS12-381 (RFC 9381) BLS12-479+ (Proposed) Performance Gain
Isogeny Degree 11-isogeny 2-isogeny -
Security Level ~128-bit ~160-bit +32 bits
Obfuscation (Sender) ~4,250,000 cycles ~1,793,000 cycles ~2.37x Speedup
Deobfuscation (Receiver) ~1,439,000 cycles ~73,000 cycles ~19.7x Speedup

Note: The local benchmarks track pure cryptographic clock cycles without P2P network noise.

Links & Proofs

I have published the full algebraic proofs, kernel extraction theorems, and Magma scripts for both G1​ and G2​ mappings:

I would highly appreciate feedback from the core cryptography community on the feasibility of transitioning to even-cofactor curves for censorship-resistant consensus layers. Are there any hidden EVM precompile edge cases I should consider with this curve topology?

As a theoretical follow-up to the EIP-2537 hash_to_curve baseline:

It is worth recalling the results of Koshelev et al. regarding optimized indifferentiable hashing to j=0 curves (like BLS12-381). While their work provides elegant mathematical optimizations for the forward Hash-to-Curve mapping (e.g., minimizing exponentiations compared to the standard Wahby-Boneh 11-isogeny approach), the inverse mapping (Point-to-Uniform via Elligator Squared) remains fundamentally constrained by the isogeny degree itself.

By transitioning to a curve like BLS12-479+ with a mathematically trivial 2-isogeny, we essentially complement those forward-mapping optimizations. It ensures that the Elligator Squared deobfuscation on the receiver’s end is just as hardware-efficient, completely bypassing the monolithic polynomial evaluations inherent to higher-degree isogenies.

It would also be interesting to explore if any of the recent batch-hashing techniques proposed by Koshelev could be adapted to further optimize the proposer-side (sender) obfuscation overhead on this new curve topology.

References / Theoretical Context:

  1. D. Koshelev. “Indifferentiable hashing to ordinary elliptic Fq -curves of j=0 with the cost of one exponentiation in Fq .” Designs, Codes and Cryptography, 90(3):621–641, 2022. <https://doi.org/10.1007/s10623-022-01012-8>

  2. D. Koshelev. “The most efficient indifferentiable hashing to elliptic curves of j-invariant 1728.” Journal of Mathematical Cryptology, 16(1):119–131, 2022. <https://doi.org/10.1515/jmc-2021-0051>

  3. J. Chávez-Saab, F. Rodríguez-Henríquez, and M. Tibouchi. “SwiftEC: Shallue–van de Woestijne indifferentiable function to elliptic curves.” Journal of Cryptology, 37(4):Article 34, 2024. <https://doi.org/10.1007/s00145-024-09529-y>

  4. D. Koshelev. “Simultaneously simple universal and indifferentiable hashing to elliptic curves.” In Progress in Cryptology – AFRICACRYPT, Lecture Notes in Computer Science. Springer, 2025/2026. <https://doi.org/10.1007/978-3-031-97260-7_18>

2

the censorship resistant transport construction is technically plausible and the even-cofactor topology is a legitimate optimization candidate.

BLS12-479+ is not EIP-2537-compatible as a drop-in curve, most concretely because of the scalar ABI and curve-specific validation/subgroup/gas semantics;

and migration of the consensus curve remains unresolved until the complete system is compared against the strongest BLS12-381 construction under the same security, bandwidth, constant-time, and implementation assumptions.

One final security distinction: a ~321-bit subgroup gives roughly a 160-bit generic group-security ceiling, but that does not by itself establish ~160-bit pairing security. For BLS12 curves, the \mathbb F_{p^{12}} discrete-log side must be evaluated against exTNFS as well; current standards treat pairing-curve security as a separate parameter-selection problem.

3

Thank you for the precise review and validation of the even-cofactor topology.

You are entirely correct on all points. To clarify the scope and security targets:

1. Security and exTNFS: I completely agree that the ~321-bit subgroup size does not automatically guarantee ~160-bit pairing security due to exTNFS bounds on the Fp12​ side. The primary objective of parameterizing BLS12-479+ was not strictly to push the global pairing security to 160 bits, but rather to construct an explicit even-cofactor curve that maintains at least the ~128-bit baseline of BLS12-381 while unlocking the structural ability to use the 2-isogeny bridge.

2. Integration Scope: I also agree this is not a drop-in replacement for EIP-2537. My proposal targets the networking/consensus layer (gossipsub), where block propagation latency under DPI censorship is critical, rather than immediate EVM precompile replacement where ABI and gas semantics are already rigidly defined.

3. Complete System Comparison: I am preparing to benchmark the full End-to-End lifecycle (signature aggregation + obfuscation + broadcasting + deobfuscation + pairing verification) against the strongest BLS12-381 constructions.

Before I finalize the E2E benchmark suite, are there any specific bandwidth assumptions or network-layer constraints (e.g., specific SSZ serialization overheads) you would prioritize seeing in this comparison?

4

Regarding the exTNFS security ceiling: you are completely right. A ~321-bit subgroup does not by itself guarantee 160-bit pairing security. However, the objective of BLS12-479+ was to guarantee that its extension field $\mathbb{F}_{p^{12}}$(479Ă—12=5748 bits) is strictly larger than that of BLS12-381 (4572 bits). This securely maintains (and exceeds) the ~128-bit exTNFS baseline of the current standard, while structurally unlocking the 2-isogeny bridge.

More importantly, BLS12-479+ is presented here as a reference candidate—a proof of concept to demonstrate the 19.7x performance gain.

The core contribution of this research is the curve generation methodology itself. The algorithmic search for even-cofactor topologies allows us to instantiate a censorship-resistant curve at any arbitrary security level. If the Foundation requires a strict 160-bit or 192-bit exTNFS ceiling for the $\mathbb{F}_{p^{12}}$ side, the parameters can be scaled accordingly using the same framework.

Essentially, this methodology provides the community with the tool to target the exact pairing-security parameters needed for the consensus layer, while deterministically preserving the ~73k cycles deobfuscation overhead.

5

For the E2E benchmark I’d prioritize the actual wire boundary rather than assume a generic SSZ overhead.

I’d report:

raw cryptographic representation → proposed Point-to-Uniform representation → SSZ bytes → Snappy bytes → final gossipsub payload.

Current BLS12-381 references are 48 bytes for G1 public keys and 96 bytes for G2 signatures, so any changed representation should include the resulting SSZ/schema delta rather than only the algebraic cost. I’d separate G1 and G2. For steady-state gossip, G2 is probably the more important path because signatures occur throughout blocks, attestations, aggregates and sync messages, while public keys are not transmitted in every ordinary consensus message.

I would not choose one bandwidth assumption. Report the byte delta directly and run a bandwidth/RTT sweep. The 10 MiB consensus value is a protocol maximum for uncompressed payloads, not a useful representative network condition.

For latency, I’d measure p50/p95/p99 against the actual slot budget. Current mainnet uses 12-second slots, with attestation and aggregate timing at roughly 4 and 8 seconds into the slot.

Most importantly, because the objective is DPI resistance, I’d include distinguishing advantage after the complete Ethereum encoding pipeline. A uniform-looking curve representation only establishes the desired system property if the resulting wire traffic is materially harder to classify.

So the comparison I’d want is:

existing BLS12-381 transport vs strongest BLS12-381 Point-to-Uniform construction vs BLS12-479+,

using the same consensus messages, same SSZ+Snappy pipeline, same hardware, same network conditions, and the same classifier/adversary.

1 Like
6

Thank you for this detailed E2E testing specification. It is a brilliantly structured blueprint for the engineering phase and highlights exactly what needs to be measured before any production deployment.

However, I must be completely transparent about my resource constraints. My research is sponsored by my employer, who graciously provides me with the flexibility to explore cryptographic primitives, algebraic optimizations, and curve generation frameworks. Unfortunately, building a full Ethereum network simulation pipeline—implementing the SSZ/Snappy serialization delta, simulating gossipsub slot timing, and training a DPI classifier—falls strictly outside the scope of their commercial interests. Consequently, I simply cannot allocate professional time and resources to this intensive systems engineering phase.

My objective was to solve the mathematical bottleneck: proving the feasibility, securing the algebraic parameters (BLS12-479+), and delivering the deterministic tooling (the universal 2-isogeny framework) to achieve the 19.7x deobfuscation speedup. This cryptographic foundation is now fully laid out, mathematically verified, and publicly available.

To move this from a mathematical proof-of-concept to a network-tested protocol, collaboration is essential. Since I cannot build the network harness myself, do you know of any existing teams—perhaps working on consensus clients or network research within the EF ecosystem—who might be interested in taking this primitive and running it through their established testing environments?

1 Like
7

The DPI Paradox: Algebraic Payload vs. Transport Metadata

While discussing the E2E benchmark pipeline (SSZ → Snappy → gossipsub) and DPI distinguishing advantages, it is crucial to address a fundamental architectural paradox regarding censorship resistance.

Even if we achieve mathematically perfect Point-to-Uniform obfuscation for the $\mathbb{G}_2$ signature payload (which the proposed BLS12-479+ construction accomplishes), a DPI classifier will likely still succeed if the transport-layer metadata remains predictable.

If cleartext validator_index values, aggregation bitfields, and standard SSZ headers consistently precede 96 bytes of high-entropy data, the resulting wire traffic remains trivially easy to fingerprint. The DPI system does not need to analyze the signature itself; it simply flags the predictable protocol envelope.

In other words, algebraic obfuscation of the cryptographic primitive is a necessary condition for censorship resistance, but it is not a sufficient one without complementary transport-layer obfuscation (e.g., encapsulating gossipsub in a Noise-like framework or applying traffic padding).

Building a mathematically invisible payload solves the cryptographic bottleneck, but if it is wrapped in highly predictable routing metadata, the DPI classifier will still win. A truly censorship-resistant consensus network will ultimately require both layers to work in tandem.

1 Like
8

Future-Proofing DPI Resistance: 2-Isogeny Obfuscation on KSS-18

As we evaluate the network overhead and computational limits of Point-to-Uniform mappings, it is worth noting the long-term trajectory of curve choices regarding exTNFS attacks.

While the current proof-of-concept emphasizes BLS12-479+ as a direct drop-in replacement that preserves the $\mathbb{F}_{p^2}$ architecture for $\mathbb{G}_2$, the underlying obfuscation framework is not strictly bound to the BLS12 family. As detailed in the paper, the KSS-18 curve serves as a highly secure, pairing-friendly alternative to BLS12-381 that natively mitigates exTNFS vulnerabilities while keeping pairing costs at an acceptable level.

From a steganographic and computational perspective, transitioning to KSS-18 incurs no penalty on the obfuscation pipeline. The crucial mathematical component—the existence of a 2-isogeny—applies to KSS-18 just as it does to BLS12.

This means the deterministic framework avoiding the expensive, multi-branch Shallue-van de Woestijne (SW) inversions is fully portable. If the ecosystem eventually migrates to KSS-18 (or similar curves) to strengthen cryptographic margins, the 2-isogeny bridge ensures that DPI-resistant obfuscation will remain computationally viable without reintroducing severe gas or latency bottlenecks.

1 Like
9

The Metadata Trade-off: Obfuscated Indices vs. Obfuscated Public Keys

Following up on the DPI paradox and transport-layer metadata, there is a fundamental open question regarding the optimal network architecture for censorship resistance.

Currently, the protocol optimizes for bandwidth by transmitting a lightweight validator_index alongside the signature, caching the actual public key in the state. However, from a DPI-resistance perspective, this cleartext index acts as a predictable anchor that compromises the obfuscated payload.

This presents a critical system-level trade-off. It remains an open question which approach is ultimately more optimal:

  1. Retaining indices with transport encryption: Keeping the lightweight validator_index and aggregation bitfields, which forces the network to adopt complex, full-stack transport layer obfuscation to hide this metadata.
  2. Transmitting obfuscated Public Keys directly: Dropping the validator_index from the wire protocol entirely and instead transmitting the obfuscated $\mathbb{G}_1$ public key alongside the obfuscated $\mathbb{G}_2$ signature.

While the second option introduces a bandwidth penalty (due to the size of the $\mathbb{G}_1$ element compared to an integer index), it yields a self-contained packet that mathematically resembles pure uniform noise “out of the box,” potentially bypassing the need for heavy transport-layer wrappers.

Evaluating the network impact of these two paradigms—bandwidth overhead vs. metadata leakage—is exactly what makes the proposed E2E benchmark sweep so crucial.

1 Like
10

An Architectural Jackpot: Trivial 2-Isogeny Constants for BLS12-539

While finalizing the parameters for the high-security BLS12-539 curve (designed to secure against exTNFS attacks via a 539-bit prime), an unexpected and highly beneficial algebraic property emerged regarding its Point-to-Uniform obfuscation overhead.

Through a dynamic twist-search, we confirmed that the optimal curve equation for this specific field is $E: y^2 = x^3 + 1$ (where $B = 1$).

From a systems engineering and gas-cost perspective, this is a computational jackpot.

For the 2-isogeny mapping used in the obfuscation wrapper, we must find a root of $x^3 + B = 0$ to locate the 2-torsion point.

  • On the standard BLS12-381 curve, the seed $x$ is even, resulting in an odd curve order. Mathematically, this means BLS12-381 has no points of order 2 in its base field $\mathbb{F}_p$, making a highly efficient 2-isogeny Point-to-Uniform mapping impossible without operating in expensive extension fields.
  • By contrast, our BLS12-539 profile deliberately utilizes an odd seed, guaranteeing an even curve order and the existence of a 2-torsion point in $\mathbb{F}_p$. Furthermore, because $B = 1$, the equation $x^3 + 1 = 0$ yields a trivial integer root: $x_0 = -1 \in \mathbb{Z}$.

Because the root exists in the ring of integers, evaluating Vélu’s formulas yields universally small constants ($A’ = -15, B’ = 22$). Our curve design not only enables the 2-isogeny pipeline (which BLS12-381 prohibits) but reduces its rational map evaluation to trivial small-integer arithmetic, entirely bypassing 539-bit modular multiplications.

Explicit BLS12-539 Parameters

For developers and researchers wanting to benchmark this, here is the complete cryptographic specification:

1. Target Curve: $E: y^2 = x^3 + 1$
2. Isogenous Curve: $E’: y^2 = x^3 - 15x + 22$
3. 2-Torsion Root (Kernel): $x_0 = -1$

Seed ($x$): (Hamming Weight = 9)

  • Hex: 0x400000000000000000032F1
  • Dec: 1237940039285380274899137265

Base Field Prime ($p$, 539-bit):

  • Hex: 0x5555555555555555556ECDAAAAAAAAAAAAAAADD592341AAAAAAAAAAAE073DA2A83AD55555557570E89126C2FE055555F8E3EF3F9BFCF3E52EAC05D13300080094535DF1
  • Dec: 1199710345211519035416219429741786876319311421933497483626991418658478319088544596915796254702839442454587420641007826572438113715342206999017869775578752368205297

Order ($r$):

  • Dec: 2348542582773833227889579559074585135706986693842114542365887958205046357838972976018537621768903971344370401

Cofactor ($h$):

  • Dec: 510831846955296286119459770875511248778769497171135232

The System Impact

During obfuscation/deobfuscation, the algorithm mapping between $E$ and $E’$ only needs to multiply coordinates by 15 and 22. In hardware implementations, SNARK circuits, or EVM precompiles, this reduces to a few trivial bit-shifts and additions, entirely eliminating the need for 539-bit modular multiplications for these coefficients.

Counterintuitively, this proves that by upgrading to a massive 539-bit field for maximum cryptographic margin, we actually lower the arithmetic complexity of the obfuscation wrapper compared to the less secure BLS12-381 standard.

1 Like
11

The Index Paradox: Why Stateless $\mathbb{G}_1$ Obfuscation Beats Transport Crypto for DPI Resistance

As we design DPI-resistant consensus protocols, a recurring debate emerges around how to hide transport-layer metadata, specifically the 8-byte validator_index. The initial engineering instinct is often to use symmetric transport cryptography (like AES or ChaCha20) to encrypt the index, assuming it’s a “cheaper” alternative to applying Point-to-Uniform obfuscation to the full $\mathbb{G}_1$ public key.

However, a strict cryptographic and architectural analysis reveals a paradox: attempting to securely encrypt the index ultimately costs the same bandwidth as sending the full $\mathbb{G}_1$ key, but with catastrophic key-management vulnerabilities.

Here is the step-by-step breakdown of why transport crypto is a dead end for this specific problem, and why stateless $\mathbb{G}_1$ obfuscation is the only viable path.

1. The Sweet32 Trap (Why 64-bit blocks fail)

An 8-byte validator_index is 64 bits. If we attempt to encrypt this symmetrically without padding, we hit the Birthday Bound (Sweet32 vulnerability) at just $\sqrt{2^{64}} = 2^{32}$ blocks.
$2^{32}$ blocks is roughly 32 GB of data. In a high-throughput Gossip network, a passive DPI analyzer can collect this volume in hours. Once collisions occur, the predictable distribution of validator indices allows the censor to statistically recover the plaintext without the key. Raw 64-bit obfuscation is cryptographically toxic.

2. The Padding Paradox (Convergence of Bandwidth)

To fix the collision vulnerability, a cryptographer must pad the block to 256 bits (32 bytes) and use a modern AEAD cipher (like AES-GCM or ChaCha20-Poly1305).
Let’s look at the actual wire overhead:

  • Padded Block: 32 bytes
  • AEAD Nonce/IV: 12 bytes
  • MAC Tag: 16 bytes
    Total: 60 bytes.

At 60 bytes, the “cheap” symmetric encryption has bloated to practically the exact same size as a compressed $\mathbb{G}_1$ public key ($\approx 68$ bytes on our high-security BLS12-539 curve). The bandwidth saving is an illusion.

3. The Key Management Trap (Stateful vs. DPI)

Even with perfect 256-bit padded blocks, symmetric cryptography fundamentally requires keys.

  • If the network uses a global shared key, a censor simply spins up a node, extracts the key, and decrypts the traffic instantly.
  • If the network uses pairwise encryption (Noise/Libp2p-secio), nodes must perform Diffie-Hellman handshakes. Handshakes have highly distinct network signatures. A censor doesn’t need to break the crypto; they simply block the DH handshake packets, and the P2P layer collapses.

The Solution: True Stateless Payload ([Obfuscated G1, Obfuscated G2])

Instead of wrestling with stateful transport layers, we can solve this with pure mathematics. We drop the validator_index entirely.

The validator takes its public key ($\mathbb{G}_1$) and its signature ($\mathbb{G}_2$), applies a Point-to-Uniform mapping (Elligator Squared + 2-isogeny), and broadcasts:
[ Obfuscated G1, Obfuscated G2 ]

  1. Zero Key Management: The packet is 100% stateless. No handshakes, no shared secrets, no sessions.
  2. True White Noise: To the DPI censor, the packet is pure indistinguishable entropy from byte zero.
  3. Cryptographic Asymmetry: The only way for a censor to prove this noise belongs to Ethereum is to attempt a highly expensive Elliptic Curve Pairing operation on every packet, which will instantly melt their hardware.

What about CPU/Gas limits?

Historically, evaluating Point-to-Uniform mappings on $\mathbb{G}_1$ for every packet was considered computationally prohibitive. However, as demonstrated in our recent BLS12-539 v1.4.0 release, we hit an architectural jackpot: the optimal curve parameter is $B=1$. This yields a trivial 2-torsion root ($x_0 = -1$), reducing the 2-isogeny rational map constants to $A’ = -15, B’ = 22$.

Obfuscating/deobfuscating the $\mathbb{G}_1$ key now requires only trivial small-integer arithmetic (shifts and additions), completely eliminating the CPU bottleneck.

Conclusion: By accepting a mathematical reality over an engineering shortcut, we achieve absolute, stateless censorship resistance with virtually identical bandwidth overhead and minimal computational cost.

1 Like
12

I think the stateless [G1, G2] branch survives, but the conclusion that it is the only viable path does not yet.

The first thing I would remove is the Sweet32 premise. An 8-byte validator_index is 64-bit plaintext; that does not imply use of a 64-bit block cipher. Sweet32 is about ciphers with 64-bit block sizes. ChaCha20-Poly1305 accepts arbitrary-length plaintext, so there is no requirement to pad an 8-byte index to 32 bytes merely to avoid Sweet32. That means the 60-byte comparison is not an unavoidable property of modern authenticated encryption.

More importantly, Ethereum already has the stateful transport layer this comparison is trying to replace. QUIC is secured with TLS 1.3 and TCP fallback uses libp2p Noise; the networking specification explicitly says transport encryption provides confidentiality against observers. So for a passive DPI adversary, the validator_index is already inside an encrypted channel.

There is also a layer distinction here that I think matters. Making the application payload stateless does not make the Ethereum network stateless. If [obfuscated G1, obfuscated G2] is still propagated through libp2p/gossipsub, peers still establish QUIC/TLS or Noise connections. Therefore an adversary capable of killing those handshakes defeats both payload formats unless this proposal also changes the transport architecture. The stateless construction removes validator-identity lookup state; it does not by itself remove P2P session state.

So I would preserve the important discovery and narrow the claim: validator_index is not an invariant. A self-contained [G1, G2] representation is a legitimate successor candidate, and BLS12-539 may make that candidate substantially more practical. But “absolute censorship resistance” and “the only viable path” require a comparison under one fixed adversary.

For passive DPI, compare the complete observable flows: packet sizes, timing, direction, bursts, connection behavior and topology. For an active censor that can participate in or block the network, evaluate both architectures against that same capability. We should not use an active adversary to defeat transport crypto and then implicitly weaken it when evaluating the stateless candidate.

The experiment is therefore:

existing encrypted transport + validator_index

versus

existing encrypted transport + obfuscated G1/G2

and, only if we actually remove the current transport/session dependency,

stateless transport + obfuscated G1/G2.

Measure classifier advantage, bandwidth, CPU, latency, state requirements and implementation complexity under the same workload and adversary. The index was an implementation choice, not an invariant. Now the experiment should determine whether removing it actually moves the full-system frontier.

1 Like
13

You raise excellent points regarding the current layer structure, but evaluating the stateless [$\mathbb{G}_1, \mathbb{G}_2$] payload purely within the context of a functioning TLS/Noise transport fundamentally misses the threat model this research addresses.

To clarify a few points:

  1. The Block vs. Stream Cipher Context:
    The padding argument was formulated specifically in the context of block ciphers, which are the architecturally standard approach for encrypting fixed-width discrete fields (like an 8-byte index) independently of a stream. If we assume a block cipher, the Sweet32 vulnerability and the necessity of a 256-bit padding stand.

  2. The Transport Layer Paradox:
    You correctly note that validator_index is already encrypted via QUIC/TLS 1.3 or TCP/Noise. If we assume a passive adversary that allows these stateful connections to exist, then the subject of discussion is entirely absent. We don’t need payload obfuscation if the transport tunnel is secure and unblocked.
    However, the genesis of this research is the active DPI adversary who simply drops packets containing TLS/Noise handshake signatures. When the transport layer fails to establish, its confidentiality guarantees for the payload are zero.

  3. ECDHKEP Obfuscation is a Given:
    If the network attempts to salvage the existing stateful transport against an active DPI, it will be forced to obfuscate the ECDH ephemeral keys during the handshake anyway (e.g., using Elligator 2 for Montgomery curves or Elligator Squared for Weierstrass). This isn’t a novel architectural shift; it’s just a mandatory implementation step to hide the handshake.

The Real Experiment

The core proposition is that if we must employ Point-to-Uniform obfuscation (Elligator) anyway—either to hide transport handshakes or to hide the payload—applying it directly to the native payload (via the trivial $B=1$ 2-isogeny constants on BLS12-539) is arguably cleaner.

It makes the packet self-contained. It enables fallback to connectionless, stateless transport (like raw UDP) in extreme censorship environments where establishing a stateful session is mathematically or practically impossible.

The experiment isn’t just about replacing the index inside a working Noise tunnel. It is about whether making the payload fundamentally stateless provides a more robust fallback architecture when the Noise tunnel is actively denied.

1 Like
14

The Architectural Fallacy of Tunneling: Why ECDH-based Encryption Fails for Consensus Steganography (and Why Native BLS Obfuscation is Required)

When discussing censorship resistance for the Ethereum consensus layer, a common intuitive counter-proposal arises: Instead of natively obfuscating BLS points ($\mathbb{G}_1$/$\mathbb{G}_2$), why not encrypt the validator_index and the entire consensus payload using an Ephemeral Elliptic Curve Diffie-Hellman (ECDH) key exchange?

While tunneling works well for standard web traffic, applying a stateful ECDH key exchange to a decentralized, high-churn consensus network like Ethereum introduces catastrophic architectural and steganographic vulnerabilities.

1. The Threat of Active Probing & The Four-Way Identity Trap

It is a valid observation that any unauthenticated protocol (whether an open ECDH tunnel or natively obfuscated consensus points) is vulnerable to an active state-level censor. A censor could perform a MitM attack on an unauthenticated tunnel, or simply run a node to receive and deobfuscate public points.

Therefore, defense against active probing strictly requires authentication. However, how we authenticate changes everything. If we attempt to use an ECDH tunnel to hide consensus data, we fall into an unsolvable four-way trap:

  • Passive Detection (The Algebraic Signature Leak): A standard ECDH handshake requires transmitting ephemeral public keys in the clear. These keys possess distinct algebraic invariants. A passive DPI system detects this mathematical signature in the initial bytes and drops the connection immediately.
  • Unauthenticated ECDH (The Protocol Discipline Trap): If one attempts to bypass passive detection by obfuscating the ECDH keys without prior authentication, the network falls victim to active blind probing. A state-level censor observing uniform traffic can simply guess the protocol and initiate a MitM probe by sending their own obfuscated ephemeral keys. Because the inherent interactive discipline of the ECDH protocol dictates a response, the victim node is compelled to complete the key exchange and reply with the first encrypted frame containing its validator_index. The censor decrypts the response, confirms the node’s existence, and permanently bans the IP.
  • Consensus-Authenticated ECDH (The Plaintext Identity Leak): To prevent active MitM, the ephemeral keys could be signed by the node’s long-term identity key. If this relies on the Beacon State, the receiving peer must know who the sender is to fetch the correct public key. This forces the sender to transmit their validator_index in plaintext outside the tunnel. DPI simply profiles and blocks the connection based on this identifier.
  • PKI-Authenticated ECDH (The OCSP Trap): If the network abandons the Beacon State and uses standard P2P identity certificates to authenticate the handshake, a new fatal flaw emerges. Even if these certificates are aggressively cached by peers, their revocation status must be validated to maintain zero-trust security. This mandates the Online Certificate Status Protocol (OCSP). OCSP traffic is unmasked and exhibits highly distinct structural signatures. A state-level censor simply blocks the OCSP requests, instantly paralyzing the network’s ability to authenticate tunnels.

2. Network Paralysis: The Stateful Handshake Bottleneck

Ethereum relies on the libp2p GossipSub protocol, characterized by aggressive peer discovery and high churn.

  • Connection Churn Overhead: In a fluid P2P mesh, nodes constantly drop and establish connections. Requiring a multi-round-trip cryptographic handshake (Key Exchange + Signature Verification + OCSP Validation) for every new peer connection would introduce massive latency, destroying the ultra-low latency required for block propagation and attestation aggregation.
  • Denial of Service (DoS): The computational cost of continuous ECDH handshakes opens a glaring DoS vector. Malicious actors could easily spam unauthenticated connection requests, forcing nodes to constantly compute heavy ECDH share derivations and exhaust their CPU resources, effectively halting consensus.

3. The Superiority of Stateless Native BLS Obfuscation

Because authenticated tunnels either leak identifying metadata, rely on signature-heavy infrastructure (OCSP), or cause DoS, we must abandon stateful tunneling for consensus data entirely.

Instead, we must leverage Native Point Obfuscation. By applying explicit inverse isogenies (e.g., the 11-isogeny for $\mathbb{G}_1$ and 3-isogeny for $\mathbb{G}_2$) combined with the Elligator Squared framework, we solve both passive and active threats natively:

  1. Passive DPI Immunity: The BLS signature and the public key are transformed directly into uniform random noise at the protocol layer. DPI classifiers looking for algebraic signatures are completely blinded.
  2. Active Probing Resistance via “Silent Drops”: Unlike ECDH tunnels, whose very protocol discipline forces the node to actively respond to blind probes, obfuscated BLS points are verified unilaterally and statelessly. If an active censor probes the node with uniform garbage, the signature verification simply fails. The receiving node strictly maintains a “silent drop” policy—it generates zero response bytes. Because the node never talks back, the censor cannot distinguish the node from an inactive IP or a black hole, preserving perfect steganographic deniability.
  3. Zero Overhead: There are no ECDH round-trips, no certificate caches, no OCSP checks, and no prior identity leaks. The payload remains seamlessly compatible with the extreme efficiency of the libp2p gossip protocol.

Research Paper (Zenodo)