[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