Attacker goal: Forge Alice's signature on "DELETE all edits"

Attack attempt:
1. Attacker gets Alice's public key (vk_alice) [public]
2. Attacker tries to forge Dilithium signature
   - Must find (c̃, z) such that Verify(vk_alice, msg, (c̃, z)) = accept
   - Requires solving Module-LWE: find short vector in lattice
   - Module-LWE is NIST-hard: 2^256 operations minimum
3. Attacker computes for 100 years... still can't forge

Result: ✗ IMPOSSIBLE for all practical purposes

Operation format in FNP:

{
  site_id: "alice@example.com",
  operation_id: 42,           ← unique per Alice
  lamport_clock: 1000,        ← monotonically increasing
  timestamp: 2025-11-28T10:00Z,
  content: "Hello",
  position: (1.5, "alice", 42),
  signature: DILITHIUM_SIG
}

Replay attack scenario:
1. Attacker captures operation #42 (INSERT "Hello" at 1.5)
2. Attacker sends it again next week
3. Server checks: operation_id 42 from alice@example.com
4. Server has: "operation 42 already applied" [deduplication log]
5. Server rejects: ✗ Duplicate operation

Prevention:
- Each site_id maintains monotonic operation_id (like Lamport clock)
- Server stores: {(site_id, operation_id) → timestamp}
- Replayed operation: operation_id is old → rejected

Delete operation structure:

{
  type: "DELETE",
  position_id: (2.0, "alice", 100),  ← Which edit to delete?
  deletion_timestamp: 1001,
  signer: "alice@example.com",
  signature: DILITHIUM_SIG
}

Security properties:
1. Only Alice can delete Alice's edits (her signature required)
2. Delete is timestamped and signed (audit trail)
3. Tombstone remains: (2.0, "alice", 100, visible: false)
4. Bob/server can verify: "Alice deleted this, not server error"

Attack scenario:
- Attacker: "Alice wants to delete all her edits"
- Attacker sends: DELETE messages for all alice edits
- Problem: No Dilithium signature (attacker doesn't have alice's secret key)
- Server: ✗ Rejects all unsigned deletes

Result: Only Alice can delete Alice's edits (cryptographically enforced)

LSEQ position generation (unpredictable):

position = (base_seq, site_id, clock)

where:
- base_seq: derived from parent position + random bits
- site_id: Alice_ID (constant, unique)
- clock: Lamport timestamp (increases, not guessable)

Collision attempt:
- Attacker wants to create operation at same position as Alice's #100
- Alice's position: (1.5, "alice", 100)
- Attacker generates position: (1.5, "alice", 100)
- Problem 1: Can't use site_id "alice" (attacker is "malicious_replica")
- Problem 2: Even with different site_id, positions compare by (level, digits)
- Problem 3: Parent-based generation means previous history matters

Result: ✗ Position collision requires breaking LSEQ generator

Server-side verification:

Received operation from Alice:
{
  lamport_clock: 1000,
  operation_id: 42
}

Server's state:
{
  last_lamport_from_alice: 999,
  last_operation_from_alice: 41
}

Check:
if (lamport_clock <= last_lamport_from_alice):
  reject("Clock didn't advance—replay or out-of-order")

if (operation_id <= last_operation_from_alice):
  reject("Operation ID didn't advance—replay")

if (lamport_clock != last_lamport_from_alice + 1):
  mark("Gap in clock—acceptable with offline edits")

Accept operation and update:
{
  last_lamport_from_alice: 1000,
  last_operation_from_alice: 42
}

Result: ✓ Prevents replay and out-of-order operations

Scenario: Two evil servers collude to reorder operations

Evil replica 1: "Reorder edits: (1.0, 'x') then (2.0, 'y')"
Evil replica 2: "Reorder edits: (2.0, 'y') then (1.0, 'x')"

Result when merging:
- CRDT commutativity check: sort positions by (level, digits)
- Position 1.0 < 2.0 always
- Merge produces: (1.0, 'x'), (2.0, 'y')
- Both replicas converge to same order
- Colluding attempt failed!

Why? Positions are immutable after insertion (no "reordering" in CRDT)