Squyr.
Bilateral Cryptographic Data Exchange
Eight-step protocol breakdown. Cryptographic primitives. Bilateral exchange flow. Key rotation and hash-chain audit.
Raw identifiers are normalized — phone numbers to E.164 format, emails to lowercase and trimmed. Both parties produce identical hashes from identical underlying identifiers.
◣ E.164 · RFC 3966Each normalized identifier is hashed with SHA-256 client-side. Output is the only data that will be exchanged — never the raw identifier. One-way function; cannot be reversed.
◣ FIPS 180-4 · RFC 6234A derived key is computed using HKDF-SHA256 over the Sender's master, the Recipient's public commitment, and a per-segment salt. Unique to this exchange. Neither party derives alone.
◣ HKDF-SHA256 · RFC 5869Each SHA-256 hash is encrypted with AES-256-GCM using the derived key + unique nonce + segment metadata as AAD. Output is a wrapped token with no recoverable identifier information.
◣ AES-256-GCM · FIPS 197 · NIST SP 800-38DThe Sender signs the bundle metadata with Ed25519. The signature proves origin and integrity. 64-byte deterministic signature. 10× faster than RSA-2048.
◣ Ed25519 · RFC 8032Signed, wrapped bundle is transmitted over mutual TLS 1.3. Both parties authenticate. No plaintext passes between environments at any point in the protocol.
◣ mTLS 1.3 · RFC 8446Recipient verifies Ed25519 signature against the Sender's registered public key. Bundle integrity confirmed. Any tampering is detectable — failed verification terminates the exchange.
◣ Ed25519 Verify · RFC 8032Recipient locally derives the session key using their own master material and the Sender's public commitment + segment salt. Wrapped tokens unwrapped bilaterally. Hashes matched against partner cohort.
◣ HKDF · AES-256-GCM · RFC 5869Salts rotate automatically. Master material rotates on a configurable schedule — typically 90 days — with on-demand rotation supported.
Both parties contribute key material. Neither side can unilaterally decrypt the exchange. No third-party middleware required.