L0 security limits and threat grades

Evidence level: Implemented capability for the current CoNET-SI forwarding plane; design study for listed upgrades that are not in SI main.

This page states what Layer Minus actually protects. It answers common over-claims: Fetch-and-Close is not an anonymity protocol; Chat SSE is a traffic fingerprint; long-term user OpenPGP keys do not provide forward secrecy; a valid EOA signature does not by itself stop replay; A/B/C role names are not independent operators.

L0 remains a permissionless decentralized cloud whose live wire is a PGP / wallet-address forwarding network. Any node may be malicious. Stronger privacy modes are application compositions (privacy routing + fragmentation + client crypto) unless SI implements them.

Public source for the live plane: CoNET-project/CoNET-SI.

Fetch-and-Close is a short-session mode

Fetch-and-Close is optional:

select an entry → send one bounded request → receive a bounded response → close

It can reduce:

• long-lived connection duration;
• a fixed tunnel fingerprint;
• single-connection bidirectional volume statistics;
• long-term binding to one entry;
• a continuous network identity at one exit;
• the window during which one connection can be monitored.

It cannot remove:

• the set of entry IPs a client uses;
• request time;
• packet or ciphertext length;
• request frequency;
• periodic polling;
• a stable client or TLS fingerprint when HTTPS is used;
• correlation of adjacent requests;
• the bandwidth curve of a large download;
• global entry–exit matching by a well-placed observer.

The current book already treats Fetch-and-Close as optional. Chat and mining use long-lived SSE. UDP client and server listens are also SSE. Browsers may reuse HTTP/2 connections. Browser pooling, caching, and OS behavior can break a “new connection per resource” assumption. Those effects must be measured, not inferred from the design.

Grade: Fetch-and-Close lowers persistent-flow features. It is not a traffic-anonymity protocol. Size padding and timing jitter are not implemented.

Outer envelope and nested PGP hops

Byte-level freeze: X-CoNET-Hop-Sigs v1. The header is a compact miner signature used to meter forwarded bytes. It is not a public HopRecordV1 itinerary (messageId, inner/outer hashes, previous-hop hash, hopIndex). That extra JSON would let a path observer reconstruct the forward chain.

SI routing is not limited to “one key ID, never decrypt.” After a local decrypt once:

1. If the plaintext is still OpenPGP armor, read the inner getEncryptionKeyIDs().
2. If that inner key ID is this node's route PGP, treat it as an attack: emit socket end and stop. Do not peel again on the same node.
3. If the inner key ID is not this node, read SI-to-SI X-CoNET-Hop-Sigs. More than 3 hop signatures (or a count that cannot take another hop) is an all-node flood: emit end and do not forward. The packet is discarded.
4. Otherwise forward the inner armor and append this node's miner hop signature. When the destination SI ends the socket, the previous hop closes and frees that connection.
5. If the plaintext is signed JSON { message, signMessage }, the last hop verifies hop signatures, meters those prior-hop bytes against the user wallet for GB, and runs the API command (listen, proxy, storage, WASM / container, and so on).

The client POST /post body is only OpenPGP armor and must not carry X-CoNET-Hop-Sigs. If the outer key ID is not a routable node / mailbox, A responds 404. A then miner-signs and forwards to B; B sees the header because A created it.

Loop protection

A loop that never reaches a valid recipient inside 3 miner signatures is discarded. A → D → A or A → D → E → D cannot complete a useful delivery or invent GB. The protocol therefore does not publish a previous-hop hash chain.

Adjacent and header checks already stop the useful cases:

• inner key ID equals this node → end;
• this miner wallet already appears in the hop list → refuse append;
• hop count already 3 → end.

There is one budget: 3 miner signatures. Do not add a second maxPeels / maxForwardHops pair.

An application can wrap a user-PGP business message to entry A, or use a short hop chain. A first-hop path observer then sees the outer key ID, not R's. Each peel node still learns the next key ID, time, and size. Extra hops are extra GB. This is not a mix network and does not replace padding.

Current Chat clients may still post a single user-PGP layer (A forwards without decrypting when the key maps to a mailbox). The peel rule is available to any client that wraps.

Chat SSE is a primary L0 traffic fingerprint

DePIN Chat’s recipient opens a long-lived HTTP/SSE listen through entry C (command: "mining", listenKind: "chat"). Mining collectors and UDP listens also keep SSE sessions.

An ISP or entry C can observe:

• a long-lived HTTP/SSE;
• disconnect and reconnect;
• liveness heartbeats;
• a downlink push pattern;
• active hours;
• traffic peaks;
• online / offline cadence.

Content remains OpenPGP-encrypted. Metadata can still support inferences about when a user is online, how often messages arrive, device sleep/wake, and that a chat-like application is in use.

Receive modes

Do not set every client to the same fixed poll period if a poll mode is added later — that creates a new sync fingerprint. Current SI mailbox delivery is store-then-push over SSE.

Long-term user OpenPGP is not forward-secret

Business messages are encrypted to the recipient’s registered user OpenPGP public key. OpenPGP typically creates a per-message symmetric session key and wraps that key to the long-term recipient public key.

If that long-term private key is later compromised, an attacker who stored earlier ciphertext may decrypt it. The live model therefore provides:

• confidentiality against nodes that lack the user private key;
• sender authentication when the outer EOA signature verifies;
• a per-message random session key wrapped by the long-term key.

It does not currently specify or implement:

• forward secrecy for stored Chat ciphertext;
• post-compromise security;
• Double Ratchet;
• automatic session-key rotation after first contact;
• MLS group messaging (RFC 9420).

Encrypted Chat history (IPFS fragments + ChatIndexRegistry) is likewise keyed from long-term EOA/OpenPGP material. Compromise of that authority can expose recoverable history.

Chat crypto profile (roadmap)

Acknowledging the gap does not raise the live grade. Until a later profile ships, do not describe Chat as forward-secret.

AddressPGP remains the wallet identity, offline discovery, mailbox route, initial handshake, and session-recovery root. On-demand new wallets reduce future correlation after a leak; they do not decrypt-protect already captured V1 armor.

HTTP versus HTTPS (neither is “more private”)

The /post body is only OpenPGP ciphertext. Confidentiality of business content does not come from TLS. That does not mean “HTTP is more private than HTTPS.”

Carrier decision

Protocol rule: both HTTP and HTTPS are valid client carriers. SI-to-SI stays HTTP :80. Do not advertise plain HTTP as the default privacy mode for every environment.

Plain HTTP allows active path attacks

OpenPGP and EOA signatures stop a path observer from quietly rewriting plaintext. They do not stop an HTTP observer from:

• dropping or delaying packets;
• replaying an old request;
• injecting a false HTTP status;
• returning a fake entry response;
• blocking a recipient key ID;
• classifying by key ID;
• forcing client retries;
• measuring whether a mailbox accepted a copy.

checkSign in CoNET-SI recovers the EOA from personal_sign(message) and checks it against walletAddress. That is authentication of that exact string, not a consumed-nonce store. X-CoNET-Hop-Sigs is also not an anti-replay store — it meters miner-forwarded bytes (hop-sigs v1).

Partial anti-replay exists only on some route-key commands:

A correct EOA signature therefore does not automatically reject a previously valid message. Replaying the same valid armor to entry 1, 2, and 3 can duplicate mailbox store, push, APNs, or application handling unless the application consumes an id.

Required application bindings (normative for payments / POS / control)

Do not put a full L0SignedObjectV1 on the hop header. That would publish messageId / payloadHash to every SI hop.

Non-idempotent application objects (payments, POS authorization, AA / Treasury control, spend) must bind at least messageId, nonce, timestamp / expiry, senderWallet, recipientWallet, commandType, payloadHash inside the encrypted application object, and persist consumed identifiers at the consumer:

Do not treat TLS, HTTP 2xx, checkSign, or hop-sigs alone as that store.

TLS 1.3 0-RTT (not used by the HTTP-first path)

If a future Fetch-and-Close client uses TLS 1.3 0-RTT for performance, 0-RTT has no inherent anti-replay (RFC 8446). Non-idempotent operations must still consume application nonces.

Mailbox isolation fails under collusion

A/B/C separation prevents an ordinary mailbox from seeing the client’s direct IP. It is a role split, not a proof that A, B, and C are independent operators.

L1 has no public operator-domain census equivalent to the DLE OperatorDomainRegistryV1 specification. Clients today pick healthy entries; SI does not enforce “this operator must not be both entry and mailbox on one path.”

Proposed operator hygiene (not implemented on L0)

• Same operator domain must not be both entry and mailbox on one path.
• Clients check an operator-domain signal before selecting A/C.
• Diversify by ASN, cloud, and region.
• Rotate mailboxes.
• Publish independence metrics.
• Challenge and slash correlated multi-wallet operators.
• Remember recent path triples locally and avoid immediate reuse.

Until those exist, treat A/B/C as correct use of roles, not as multi-operator anonymity.

UDP forward: cryptography vs native UDP

The cryptographic split is sound and implemented:

• session AES key is encrypted only to the UDP server user PGP;
• mailbox B must not receive that key;
• route commands must not carry Securitykey;
• frames are AES-256-GCM;
• client and server should reach B through different entries;
• UDP pools are separate from chat/mining.

UDP forward is not native UDP. It is HTTP request plus SSE. It does not automatically provide UDP timing, congestion control, retransmission, delivery ACK, application-consumption proof, packet ordering, or low-jitter realtime performance.

Mailbox B still sees sessionId, client and server wallets, frame timing and size, direction, and session duration. That metadata can classify VoIP-like, game-like, or sensor-like use even when payloads stay encrypted.

Implemented bounds: 12,000-character payload, ±600 s timestamp, session-count caps, 10-minute idle sweep, downlink seq for SSE writes.

Proposed UDP hardening (not implemented)

Sequence numbers with a replay window, padding buckets, optional constant-rate mode, application ACKs, rekey, and tighter per-session byte limits. Document these as upgrades, not as the live relay.

Wallet identity is a correlation paradox

A wallet solves problems IP cannot: cryptographic ownership, mobility without renaming the peer, and accounts that are not issued by a platform.

A long-lived wallet used for Chat, POS, Beamio, mining, L1 transfers, DLE, BT, Treasury, and public social identity becomes a stable join key. Observers can build wallet → chat activity → payments → services → social graph.

A wallet is more autonomous than an IP. It is not automatically harder to correlate than an IP.

Layered identities (application, not L0)

L0 will forward whatever key ID it is given. Isolation is an application registration policy.

Available now: use a routing wallet for AddressPGP, listen, ACK, presence, and hop GB, and keep sender / recipient EOAs only inside the encrypted envelope. Mailbox B does not need the payment or display wallet. How to wire it: wallet-addressed peer identity.

Master wallet
  ├── Routing wallet     ← mailbox + listen + GB (what B sees)
  ├── Chat / display
  ├── POS
  ├── BT session
  ├── DLE payment
  └── Temporary network

This does not hide an on-chain gas or token transfer from master → routing wallet. Putting both addresses in one plaintext command or hop header undoes the split. Delegation proofs, stealth addresses, or ZK membership are not L0 features.

Current L0 threat grades

Grades describe the current SI + intended A/B/C client path, not a future ratchet, poll mode, or operator registry.

What applications must not claim

• Fetch-and-Close as mix-net or anonymity.
• Chat SSE as metadata-private presence.
• OpenPGP-to-AddressPGP as Double Ratchet / MLS (that is Chat crypto V2/V3, not live V1).
• checkSign or X-CoNET-Hop-Sigs as anti-replay for payments or POS.
• A detailed hop JSON (HopRecordV1) as required for loop safety — the cap is 3 miner signatures, then discard.
• HTTP as “more private than HTTPS.”
• A/B/C as independent-operator anonymity.
• UDP forward as native realtime UDP.
• One wallet as an unlinkable identity across products.

Implementation anchors

• Entry HTTP/HTTPS and { data } POST: CoNET-SI server.ts
• Key-ID forward and checkSign: CoNET-SI localNodeCommand.ts
• Mailbox append store: saveLocal in CoNET-SI util.ts
• UDP bounds: CoNET-SI udpForward.ts
• Chat listen composition: DePIN Chat

Next

• How to use Layer Minus — compose only the primitives that exist.
• X-CoNET-Hop-Sigs v1 — compact miner hop encoding and failure codes.
• HTTP transport and Fetch-and-Close — short-session carrier.
• Zero-trust mailbox routing — A/B/C roles.
• Wallet-addressed peer identity — key roles and reuse risk.
• UDP frame forwarding — AES split and remaining metadata.