Posts

Vitalik Buterin recently shared a concise yet profound framework for thinking about security. At its core, the argument is deceptively simple: security is about minimizing the divergence between the user’s intent and the actual behavior of the system. But the implications ripple far beyond what that one sentence might suggest. This post distills and extends the key ideas from his thread. I. Security and UX Are the Same Problem Under this definition, “user experience” and “security” collapse into a single spectrum. Both ask the same question: does the system do what the user actually wanted? ...

In traditional financial risk control, we analyze “people”—individuals or legal entities with names, ID numbers, and credit histories. But in the on-chain world, we face “addresses”—strings of 42 hexadecimal characters. The chasm between address and identity, between transactions and behavior, is the core battleground for Web3 risk control. I. The Nature of Addresses: Pseudonymity and the Identity Dilemma 1.1 What Could Be Behind an Address? When we look at an Ethereum address like 0x28c6c06298d514db089934071355e5743bf21d60, it could represent: ...

In our previous blog, we explored differential privacy (DP) for protecting retrieval patterns. While DP adds controlled noise to provide plausible deniability, it doesn’t provide cryptographic guarantees. Today, we introduce Private Information Retrieval (PIR) - a cryptographic primitive that ensures the server learns absolutely nothing about which documents you’re retrieving. The Query Privacy Problem Consider a scenario where you’re using a RAG system hosted by a third party: ┌─────────────────────────────────────────────────────────────────┐ │ Standard RAG Retrieval │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ User Server │ │ │ │ │ │ │ "Query: cancer treatment" │ │ │ │─────────────────────────────>│ │ │ │ │ Server sees: │ │ │ │ - Your query │ │ │ │ - Which docs match │ │ │ │ - Your access patterns │ │ │ │ │ │ │ Returns: Documents 3, 7, 12 │ │ │ │<─────────────────────────────│ │ │ │ │ Problem: Server learns sensitive information about user! │ └─────────────────────────────────────────────────────────────────┘ This reveals potentially sensitive information: ...

> As a security researcher who has played CTFs for many years, the first time I encountered prompt injection, a strong sense of familiarity hit me immediately — *isn’t this the “spiritual successor” of SQL injection?* Introduction In 2023, LLM Agents began to be deployed at scale. From customer service bots to coding assistants, from data analysis to office automation, AI agents are rapidly taking over an increasing number of tasks. At the same time, security risks are emerging alongside this adoption. ...

1. Motivation In a finite cyclic group $$G = \langle g \rangle, \quad |G| = n$$The discrete logarithm problem (DLP/ECDLP) is formalized as: **Given $g$ and $y = g^x$, find $x \bmod n$. The secret key $x$ has domain $\mathbb{Z}_n$ Because $g^n = 1$, we have: $$g^x = g^{x \bmod n}$$This means: The secret key space is at most the size of the group $n$. The basic attack is to enumerate $x \in {0, \ldots, n-1}$ ...

1. Background and Core Concept Gasper is the sub-protocol responsible for deterministic finality in Ethereum’s PoS consensus. Its core objectives are: To continuously advance Justification and Finalization of the chain when the majority of honest participants are online; To form a probabilistically secure chain selection through honest majority voting when forks exist. However, if an attacker controls: Close to 1/3 of the voting power; The ability to delay attestation broadcasts (i.e., temporary network inconsistency); They can create the following situation: ...

In Ethereum’s PoS Gasper consensus, “Checkpoint justification” is one of the core components of chain security: Only when at least 2/3 of active validators in an epoch submit attestations pointing to a certain checkpoint will that checkpoint be “justified”. The Justification withholding reorg attack exploits a vulnerability in this mechanism: Attackers deliberately prevent the honest chain from collecting enough attestations, keeping the honest chain from justifying checkpoints. Meanwhile, the attackers secretly build a hidden chain and accumulate sufficient attestations. Once the timing is right, they release the hidden chain all at once, directly reorganizing an entire epoch of blocks from the honest chain. ...

Ethereum now uses a Proof-of-Stake (PoS) consensus mechanism called Gasper. Gasper integrates two protocols: Casper the Friendly Finality Gadget (FFG), a protocol ensuring the finality of transactions; and a modified version of the Greedy Heaviest-Observed Sub-Tree (HLMD GHOST) for selecting the canonical chain. In the unrealized justification reorg attack, the attacker manipulates the justified update of checkpoints to alter the “filtered/visible” view of the block tree for honest nodes. Specifically, the attacker creates and publishes a branch containing a new checkpoint, causing honest nodes to filter out the original branch (which is canonical according to weight) from their local fork-choice viable space, thereby achieving reorganization or blocking finality. ...

In this article, we expand on Reorg Attacks once again. We mainly analyze how Reorg Attacks are launched in the Ethereum PoS Protocol and identify the vulnerable points where attacks can be launched. Before this, combined with our previous meeting discussions, it is necessary to first review the Ethereum PoS Protocol to help us reach consensus on fundamental knowledge. I. Preliminaries 1.1 Gasper Ethereum now uses a Proof-of Stake (PoS) consensus mechanism called Gasper. Gasper integrates two protocols: Casper the Friendly Finality Gadget (FFG), a protocol ensuring the finality of transactions; a modified version of the Greedy Heaviest-Observed Sub-Tree (HLMD GHOST) for selecting the canonical chain. ...

Core Objective Core Purpose: The goal of the attack (by Byzantine validators) is not to break the system (such as double-spending), but rather to manipulate block publication and voting so that their “privately held” block (b₁) defeats an honest block (b₂), thereby becoming the main chain. Ultimate Gain: By making the honest b₂ block become “orphaned,” Byzantine validators can “steal” the block rewards that should have belonged to the b₂ proposer, thus obtaining “higher rewards.” ...