The unavoidable UX–security trade-offs in TLOS arising from interface design and physical constraints.

[SoraSuegami]

I will first summarize, to the best of my understanding, TLOS’s interface and the security it provides, and then suggest the unavoidable UX–security trade-offs in TLOS arising from interface design and physical constraints.

Summary of TLOS

TLOS is an obfuscation scheme for a point function that returns 1 if the given input x is equal to the hardcoded (planted) secret; otherwise it returns 0. In a simple hash-based instantiation of point-function obfuscation, TLOS claims that it increases the computational cost of evaluating the function on each input. Consequently, an honest user who knows the planted secret only needs to evaluate the obfuscated circuit once, whereas an attacker must attempt evaluations on many candidate inputs. If, in the application design, the benefit of learning the planted secret is larger than the cost of evaluating the obfuscated circuit once, but smaller than the total cost an attacker would incur to brute-force the secret (i.e., to evaluate the obfuscated circuit as many times as needed), then TLOS is secure against an economically rational adversary. In particular, even when the input domain is small, security can be maintained as long as this cost–benefit relationship continues to hold.

---

The unavoidable UX–security trade-offs in TLOS arising from interface design and physical constraints

I will analyze the properties of point-function obfuscation itself, independently of any particular implementation. The procedure for evaluating the obfuscated circuit can be classified into the following three types:

1. Computation that does not depend on the input $x$.
2. Computation that depends on $x$ and is necessary to learn the output of the obfuscated circuit.
3. Computation that may depend on $x$ but is not necessary to learn the output of the obfuscated circuit. (For example, TLOS’s PoW layer falls into this category, since it can be executed after the LWE puzzle layer reveals the output—namely, after one learns that a particular input is the planted one.)

Let $c_1$, $c_2$, and $c_3$ denote the per-input computational costs required for the computations in categories 1, 2, and 3, respectively. When an adversary tries $n$ inputs, it must incur a total cost of $(c_1 + c_3) + n c_2$. Therefore, the difference in computational cost between the adversary and an honest user is $(n-1)c_2$.

The number of trials $n$ that an adversary needs in order to find an input equal to the planted secret with non-negligible probability depends only on the application, and is independent of the particular implementation of point-function obfuscation. If the planted secret is chosen uniformly at random from a domain $\mathcal{D}$ of size $|\mathcal{D}|$, then an adversary who tries $n$ distinct inputs hits the planted secret with probability $\frac{n}{|\mathcal{D}|}$.

For example, in an application such as a wallet with human-memorable recovery codes mentioned in the paper, if the code is a 6-digit decimal string, then with $n = 10000$ the adversary can guess the planted secret with probability 1%. If this wallet is intended to remain secure for balances up to $1000, then the computation cost $c_2$ must be on the order of $0.1 even for an honest user.

The appendix presents a ChatGPT-generated analysis of the relationship between electricity cost and the computation time required on a smartphone, a laptop PC, and a GPU server. To force an electricity cost of $0.10—assuming the lowest electricity price in the US and measuring computation in 64-bit integer multiplications—a smartphone would need to compute continuously for more than five days. Note that in practice, TLOS computation is not composed solely of 64-bit multiplications, so this estimate does not directly carry over as-is.

Summarizing the analysis above, to ensure that a wallet protected by a six-digit recovery code safeguards $1,000 of assets against an economically rational adversary with probability at least 99%, an honest user with a smartphone would need to make the phone compute continuously for a few days—incurring about $0.10 in electricity cost—each time they authenticate. This is hardly an ideal user experience.

Even when considering the problem more generally, in settings with a small input domain—such as the applications discussed in the TLOS paper—the required attack cost is fundamentally limited by brute-force search over the input space and thus can be at most a small constant factor larger than the honest evaluation cost. As a result, if one aims to guarantee a sufficiently high attack cost except with sufficiently small probability, it is unavoidable that the honest evaluation cost also increases accordingly, which in turn degrades the UX by increasing the honest user’s computation (waiting) time.

---

Appendix: ChatGPT-generated analysis of the relationship between electricity cost and the computation time required on a smartphone, a laptop PC, and a GPU server

1) Scope

This report estimates:

1. How much electrical energy you can buy for $0.10 at the lowest U.S. residential retail electricity price (state-level average).
2. How many 64‑bit integer multiplications that energy corresponds to on:
   • a smartphone‑class CPU,
   • a laptop‑class CPU,
   • a server‑class GPU.
3. How long each device would need to run (at assumed power draw) to consume $0.10 of electricity.

All compute figures are order‑of‑magnitude engineering estimates, not benchmark results.

---

2) Electricity price assumption: lowest U.S. residential retail price (state average)

Using the Electric Power Monthly Table 5.6.A (Average Price of Electricity to Ultimate Customers by End‑Use Sector, by State), data for November 2025 (release date Jan 26, 2026), the lowest residential state average listed is North Dakota: 11.93 ¢/kWh. (eia.gov)

Let:

• Price $p = 11.93 \text{¢/kWh} = 0.1193 \text{\$/kWh}$

---

3) Energy purchasable with $0.10

Energy purchasable with $0.10:

$$ E_{\text{kWh}} = \frac{0.10}{p} = \frac{0.10}{0.1193} \approx 0.8382\ \text{kWh} $$

Convert to joules using $1\ \text{kWh} = 3.6\times 10^6\ \text{J}$:

$$ E_{\text{J}} \approx 0.8382\times 3.6\times 10^6 \approx 3.018\times 10^6\ \text{J} = 3.018\ \text{MJ} $$

So, $0.10 buys ~0.838 kWh (~3.02 MJ) under the price assumption above.

---

4) Device models and compute models

4.1 Smartphone‑class CPU model (A17 Pro‑class)

Core configuration (representative): 6‑core CPU with 2 performance + 4 efficiency cores. (support.apple.com)
Clock assumptions used for the model: P‑cores up to 3.78 GHz; E‑cores up to 2.11 GHz. (notebookcheck.net)

Throughput model (idealized):

• Assume 1 × int64 multiply per cycle per core at the assumed clocks.
• Aggregate cycle budget: $R_{\text{phone}} = 2\cdot 3.78 + 4\cdot 2.11 = 16.0 \text{GHz} \Rightarrow 1.6\times 10^{10} \text{int64 mul/s} $

Power assumption (workload power, not a spec): 3–6 W.

---

4.2 Laptop‑class CPU model (Intel Core i7‑1360P‑class)

Representative parameters:

• 4 P‑cores (max turbo 5.00 GHz)
• 8 E‑cores (max turbo 3.70 GHz)
• Processor base power 28 W; maximum turbo power 64 W (intel.com)

Throughput model (idealized): $R_{\text{laptop}} = 4\cdot 5.0 + 8\cdot 3.7 = 49.6 \text{GHz} \Rightarrow 4.96\times 10^{10}\ \text{int64 mul/s}$

Power assumption: use 28 W and 64 W as a bracket (CPU power limits, not whole‑system wall power). (intel.com)

---

4.3 Server‑class GPU model (NVIDIA H100 SXM‑class)

Representative parameters (H100 SXM):

• FP32 peak: 67 TFLOPS
• Max TDP: up to 700 W (configurable)
  (nvidia.com)

Architecture detail used:

• 132 SMs, 128 FP32 CUDA cores per SM (16,896 FP32 cores total). (developer.nvidia.com)

Estimating 32‑bit integer throughput from NVIDIA’s instruction‑throughput table: The instruction‑throughput table defines throughput in operations per clock cycle per multiprocessor; it also states that for warp size 32, one instruction corresponds to 32 operations (i.e., $N$ ops/clock implies $N/32$ warp‑instructions/clock). (docs.nvidia.com)

For 32‑bit integer multiply / multiply‑add (mad.lo.s32), Table 5 gives a throughput of 64 results per clock per multiprocessor (shown as “64” with a footnote). (docs.nvidia.com)

Step A: infer an effective clock from FP32 peak (approximation): Assuming the FP32 TFLOPS spec counts FMA as 2 FLOPs:

$$ f \approx \frac{67\times 10^{12}}{(16896)\cdot 2} \approx 1.98\times 10^9\ \text{Hz} $$

Step B: estimate 32‑bit integer “ops/s”: $R_{32} \approx 64\ \frac{\text{ops}}{\text{cycle·SM}}\cdot 132\ \text{SM}\cdot 1.98\times 10^9\ \frac{\text{cycles}}{\text{s}} \approx 1.675\times 10^{13}\ \text{ops/s}$

Step C: map 32‑bit ops to int64 multiplications: A 64‑bit integer multiplication typically expands to multiple narrower operations (sequence depends on compiler/codegen). Model: $R_{64} \approx \frac{R_{32}}{k}$

Report a sensitivity band:

• optimistic: $k=8$
• baseline: $k=20$
• conservative: $k=32$

For the baseline $k=20$: $R_{64} \approx 8.38\times 10^{11}\ \text{int64 mul/s}$

---

5) Method (common to all devices)

Given energy budget $E_J$ and average device power $P$:

• Runtime to consume $0.10: $t = \frac{E_J}{P}$
• Total int64 multiplies: $N = R\cdot t$
• Energy efficiency: $\eta = \frac{R}{P}\quad[\text{int64 mul/J}]$ and $N = \eta\cdot E_J$.

---

6) Results

6.1 Energy for $0.10 at the assumed minimum U.S. residential rate

• 0.838 kWh
• 3.02 MJ

6.2 Compute and time per $0.10

Device class	Representative model	Assumed power (W)	Est. int64 mul/s	Time to spend $0.10	Est. int64 mul for $0.10	Est. int64 mul/J
Smartphone CPU	A17 Pro‑class	3	1.6e10	279 h (11.6 d)	1.61e16	5.33e9
Smartphone CPU	A17 Pro‑class	6	1.6e10	140 h (5.82 d)	8.05e15	2.67e9
Laptop CPU	i7‑1360P‑class	28	4.96e10	29.9 h (1.25 d)	5.35e15	1.77e9
Laptop CPU	i7‑1360P‑class	64	4.96e10	13.1 h	2.34e15	7.75e8
Server GPU	H100 SXM‑class (baseline $k=20$)	700	8.38e11	1.20 h (71.8 min)	3.61e15	1.20e9

GPU sensitivity to the int64 expansion factor $k$ (700 W):

• $k=8$: $N \approx 9.03\times 10^{15}$ int64 multiplies per $0.10
• $k=20$: $N \approx 3.61\times 10^{15}$ int64 multiplies per $0.10
• $k=32$: $N \approx 2.26\times 10^{15}$ int64 multiplies per $0.10

---

7) Interpretation

For a fixed energy budget ($0.10 → ~3.02 MJ at the assumed price), total work is:

$$ N = E_J \cdot \left(\frac{R}{P}\right) $$

So “multiplies per $0.10” depends on energy efficiency $(R/P)$, not wattage alone:

• Lower power increases the time to spend the same dollar amount.
• Higher $R/P$ increases the amount of work per dollar.

The smartphone runs for days to spend $0.10, while the GPU spends $0.10 in ~1.2 hours (under the chosen assumptions).

---

8) Major limitations (important)

1. Electricity price definition: This uses EIA state‑average residential “average price” for one month; the cheapest achievable retail rate can differ by utility, tariff, plan, time‑of‑use, etc. (eia.gov)
2. Power draw basis mismatch: CPU “W” here is not consistently wall‑power; system overheads and PSU losses are ignored. GPU TDP is used as a proxy for sustained board power. (nvidia.com)
3. Clock sustainability: Real devices may not sustain peak clocks under long continuous load; DVFS/thermal throttling will reduce sustained $R$.
4. GPU int64 model uncertainty: The instruction‑throughput table provides theoretical maxima and notes that achieving them can require specific sequences/care; mapping int64 to narrower ops is compiler‑ and kernel‑dependent. (docs.nvidia.com)

---

References

1. U.S. Energy Information Administration. Electric Power Monthly, Table 5.6.A “Average Price of Electricity to Ultimate Customers by End‑Use Sector, by State, November 2025 and 2024 (Cents per Kilowatthour)”; data for Nov 2025; release date Jan 26, 2026. (eia.gov)
2. Apple. “iPad mini (A17 Pro) — Tech Specs” (CPU core configuration). (support.apple.com)
3. NotebookCheck.net. “Apple A17 Pro Processor — Benchmarks and Specs” (clock assumptions used in the model). (notebookcheck.net)
4. Intel. “Intel Core i7‑1360P Processor — Specifications” (core counts, turbo frequencies, power limits). (intel.com)
5. NVIDIA. “H100 GPU” product specifications (FP32 peak; max TDP up to 700 W). (nvidia.com)
6. NVIDIA Technical Blog. “NVIDIA Hopper Architecture In‑Depth” (H100 SXM SM count; FP32 cores/SM). (developer.nvidia.com)
7. CUDA C++ Best Practices Guide. Section 12.1 / Table 5 (definition of ops/clock per multiprocessor; mad.lo.s32 throughput row). (docs.nvidia.com)

[igor53627]

Thanks for the careful analysis. We agree with the core UX and security trade-off for low-entropy secrets, and we have tried to state this explicitly.

1. TLOS is not a hash-only point function. The design uses on-chain LWE, wire binding, and a planted LWE puzzle. The cost-based framing still holds, but it is not just a hash construction.

2. Planted secret is not the same as the input secret. The planted secret s* is the puzzle witness derived off-chain. The input secret is the user preimage. They are related via hashing, but they are not the same object.

3. PoW is an online throttle only. Attackers can simulate the full check offline. PoW does not raise offline enumeration cost. It only makes on-chain attempts expensive. Commit-time randomness binding prevents precomputation and forces per-instance offline work once randao is known. The model assumes a commit time bound to randao and an expiry window, so the attacker does not have indefinite time across arbitrary future randomness.

4. Low-entropy domains remain dictionary-bound. The planted puzzle is not a per-guess KDF. For low-entropy inputs, brute-force asymptotics remain unchanged. The trade-off you describe is real, but there is a wide middle ground between "tiny" and "256-bit" secrets where the per-guess cost meaningfully stretches the attack timeline while keeping honest UX acceptable.

On-chain oracle note. These issues can be mitigated by forcing evaluation through an on-chain oracle so each guess pays gas or PoW. The goal of TLOS is to explore what can be achieved without such an oracle, namely public, offline-simulatable evaluation with purely cryptographic cost.

Follow up:

Additional design note. If PoW and the planted puzzle are cheap, the scheme can be reduced to the LWE layer. A simpler construction is an LWE Jump Table. Replace transparent switch or if branches with LWE-encrypted selectors. The contract stores ciphertexts where the plaintext bit, noise versus a scaled value like q over 2, encodes the branch. At runtime the user provides a witness secret vector that allows inner products to decrypt the next branch on the fly. This makes control flow opaque to symbolic analysis unless the attacker breaks LWE.

If LWE were available as a cheap precompile, for example on L2, we could build much more complex mixed programs while keeping control flow opaque. The other layers still help. Topology mixing makes structure harder to reconstruct. Wire binding prevents mix and match of partial traces. Together they push attackers away from static analysis and toward solving hard lattice problems or paying real compute per guess, not just for one gate but across a full program.

P.S. On electricity costs, the scaling is not strictly linear. The dominant cost can be memory bandwidth and batching effects, so energy per guess varies with hardware, batch size, and implementation. Our numbers are order-of-magnitude estimates, not a linear cost-per-multiply model.

[SoraSuegami]

Thank you for your reply!

TLOS is not a hash-only point function.

I understand your point. However, the fact that this is not a hash-only point function does not necessarily mean that TLOS is not a form of point-function obfuscation. More generally, when we discuss the gap between the work required for an honest evaluator and for an adversary in cryptographic primitives, I think it is important to focus on the capability asymmetry between them. In the TLOS setting, that asymmetry is that the honest evaluator knows the planted input before evaluating the obfuscated circuit, whereas an adversary can learn the planted input only after evaluating it a number of times. From this perspective, it seems reasonable to abstract the core of TLOS as point-function obfuscation.

Planted secret is not the same as the input secret. The planted secret s* is the puzzle witness derived off-chain. The input secret is the user preimage. They are related via hashing, but they are not the same object.

Thank you for the clarification. In what follows, let $x^{\star}$ denote the planted input that the adversary aims to find.
(Even with this difference, my argument still goes through as long as the planted LWE secret $s^{\star}$ can be uniquely and efficiently derived from $x^{\star}$.)

The goal of TLOS is to explore what can be achieved without such an oracle, namely public, offline-simulatable evaluation with purely cryptographic cost.

My understanding is that, unless we have a cryptographic primitive—such as witness encryption or iO—that verifies an Ethereum consensus proof and releases a secret only if a particular state has been reached on-chain, it is difficult to realize the kind of property we want. In the TLOS setting, an adversary can test whether a candidate input $x$ is the planted input without solving the PoW at all: given the LWE instance $(a,b)$, the adversary derives $s$ from the attempted input $x$ and checks off-chain whether $|b - \langle s, a\rangle|$ falls below a prescribed threshold. Therefore, it suffices for the adversary to solve the PoW only for the found planted input, and this cost is essentially the same as the honest user's cost (since both the honest user and the adversary only need to solve the PoW for a single input).

Commit-time randomness binding prevents precomputation

As I understand it, the PoW does not prevent precomputation for finding the planted input. It is true that the randomness forces the PoW to be solved only after the RANDAO value is revealed, but the LWE instance itself does not depend on the RANDAO randomness at all. Therefore, an attacker can use the LWE instance to find the planted secret (and thus the planted input) before the randomness is known, and then solve the PoW only once after the randomness is published.

P.S. On electricity costs, the scaling is not strictly linear. The dominant cost can be memory bandwidth and batching effects, so energy per guess varies with hardware, batch size, and implementation. Our numbers are order-of-magnitude estimates, not a linear cost-per-multiply model.

It seems plausible that, due to batching and related effects, energy consumption could increase with the number of attempted inputs $n$ at a rate that is sublinear in $n$. However, in that case, the computational gap between the honest user and the adversary becomes even smaller than in the linear-scaling case. As a result, the trade-off between the honest user’s computation time (UX) and the level of security one can guarantee becomes strictly worse. Concretely, to achieve the same UX and security as in the linear-scaling case, one would need to either relax the security target (i.e., tolerate a higher allowable attack success probability) or increase the input-domain size, in proportion to the reduction in effective computation cost due to batching.

[SoraSuegami]

The trade-off you describe is real, but there is a wide middle ground between "tiny" and "256-bit" secrets where the per-guess cost meaningfully stretches the attack timeline while keeping honest UX acceptable.

I analyzed this trade-off in a more general, implementation-independent way. The analysis suggests that improving the point-function obfuscation algorithm does not, by itself, improve the trade-off.

We define the following variables:

• $\varepsilon$: the (maximum tolerated) attack success probability threshold.
• $B$: the attacker’s benefit (payoff) upon a successful attack, measured in USD [$].
• $c$: the electricity price per unit energy, measured in USD per joule [$/J].
• $P_H$: the honest user's device power consumption, measured in watts [W] = [J/s].
• $E_H$ (resp. $E_A$): the energy cost of evaluating one input (one guess) for the honest user (resp. the adversary), measured in joules [J].
• $N$: the size of the input domain (number of possible inputs).
• $n$: the number of inputs (guesses) attempted by the adversary.
• $Q_A$: the total energy consumed by the adversary, measured in joules [J].
• $T$: the user’s computation time, measured in seconds [s].

We adopt the following assumptions.
Assumption 1: The adversary is given an obfuscated circuit $O_{x^{\star}}$ with a planted input $x^{\star}$. This takes as input $x$ and returns 1 if $x = x^{\star}$ and 0 otherwise. The obfuscated circuit $O_{x^{\star}}$ provides virtual black-box (VBB) security. This is the most idealized (and strongest) security notion: having access to $O_{x^{\star}}$ is computationally indistinguishable from having oracle access to an ideal trusted third party that, on a query input $x$, outputs $1$ if and only if $x = x^{\star}$ (and otherwise outputs $0$), while leaking no additional information.

Assumption 2: The planted input $x^{\star}$ is sampled uniformly at random from an input domain of size $N$. In practice, the sampling distribution may deviate from uniform. However, in that case there exist planted inputs that occur with relatively higher probability, and an adversary can prioritize those candidates; as a result, for any fixed target success probability, the adversary can find the planted input with fewer attempts than in the uniform case. Thus, the non-uniform sampling case only worsens the trade-off and need not be considered here.

Assumption 3: If the adversary succeeds in finding $x^{\star}$, they can obtain a benefit of $B$ from the application. Therefore, to guarantee security against an economically rational adversary, we require that the minimum computational cost—measured in electricity expenditure—needed to find $x^{\star}$ with success probability greater than or equal to $\varepsilon$ is at least $B$, i.e., $cQ_A \geq B$.

Assumption 4: We assume that the energy an adversary spends to evaluate the obfuscated circuit scales linearly with $n$, i.e., $Q_A = nE_A$. As discussed above, batching effects could in principle make the energy grow sublinearly in $n$, but that case only makes the UX–security trade-off worse and is therefore not essential to analyze here. It is also reasonable to idealize that the energy does not grow superlinearly in $n$: the adversary can provision $n$ identical devices in advance and evaluate the obfuscated circuit on $n$ distinct inputs in parallel, in which case—since the same algorithm is run on the same type of device—the average energy per evaluation can be treated as constant across devices.

Assumption 5: The adversary’s energy consumption per evaluated input is at most that of the honest user, i.e., $E_H \geq E_A$. This assumption is reasonable because, if the honest user’s device consumes less energy than the adversary’s, the adversary can always switch to the same type of device as the honest user—unless the application is restricted to honest users who secretly possess a particular low-power ASIC.

Assumption 6: The honest user’s device has a hardware-specified maximum power draw $P_H [W]$, which upper-bounds its instantaneous power consumption regardless of the algorithm being executed. Therefore, to consume energy $E_H [J]$ on that device, it must run for at least $T \geq \frac{E_H}{P_H} [s]$.

From the assumptions above, we can derive a bound on the trade-off—specifically, an inequality that lower-bounds $T$—via the following reasoning.

1. If the adversary tries $n$ distinct inputs, Assumptions 1 and 2 imply that the probability that one of them equals $x^{\star}$ is $\frac{n}{N}$. Therefore, any adversary who can find $x^{\star}$ with probability at least $\varepsilon$ must try more than or equal to $\varepsilon N$ inputs. Since the adversary aims to minimize its computational cost, we consider the tight case and set $n = \varepsilon N$ (up to rounding).

2. By Assumption 4. the adversary consumes $Q_A = nE_A = \varepsilon N E_A [J]$.

3. By, Assumption 3, it must holds that $B \leq c Q_A = c \varepsilon N E_A [\$]$, i.e., $E_A \geq \frac{B}{c \varepsilon N}$.

4. By Assumption 5, it follows that $E_H \geq E_A \geq \frac{B}{c \varepsilon N}$.

5. By Assumption 6, the time $T$ is lower-bounded by $T \geq \frac{E_H}{P_H} \geq \frac{B}{c \varepsilon N P_H} [s]$.

Therefore, we conclude that the lower bound on the honest user’s running time is determined solely by the application parameters $(B,\varepsilon,N)$, the user’s device specification $(P_H)$, and the electricity price $c$, and is independent of the concrete implementation of the obfuscated circuit. This result is also intuitively clear. For fixed $(\varepsilon, N, P_H, c)$, if we modify the algorithm so as to double $B$ by doubling the adversary’s per-input energy cost $E_A$, then the honest user must run the same algorithm and thus also incurs twice the energy cost, i.e., $E_H$ doubles as well. Since the device’s power draw is still bounded by $P_H$, the time required to expend $E_H$ joules on that device also doubles. If this conclusion does not seem to make sense to you, it would help move the discussion forward if you could point out which specific assumption or step in the reasoning above you believe is incorrect.

If we can agree on the model and conclusion above, then the next step, in my view, is not to modify the TLOS algorithm in a concrete way, but rather to plug in concrete parameters and simulate whether there exist practical $(B, T)$ pairs that satisfy the inequality above.

For example, when $N = 10^6$, $P_H = 30 W$, and $c$ is the lowest electricity price per unit energy in the US searched by chatgpt, the following figure provides the relation between $B$ and the minimum $T$ for $\varepsilon = 1\%, 5\%, 10\%$. This suggests that the honest user needs to take around 6 hours for protecting at most $\$1000$ with a $\geq 95\%$ probability.

[igor53627]

Your formalization clarifies the UX-security trade-off for low-entropy domains. The main question is whether our current layering lets an offline attacker amortize away PoW (i.e., do PoW only once after a cheap LWE/puzzle test), and what happens if we explicitly prevent that by wiring layers.

Your question pushed us to wire PoW into execution; we now consider this an improvement:
PoW-masked accept/reject (mask the accept/reject so PoW is required per guess):

• Keep the LWE instance fixed, but make the success signal depend on a PoW-derived value, so a candidate cannot be tested without first solving PoW for that candidate.
• Concretely: require a PoW nonce and derive a mask M = H(randao || input || solutionHash || nonce), then verify a commitment to the result bit (or to solutionHash) under M. The contract verifies PoW and the masked predicate; without PoW you cannot tell if a guess succeeds.
• If there is no side channel that reveals success without the mask, then an offline dictionary attack must pay one PoW per guess.

Attack cost implication (for uniform input):

• To reach success probability epsilon, an attacker needs n = ceil(epsilon * N) guesses, hence n PoW solves.
• Expected PoW solves until success (random ordering, no side info) is (N + 1) / 2.
• If any bypass lets an attacker test guesses without the mask, the PoW count collapses back toward 1 (only the winning input pays PoW).

Concrete example:

• If N = 1,000,000 and epsilon = 1%, then n = 10,000 PoW solves are required for 1% success. If a single PoW at difficulty D takes t_D seconds (measured), that is 10,000 * t_D seconds of work.

Concrete $ estimates (D=40, H200 measured 1.769e9 hashes/sec; $0.001261/sec; pricing: https://modal.com/pricing):

• Cost per PoW solve at D=40 ≈ $0.7839.
• For epsilon in {1%, 5%, 10%} (n = ceil(ε * N)), attacker cost:
  • N = 1M → 1%: ~$7,839 | 5%: ~$39,193 | 10%: ~$78,386
  • N = 10M → 1%: ~$78,386 | 5%: ~$391,932 | 10%: ~$783,864
  • N = 100M → 1%: ~$783,864 | 5%: ~$3,919,319 | 10%: ~$7,838,639
  • N = 1B → 1%: ~$7,838,639 | 5%: ~$39,193,194 | 10%: ~$78,386,389
• Expected cost to find the secret (random order) is ~N/2 solves; multiply the 1% line by ~50×.

Practical note (UX + economics):

• With D=40, a single PoW solve costs ~$0.78 on H200. It’s a non-zero per-try price; acceptable for recovery or infrequent user flows if you allow delegated solving. The solver can be trusted or self-hosted by users (Modal is a practical example). Delegation shifts the honest-user UX from “minutes of local compute” to “seconds of remote compute” at a predictable dollar cost, while keeping a meaningful per-guess cost for attackers.

Experiment update (Modal H200):

• Implemented Keccak256 PoW exactly as in GuardedLWE and measured hashes/sec and time-to-solve for difficulties D = 24, 32, 40.
• PR includes the benchmark code and updated economics tables: Update PoW benchmarks and mitigation #79

If you’re open to it, could you review the PoW-masked accept/reject approach for side channels or flaws?

[igor53627]

P.S. Correction/clarification: The PoW-masked accept/reject only raises offline cost if every success signal is masked and there is no public side channel to test guesses without PoW. In the current static on-chain puzzle setting, an offline attacker can verify guesses directly from the public (A, b) and ignore PoW, so the per-guess cost remains unchanged unless the verification key or success predicate itself depends on the PoW.

[igor53627]

Subject: Update: Mitigation for Offline GPU Dictionary Attacks via Layer 6 (Memory-Hard Function)

Hi there,

We have implemented a significant architectural upgrade to mitigate offline dictionary attacks, specifically targeting high-end GPU clusters (e.g., NVIDIA H100/H200).

The Solution: Layer 6 (EVM-Optimized MHF)

We introduced a Memory-Hard Function (MHF) layer that runs before the LWE circuit evaluation. This layer forces the derivation of the circuit secret to be memory-bound rather than compute-bound.

• Algorithm: Keccak-256 state loop with Pointer Chasing.
• State Size: 3 MB (98,304 words of 32 bytes).
• Logic:
  1. Sequential Fill: Fill 3MB buffer with hash chain.
  2. Random Read Mixing: Perform 98,304 iterations where address j depends on hash(previous_value).

Why 3 MB?

The NVIDIA H200 has a 256 KB L1 Data Cache per SM. A 3 MB state per thread forces massive cache spills into the shared L2 (80 MB) and eventually the global HBM3e memory when running thousands of parallel threads. This introduces significant latency bubbles that cannot be hidden by compute throughput.

Real-World Benchmarks (NVIDIA H200)

We benchmarked this implementation on an H200 node via Modal.

• Throughput: ~6.2 Billion mixing ops/sec (global GPU).
• Effective Guess Rate: ~36,000 guesses/second (vs >20 Billion for raw Keccak).

The "40-Bit" Example (Why this matters)

40 bits of entropy (e.g., a 4-word random phrase like correct horse battery staple) is cryptographically "extremely low"—equivalent to the broken US Export Grade crypto of the 1990s. Without MHF, an H200 can brute-force a 40-bit space in milliseconds.

With the 3MB MHF:

• Time to Crack: ~320 Days on a single H200.
• Estimated Cost: ~$35,000 (at $4.54/hr Modal H200 pricing).

While 40 bits remains theoretically vulnerable to a funded adversary, the MHF successfully transforms a "trivial/free" attack into a significant economic cost.

For 1 Billion Guesses (~30 bits):

• Time: ~7.7 hours.
• Cost: ~$35.

Can this be bypassed?

No. The architecture ensures there are only two ways to recover the secret:

1. Solve the LWE Lattice Problem: This requires breaking the underlying math ($\sim 2^{112}$ operations), which is computationally infeasible with current or near-future hardware.
2. Guess the Secret (Dictionary Attack): This forces the attacker to generate the candidate LWE vector $s$ from their guess. Since $s = \text{MHF}(\text{guess})$, the attacker must execute the full 3MB memory-hard loop for every single guess to validate it against the puzzle.
   • The "Random Read" loop creates a serial dependency chain (next_address depends on previous_value), preventing the GPU from "looking ahead" or pre-fetching memory.
   • There is no mathematical shortcut to predict the output of the Keccak-MHF without executing it.

The Trade-off: Gas Cost

To enforce this barrier, legitimate users must pay for the memory expansion and hashing on-chain.

• Total Transaction (64 gates + MHF): ~48 Million Gas.

Verification

You can verify these results using the new benchmark suite included in the PR:

• tests/gpu_benchmark/mhf_attack.cu (CUDA kernel)
• tests/gpu_benchmark/run_modal.py (Modal deployment script)

Code changes are live in contracts/libraries/LibMHF.sol and TLOSWithPuzzleV5.sol.

[SoraSuegami]

Thank you for your feedbacks and updates.

My understanding is that this new idea can more reliably increase the adversary's time per attempted input by amplifying the data-transfer overhead in memory rather than the computation itself. Therefore, in applications where the attacker faces not only a cost constraint but also a time constraint, this idea would be useful.

However, this still increases the per-input energy consumption not only for the adversary but also for the honest user. Therefore, while this idea can raise the acceptable attack benefit $B$ (i.e., security), it also increases the honest user’s runtime $T$ (i.e., UX) accordingly, so it does not improve the UX–security trade-off represented by $T \geq \frac{B}{c\varepsilon N P_H}$.

[SoraSuegami]

If we want to achieve security beyond $1000 against small-domain inputs while keeping the user’s computation time within a few seconds, then—although it depends on other variables as well—it seems to me that, in many cases, we would need a new idea that amplifies the ratio between the honest user’s and the adversary's required work by more than a constant factor of the input-domain size.