This page is a technical walkthrough of what version 0.7 is intended to protect, how each mechanism contributes to that protection, and where the current implementation still has known gaps. It describes the code as currently deployed, not the target design in the abstract.
Keylay is a coordination layer for remote multisig participants. It is not a wallet, not a signer, and not a custody service. Its job is narrower: move coordination data across distance while reducing how much trust must be placed in the relay and surrounding infrastructure.
The relay is intended to be a dumb message forwarder. It routes traffic on a channel and assigns simple roles, but it is not supposed to learn plaintext, hold session keys, or participate in signing. The central security question is therefore whether the relay can read, alter, or substitute coordination data without being detected or without already knowing the shared code.
The current design assumes the relay may be observable and potentially malicious. It may record traffic, attempt to read message contents, attempt handshake substitution, or replay previously seen ciphertext. The current implementation is intended to prevent plaintext disclosure to the relay and to resist relay MITM by binding handshake messages to knowledge of the shared code. It does not prevent an attacker who already knows the code from acting as a legitimate participant.
Endpoint malware, compromised browsers, compromised phones, insecure out-of-band sharing of the code, and wallet-side verification failures remain outside what the protocol itself can solve. That limitation should be stated plainly, not hidden behind transport security claims.
The security design of this protocol is described step by step. Each step contributes a limited property. No single step does all the work. Standard cryptographic protocols are referred to by abbreviation without elaboration.
The join flow accepts any code of 10 or more characters. Generated codes use a 31-character alphabet and default to length 10, but manually entered codes allow a broader character set. That means effective security depends on the actual code used, not just the generator defaults. A technical reader should therefore treat session-code strength as a parameterized question, not a fixed constant.
The code is SHA-256 hashed, and the first 32 hex characters are used as the WebSocket channel name. This gives the relay a room identifier derived from the code without exposing the raw code directly on the wire as the room name. It does not, by itself, authenticate peers or encrypt anything. Its role is channel identification only.
The code is stretched with PBKDF2-SHA256 using salt 'keylay-v1-hmac' and 300,000 iterations to derive an HMAC key. In the current implementation, this HMAC key is used to prove knowledge of the code during handshake. It is not the AES session key, and message confidentiality does not depend directly on PBKDF2 output. This matters because offline guessing cost against the code is not the same thing as decryption cost against past traffic.
Each participant generates an ephemeral X25519 key pair for the session. These keys are session-scoped, not long-lived identity keys. Their purpose is to produce a fresh Diffie-Hellman shared secret for each session. This is the basis of forward secrecy: if the ephemeral private key is discarded after handshake, later compromise of the code does not reveal old session keys.
Each peer exports its ephemeral public key, base64 encodes it, and signs that public key with the HMAC key derived from the code. The peer then sends the pair {pubkey, sig} inside a hello payload. The security contribution here is narrow but important: the relay cannot substitute a different public key unless it can also forge a valid HMAC, which requires knowing the code. Without this step, the relay could perform key substitution and place itself in the middle of the exchange.
Once a peer receives a valid foreign public key, it computes X25519 shared bits with its own ephemeral private key. Those bits are then imported as HKDF material. The HKDF info field binds the resulting AES key to the sorted pair of public keys, so both sides derive the same session key and that key is tied to the exact handshake participants. No session key is ever transmitted.
Messages are encrypted under AES-GCM with a random 12-byte initialization vector (IV) per message. The additional authenticated data (AAD) is 'keylay-v1|' + counter, where counter is a monotonically increasing integer included in the message. This binds each ciphertext to a specific sequence position: modifying the counter field in transit causes GCM tag failure. The receiver enforces strict monotonic ordering and rejects any message whose counter is not strictly greater than the last accepted value, so a previously recorded ciphertext cannot be replayed.
The state machine moves from IDLE to HELLO_SENT to ACTIVE. Duplicate retries are ignored. If a different peer public key appears after activation, the current session is wiped and a full handshake restart is triggered. This is a limited but useful defense against silent peer-key replacement on reconnect.
Gives a room identifier derived from the code. It does not provide authentication or encryption.
Proves knowledge of the code during handshake and blocks relay key substitution unless the relay also knows the code.
Produces fresh shared secret material per session and enables forward secrecy once ephemeral private keys are discarded.
Derives the same AES session key on both sides and binds that key to the exact participant keypair combination.
Protects message confidentiality and integrity under the current session key. Counter-bound AAD and strict receive-side counter enforcement prevent replay of recorded ciphertext.
Detects reconnect with a different peer public key and forces a new handshake instead of continuing silently.
The session code does not encrypt your messages. That is the job of a session key generated fresh for every connection and discarded when it ends — meaning that even if your code were compromised later, past sessions cannot be decrypted.
The code's job is narrower: it authenticates the handshake. When two browsers exchange the ephemeral keys needed to start a session, the code proves to each side that the other party is legitimate and that no one has substituted different keys in transit. The real threat is not "can an attacker decrypt my messages by guessing the code?" but rather: can an attacker break the handshake authentication fast enough to intercept a live session, or prove after the fact that they could have?
An attacker who has captured the handshake transcript — which requires access to the relay server — can attempt every possible code on their own hardware, bypassing any server-side rate limiting. The system uses PBKDF2 with 300,000 iterations to make each guess expensive. On a single modern GPU cluster, this permits roughly one million guesses per second. The tables below reflect that assumption.
Not suitable at any practical length. A 12-digit numeric code falls within 6 days on a single GPU cluster. A parallelized attack reduces this to hours.
| Length | Avg. crack time |
|---|---|
| 6 digits | < 1 second |
| 8 digits | ~50 seconds |
| 10 digits | ~1.4 hours |
| 12 digits | ~5.8 days |
The system minimum of 10 characters requires ~58 years on a single cluster — structurally infeasible as a real-time attack. No attacker can crack the code before a session completes.
| Length | Avg. crack time |
|---|---|
| 6 characters | ~18 minutes |
| 8 characters | ~16.3 days |
| 10 characters | ~57.9 years |
| 12 characters | ~75,100 years |
Adding special characters from a safe set — those that don't break URLs or copy-paste — raises the 10-character crack time to ~1029 years and pushes 12 characters to ~2.4 million years.
| Length | Avg. crack time |
|---|---|
| 6 characters | ~1.7 hours |
| 8 characters | ~163 days |
| 10 characters | ~1,029 years |
| 12 characters | ~2.37 million years |
A handshake completes in seconds. An attacker would need to crack the code before the session ends to mount a live man-in-the-middle attack. Six lowercase alphanumeric characters fall in 18 minutes — well within an active session window. At the 10-character minimum, cracking requires ~58 years on a single GPU cluster. No current hardware configuration can break the handshake before a session closes.
The 58-year figure is also the cost of a retrospective attack: proving after the fact that interception was theoretically possible. Forward secrecy means past message content remains safe regardless, but a broken handshake undermines trust in the session's integrity. Ten characters is the minimum that makes this retrospective case economically unattractive for a single-cluster attacker.
All generated codes use a 31-character unambiguous alphabet (abcdefghjkmnpqrstuvwxyz23456789) with rejection sampling to eliminate modular bias. Human-chosen codes of any length are weaker than randomly generated ones — people choose predictably. Use the generator.
The source code was reviewed against every specific security claim on this page. Each claim was traced to the corresponding function or variable and evaluated independently. The review also covered the relay server, session isolation logic, and server-side logging. This is a manual technical review with AI-assisted analysis, not a formal third-party security audit.
Confirmed. Every payload sent over the channel is AES-GCM ciphertext. The channel identifier visible to the relay is SHA-256(code) truncated to 32 hex characters. The raw code never appears on the wire.
Confirmed. Each peer signs its ephemeral public key with an HMAC-SHA256 key derived from the session code via PBKDF2 (300,000 iterations). The relay cannot forge a valid signature without knowing the code.
Confirmed. The ephemeral X25519 private key is set to null immediately after session key derivation. The session key is not derivable from the code alone; it requires the private key that was discarded at handshake completion.
Confirmed. Both peers derive the AES-256-GCM key locally from X25519 shared bits processed through HKDF. The HKDF info field binds the derived key to the sorted pair of ephemeral public keys.
Confirmed. AES-GCM additional authenticated data includes a monotonic counter per message. The receiver tracks the last accepted counter and rejects any message that does not strictly advance it. The counter is advanced only after successful decryption.
Confirmed. If a different ephemeral public key arrives while a session is active, the incoming hello is rejected and the active session continues unchanged. A legitimate peer reconnecting with a new key must reload to restart the handshake from the beginning. This prevents a rogue peer from repeatedly forcing session resets by submitting fresh keys — a denial-of-service vector present in earlier versions.
Confirmed at the server. A third connection attempt to an active session hash is refused and the socket is closed immediately.
Confirmed. The client checks the encrypted flag on every incoming data message and silently discards any message that does not carry it.
Confirmed. All cryptographic operations — key generation, PBKDF2, HKDF, HMAC, AES-GCM — use the browser's native crypto.subtle implementation. No third-party cryptographic primitives are in the protocol path.
Confirmed. The relay enforces connection rate limits, message frequency limits, and payload size caps. The client-side pre-handshake message buffer also has a size cap. No straightforward denial-of-service path against the relay through message volume or size remains.
Confirmed. A Content-Security-Policy is set for the application. The policy restricts where the page can send data: network connections are limited to the same origin and the canonical relay, so a successful XSS injection cannot exfiltrate data to an arbitrary external host. Object embedding, form actions, and base-URI changes are all blocked. Note: the current policy includes 'unsafe-inline' in script-src because the app ships as a single inline-script bundle. This means an injected inline script could still read in-memory state. Replacing 'unsafe-inline' with explicit per-block hash entries is planned and will tighten this further.
Confirmed. The server logs truncated IP addresses only — the first two octets are retained for operational purposes; the remainder is zeroed before the log entry is written. No full visitor IP addresses are stored at any layer. No session content, session codes, or coordination data appear in any log.
The relay server imposed no restrictions on connection rate, message frequency, or payload size. The client-side pre-handshake buffer also had no size cap. This created a straightforward denial-of-service path against the relay independent of the cryptographic protocol.
Resolved in v0.7. Rate limiting, message frequency caps, payload size limits, and a pre-handshake buffer cap added to the relay.
The page set no Content-Security-Policy header. In the absence of a CSP, a successful XSS injection would have had unrestricted access to the DOM, WebSocket connection, session key variables, and all decrypted payloads.
Resolved in v0.7. CSP added, restricting script sources and resource loading.
These are not bugs in the current implementation. They are areas where the security posture could be strengthened beyond what is deployed today.
PBKDF2-SHA256 at 300,000 iterations raises brute-force cost but is not memory-hard. Argon2id or scrypt would be significantly more resistant to GPU-accelerated offline attacks against the session code. Upgrading the KDF is a planned improvement.
The relay enforces a two-participant limit per session hash at the server level. A compromised or replaced relay could bypass this enforcement. There is no in-protocol mechanism that cryptographically prevents a third party from joining if the relay permits it.
The protocol has no mechanism to verify the integrity of the channel used to share the session code. An adversary who can intercept or substitute the code during out-of-band sharing — by controlling the communication channel — can join as a legitimate participant. No in-band remedy exists for a fully compromised code-sharing channel.
This review is thorough and AI-assisted, but it is not an independent third-party cryptographic audit. A formal audit by an external security firm is on the roadmap and will be conducted before the project moves out of alpha.
All problems identified in prior reviews have been resolved. Known areas for future improvement are listed above under Hardening Gaps.
Security claims on this page are specific to the version of the implementation they were reviewed against and may not apply to earlier or later versions. Each report documents a line-by-line review of the deployed code: what was confirmed, what was found, what was fixed, and what changed between revisions. This is a manual technical review with AI-assisted analysis, not a formal third-party security audit.
| Report | App version | Date | |
|---|---|---|---|
| Security Review R3 Current | v0.7 | April 2026 | |
| Security Review R2 | v0.6 | April 2026 | |
| Security Review R1 | v0.6 | April 2026 |
