Open Protocol · v1.0

Squyr

Bilateral Cryptographic Data Exchange

Healthcare patient identifier exchange without PII transit. Raw data never leaves brand environment. No vendor middleware.

HIPAA FIPS 140-2 BAA Compatible SOC 2

Architecture

Wire · 9c8f82ac508b…73d6

Identifier hashing in the partner's browser. Encrypted tokens transit. Raw data never leaves the originating environment.

RAW IDENTIFIER
normalize (E.164 / lowercase)
SHA-256 HASH
AES-256-GCM WRAP
Ed25519 SIGN
mTLS 1.3
↓ BILATERAL DATA FLOW ↓
mTLS 1.3
VERIFY SIGNATURE
AES-256-GCM UNWRAP
HKDF KEY DERIVE
MATCH COHORT
Security Stack
SHA-256 AES-256-GCM HKDF-SHA256 Ed25519 / RFC 8032 mTLS 1.3
15.3M Tx-verified

No PII on the wire. Both parties contribute key material. Neither side can unilaterally decrypt the exchange. Key material derives from both environments — bilaterally.

What Squyr Is

A clean-room-native primitive
for pharma audience data partnerships.

Squyr is a cryptographic protocol for exchanging healthcare patient identifiers between two parties without either side transmitting personally identifiable information. The primitives are standard. The architecture is what's distinctive.

Primitives

Standard RFCs. FIPS-compliant.

SHA-256, HKDF-SHA256, AES-256-GCM, Ed25519. All FIPS 140-2 compliant. All published RFCs. Compatible with standard identity infrastructure (Epsilon, LiveRamp, DSPnative).

Bilateral

No third-party middleware required.

Both parties contribute key material. Neither side can unilaterally decrypt the exchange. No credential pool, no central data store, no operational dependency on a vendor.

Compliance

HIPAA Safe Harbor framing.

Developed to stay compliant with HIPAA, BAA constraints, and state-level health privacy regulations. Identifiers hashed client-side before any exchange occurs.

Runtime

Web Crypto API · Browser-native.

All cryptographic operations run in the browser via Web Crypto API. Synthetic patient data in demos — real cryptographic operations. No network calls during hashing phase.

Three things to know

Bilateral by design.

01

Identities never cross.

Raw phones, emails, or other PII never move between systems. Hashes derive from identical underlying identifiers in both environments — bilaterally, not centrally.

02

No third-party dependency.

No credential pool, no central data store, no operational dependency on a vendor for the exchange to function. Both parties hold their own key material and derive locally.

03

30-day in-flight grace period.

Master key rotation is configurable (typically 90 days on-demand). In-flight bundles complete within a 30-day window using the key that was current when transmission began.