Technicals.

How a phone pairs with a computer

Pairing is a peer-to-peer ceremony. The two devices build the same secret at the same time. Neither device sends that secret. Nothing in the ceremony passes through a K.ai server.

1. You start the pairing on the computer. The computer makes a temporary key pair. The computer shows a QR code.
2. The QR code holds one kai://link/v1#… address. The invitation rides in the fragment after the #. The invitation is 8 KiB or less before the encoding, and the offer inside it is valid for five minutes.
3. You scan the QR code with the phone. The phone makes its own temporary key pair. The phone sends its offer back over the transport.
4. Both devices do a P-256 key agreement. Both devices calculate the same root key. The root key never crosses the link.
5. Both devices hash the same transcript. The transcript holds the two offers in a fixed order, so the order of arrival cannot change it.
6. Both screens show the same six-digit code. The code comes from that transcript hash.
7. You compare the two codes. You confirm on the computer and on the phone. If the two codes are different, do not confirm.
8. Each device sends an HMAC proof under the root key. The proof covers its role, its device identifier, and the transcript.
9. The computer makes the permission only after both proofs are correct. The phone then locks the root key to your current biometric set.

The transcript also pins the signature key of each device. The computer records the transport identity of the phone separately, when the offer arrives. A confirmation frame must then come from that same identity, and the computer refuses a correct transcript that arrives from a different transport key.

Sessions and keys

A pairing does not open a session. Each new session starts again, and each computer starts its own.

The computer makes a challenge. The challenge names the paired phone and the session. The challenge is valid for two minutes.

Your iPhone signs the challenge with a P-256 key in the Secure Enclave, and Face ID releases that key. An Android phone signs with a Keystore key, and a strong biometric releases it. Neither platform accepts a device passcode for remote retrieval.

Both sides then make the session key with HKDF-SHA256. The input is the root key. The salt is the hash of the challenge that the phone signed. The signature bytes are not part of that hash. The information string names the protocol version.

A session lasts ten minutes. ChaCha20-Poly1305 protects each session envelope. The session identifier, the message type, the sequence number, and the time are authenticated with the envelope. A counter for each session rejects an envelope that arrives twice. The pairing frames and the challenge are different frames with their own rules.

If you link more than one computer, one biometric ceremony can authorize the group. Each computer still receives its own signed challenge. Each pair derives an unrelated session key.

The limits in one session

Encryption alone is not enough. A stolen phone could ask many plausible questions and rebuild private material from the answers. Every session is therefore bounded before it starts.

Many computers, one question

Your phone sends the question to the computers you select. It sends them in parallel.

A computer that sleeps does not stop the answer. The phone waits 12 seconds for a computer to become available. It waits up to 65 seconds for a real answer.

The phone remembers a failed probe for 60 seconds. A sleeping computer then costs one wait, and not one wait for each question. A computer that already holds a session answers immediately.

Each computer ranks its own quotations. Each computer sends the order and not the score, because BM25 scores from different collections are not comparable.

The phone merges the quotations round-robin by rank. It takes one quotation from each computer at each rank, before any computer gives more. One budget of 48,000 characters covers them all.

The phone then writes one answer. The names of your computers stay on the phone. They never enter the request that leaves it.

What never crosses the link

• The vectors and the relationship graph
• The list of your files
• Security-scoped bookmarks
• Absolute paths. Only relative source names cross, and a path that tries to traverse is refused.

Records, and how you remove a device

The computer keeps a record of each query result. A record can hold the device, the session, the folder, the number of sources, the time, and the result. A record never holds a question, an answer, a quotation, or a path.

You can remove a device at any time, and the removal is immediate. The computer announces itself on the network only while it has a reason to: an unrevoked phone, or a pairing in progress. When you remove the last phone, the computer stops the announcement.

The transport

The carrier is Pear over HyperDHT. It moves opaque packets of 128 KiB or less. It receives no application key and no plain text.

The carrier finds the other device on the public DHT. It makes a direct connection when it can. It can use a blind encrypted relay when a direct connection fails.

Those peers can see endpoint and traffic data. They cannot read your questions or your answers. K.ai operates no signaling server, no rendezvous server, no routing server, and no relay server.

What leaves the machine for an answer

K.ai selects a small number of passages for the question. Your question and those passages go into the transient no-logging request, with the relative source name of each passage. No other file content leaves the machine.

The index, the vectors, the graph, the folder locations, and the other files stay where they are. Unlinking a folder deletes the index for that folder. It never deletes your files.