# Key Teleport

> Key Teleport is an encrypted handoff protocol for moving small amounts of highly sensitive, typed data between COLDCARD Q devices.

Canonical website: https://keyteleport.org/
Authoritative protocol document: https://github.com/Coldcard/firmware/blob/master/docs/key-teleport.md
Firmware implementation: https://github.com/Coldcard/firmware/blob/master/shared/teleport.py
Optional COLDCARD QR rendezvous: https://keyteleport.com/

## Scope

keyteleport.org is a protocol documentation site. It does not accept, render, transmit, or process Key Teleport payloads. keyteleport.com is the separate COLDCARD-branded static rendezvous that renders validated encrypted BBQr data carried in a URL fragment.

## Protocol overview

1. The receiving COLDCARD Q creates and stores a fresh secp256k1 keypair. It shares the compressed public key in an `R`-type BBQr, encrypted under a random eight-digit Receiver Password.
2. The Receiver Password must travel through a different channel from the BBQr.
3. The sending Q creates its own keypair and uses ECDH with the receiver public key to derive a session key.
4. The sender creates a random eight-character Base32 Teleport Password representing 40 bits.
5. The typed secret is encrypted under a key derived from the Teleport Password and session key, then wrapped under the ECDH session key. Both layers use AES-256-CTR and carry a two-byte SHA-256-derived checksum.
6. The receiver reconstructs the session key, verifies the outer layer, asks for the Teleport Password, verifies and opens the inner layer, imports the typed content, and deletes the receive keypair after a successful transfer.

## Cryptographic components

- ECDH over secp256k1
- SHA-256 over the ECDH point coordinates to derive the session key
- AES-256-CTR for both encryption layers
- PBKDF2-SHA512 with 5,000 iterations for the Teleport Password layer
- Two-byte SHA-256-derived checksums for wrong-key, corruption, and truncation detection
- BBQr with Base32 encoding for visual transport

The short checksum is part of this narrowly scoped device protocol and should not be described as a general-purpose authenticated-encryption construction.

## Typed content

- `s`: seed words, raw master secret, or compact XPRV material
- `x`: extended private-key details
- `n`: secure-note export
- `v`: Seed Vault export
- `p`: binary PSBT
- `b`: complete system backup

## Multisig PSBT path

For an existing multisig wallet, co-signers already have the XPUB material needed to derive one-time ECDH keys. The sender chooses a random 28-bit nonce and derives at `…/20250317/{nonce}`. The nonce can travel in the clear while the PSBT remains encrypted. The preferred signing flow is a daisy chain: each signer teleports the updated PSBT to the next signer.

## Boundaries and limitations

- The current design requires COLDCARD Q because QR scanning is part of the receive path.
- NFC URL transport is limited to about 4 KiB after encoding; direct BBQr is not subject to that URL limit.
- Passwords must be shared separately from the associated QR or encrypted packet.
- A receiver of seed or XPRV material gains control over the associated Bitcoin.
- Key Teleport protects the handoff, not a compromised endpoint or disclosed password.
- The firmware protocol document is authoritative if this summary differs from the implementation.