QSCS Trust Layer

Implicit Trust at Session Establishment

Hashed UUIDs and Pre‑Encryption Identity Binding

Before any encrypted traffic flows, before any delta is validated, and before the state machine sees a single bit, QSCS establishes a pre‑cryptographic trust anchor using hashed UUIDs.

This is the moment where the daemon decides: is this a legitimate client, is this session allowed to begin, and should this connection be upgraded to encrypted QSCS traffic?

This is not authentication.
This is identity anchoring.

1. Hashed UUIDs as Pre‑Encryption Identity Anchors

Every QSCS client begins with a Hashed UUID, generated locally and never transmitted in raw form.

The hash is one‑way, non‑reversible, non‑enumerable, non‑guessable, and bound to the client's Trust Certificate.

The daemon never sees the UUID. It sees only the hash, which is used to identify the client, bind the session, prevent spoofing, prevent replay, and prevent unauthorised session establishment.

This is the first layer of trust — implicit, not negotiated.

Client UUIDv4 (raw, local) SHA‑512(UUID) → hash hash only ✕ raw UUID never transmitted Daemon verify hash trust anchors One‑way, non‑reversible, non‑enumerable — the first layer of implicit trust

2. Why This Happens Before Encryption

Traditional systems do this backwards: open a socket, negotiate TLS, authenticate, then decide if the client is allowed.

QSCS flips this: the client presents a hashed UUID, the daemon verifies it against known trust anchors, and only then is the session upgraded to encrypted QSCS traffic.

This eliminates anonymous TLS handshakes, unauthenticated connection attempts, probing, scanning, and handshake‑level attacks.

The daemon does not negotiate encryption with unknown entities.
It negotiates encryption only with trusted identities.

Traditional Model 1. Open socket 2. Negotiate TLS 3. Authenticate 4. Decide if allowed Anyone can reach step 2 Attack surface: steps 1–3 → QSCS Model 1. Present hashed UUID 2. Verify trust anchor 3. TLS upgrade 4. Trust cert exchange Unknown entities never reach step 2 Attack surface: zero

3. Why QSCS Cannot Allow Anonymous TLS Handshakes

Even though TLS is encrypted, the handshake itself exposes structure: cipher suite negotiation, protocol versions, packet sizes, timing patterns, and other metadata that reveal the presence and behaviour of a service.

In traditional systems this is acceptable. In QSCS it violates the core guarantee: no visible structure.

To prevent handshake‑level probing and metadata leakage, QSCS requires a pre‑encryption trust anchor. Only clients with a valid hashed UUID may initiate the TLS upgrade. Unknown entities never reach the handshake at all.

Traditional TLS Handshake cipher suite negotiation → visible protocol versions → visible packet sizes · timing → visible structure exposed before encryption → QSCS Pre‑Encryption Gate hashed UUID verified first no structure exposed unknown entities see nothing

4. Implicit Trust vs Explicit Trust

QSCS has two layers of trust:

Implicit Trust (Session Establishment)

Hashed UUID, pre‑encryption identity anchor, session binding, anti‑spoofing, anti‑replay, and anti‑enumeration. This determines who may speak at all.

Explicit Trust (Delta Validation)

Trust Certificates, provenance, admissibility, structural validation, and deterministic constraints. This determines what they may say.

Implicit trust opens the door.
Explicit trust governs the conversation.

Implicit Trust Session Establishment hashed UUID pre‑encryption identity anchor anti‑spoofing anti‑replay Who may speak Explicit Trust Delta Validation Trust Certificates provenance · admissibility structural · deterministic What they may say Implicit trust opens the door — explicit trust governs the conversation

5. Why Hashed UUIDs Are Not "Secrets"

A hashed UUID is not a credential. It is not a password. It is not a token.

It is a non‑reversible identity anchor used only to bind the session, prevent anonymous negotiation, prevent spoofing, and prevent handshake abuse.

Even if intercepted, it is useless, non‑replayable, non‑enumerable, not tied to any transition, and not tied to any state.

It cannot be used to impersonate a client. It cannot be used to submit deltas. It cannot be used to gain access.

It is simply the first handshake.

6. The Flow

Client hashed UUID Daemon check trust anchor valid ✓ Session established TLS upgrade Trust Certificate exchange Delta provenance + admissibility Deterministic State Machine ✕ invalid no TLS no negotiation no handshake no response daemon does not exist

If the hashed UUID is not recognised: no TLS, no negotiation, no handshake, no error message, no response. The daemon simply does not exist to that client.

7. Why This Matters

This mechanism gives QSCS zero anonymous connections, zero handshake surface, zero TLS probing, zero unauthorised negotiation, zero pre‑auth attack surface, and zero metadata leakage.

It is the first line of trust, and it happens before any traditional security mechanism even activates.

QSCS Trust Guarantees zero anonymous connections zero handshake surface zero TLS probing zero unauth negotiation zero pre‑auth surface zero metadata leakage First line of trust — activates before any traditional security mechanism