A non-technical explanation:

Every message sent via Local Bitcoin is end-to-end encrypted in your browser. No one — including the Local Bitcoin team — can read those messages. To Local Bitcoin's server your message looks like a bunch of random indistinguishable numbers.

Once the keys used to encrypt the messages are destroyed, that conversation is gone forever. The only time in which our staff can read messages is when the key required to decrypt them is volunteered by one of the parties (this is done in the case of a dispute).

A technical explanation:

(Our protocol is heavily influenced by Open Whisper System's Signal Protocol, which is a trusted open source standard endorsed by Edward Snowden and used by Whatsapp, Facebook and Google Allo.)

Every Local Bitcoin user preemptively generates hundreds of signed key pairs and sends them to the Local Bitcoin server. These are called "maker keys" and they allow people to securely initiate trades, send secure messages, send BCH to and deploy smart contracts with accounts that are offline while maintaining forward secrecy.

The main purposes and benefits of the maker keys are:

  • Full end-to-end encryption - Nobody can read your messages expect you and the person you are trading with.

  • Asynchronous - Parties can send messages and BCH to one another even when the other person is offline the entire time.

  • Identity verification - Each pre‐key is signed by the identity key of its owner so that you know you are always talking to the right person.

  • Forward secrecy - Messages have forward secrecy, as once the key is deleted there is no way to recover it, even if you can replay the ciphertext.

  • Simple dispute resolution - Any party only needs to volunteer a shared secret to staff in order for us to read every message in the conversation.

As an example, say Alice is posting an offer on Local Bitcoin:

  1. She'll generate a random 256-bit secp256k1 public and private key pair securely in her browser (MakerKeyprivate and MakerKeypublic).

  2. Alice will then make an ECDSA signature of SHA3(MakerKeypublic) using her account's identity key (MakerKeysignature).

  3. MakerKeypublic and MakerKeysignature are submitted to Local Bitcoin's server for safe-keeping. The private key is encrypted safely using AES-256 with a random IV and stored online too (at least for now).

  4. (Repeat x 100 times)

Similarly, Alice goes ahead and generates and signs (using her identity key) hundreds of BCH addresses.

When Bob comes along and wants to respond to one of Alice's offer, he'll ask Local Bitcoin for one of Alice's signed pre-keys, and one of Alice's signed BCH addresses. Local Bitcoin will serve him Alice's next "unexposed" maker key (MakerKeypublic) and BCH address (MakerAddress), and will never show the same key or address to anybody else.

Once Bob verifies both signatures to Alice's public key, he can be sure that the key and the BCH address both belong to her. At this point, it would be possible for Bob to send BCH to Alice, or send an encrypted message — but for a number of reasons it isn't that simple (Bob doesn't have a way for Alice to send him an encrypted forward-secret message yet, or a signed BCH address, and there's no mechanism yet for dispute resolution).

At this stage, Bob does three things:

  1. He goes ahead and generates his own brand-new one-time secp256k1 key pair as well (TakerKeyprivate and TakerKeypublic).

  2. He grabs one of his own wallet addresses (TakerAddress).

  3. To prove the validity of his new taker key, BCH address and his intention to make this particular trade, Bob bundles everything together and signs SHA3(MakerKeypublic + MakerAddress + TakerKeypublic + TakerAddress) using his identity key (TradeSignature).

Now, he has everything we need to open a secure trade with Alice. He’ll post his TradeSignature, TakerKeypublic and TakerAddress to Local Bitcoin, and the next time Alice is online she will make sure that signature is valid.

For secure messaging, the parties select a shared secret using an anonymous agreement. The way this works is through an asynchronous key exchange protocol called Elliptic curve Diffie–Hellman (ECDH) which allows Alice and Bob to derive the same shared secret using one party’s private key and the other’s public key.

The beauty of ECDH is that ECDH(MakerKeypublic, TakerKeyprivate) produces the same output as ECDH(TakerKeypublic, MakerKeyprivate). Using this equation, the SharedSecretroot is used to generate more secure keys using the HKDF algorithm (SharedSecretenc for AES-256 encryption and SharedSecretmac for HMAC-SHA256 message authentication) — to prevent unwanted potential interactions in the different cryptographic schemes.

When sending messages to each other in the trade, Alice and Bob encrypt the messages using AES256-CBC to SharedSecretenc with a random IV. For verification purposes, every message is signed using the account's identity key. For further authentication and integrity checking, SharedSecretmac is used to verify HMAC-SHA256 hashes of each encrypted message.

In the case of a dispute, either party needs to volunteer SharedSecretroot to Local Bitcoin staff. This will allow the team to go back and inspect messages, but it won't allow us to access your wallet or decrypt anything else.

Did this answer your question?