status-im
/
specs
mirror of https://github.com/status-im/specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
specs/spec/5.html

50 lines
54 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html> <html lang="en-US"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=Edge"> <title>5/SECURE-TRANSPORT - Status Specification</title> <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon"> <link rel="stylesheet" href="/assets/css/just-the-docs-default.css"> <script type="text/javascript" src="/assets/js/vendor/lunr.min.js"></script> <script type="text/javascript" src="/assets/js/just-the-docs.js"></script> <meta name="viewport" content="width=device-width, initial-scale=1"> <!-- Begin Jekyll SEO tag v2.7.1 --> <title>5/SECURE-TRANSPORT | Status Specification</title> <meta name="generator" content="Jekyll v4.2.1" /> <meta property="og:title" content="5/SECURE-TRANSPORT" /> <meta property="og:locale" content="en_US" /> <link rel="canonical" href="https://specs.status.im/spec/5" /> <meta property="og:url" content="https://specs.status.im/spec/5" /> <meta property="og:site_name" content="Status Specification" /> <meta name="twitter:card" content="summary" /> <meta property="twitter:title" content="5/SECURE-TRANSPORT" /> <script type="application/ld+json"> {"@type":"WebPage","url":"https://specs.status.im/spec/5","headline":"5/SECURE-TRANSPORT","@context":"https://schema.org"}</script> <!-- End Jekyll SEO tag --> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-link" viewBox="0 0 24 24"> <title>Link</title> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-link"> <path d="M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71"></path><path d="M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71"></path> </svg> </symbol> <symbol id="svg-search" viewBox="0 0 24 24"> <title>Search</title> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-search"> <circle cx="11" cy="11" r="8"></circle><line x1="21" y1="21" x2="16.65" y2="16.65"></line> </svg> </symbol> <symbol id="svg-menu" viewBox="0 0 24 24"> <title>Menu</title> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-menu"> <line x1="3" y1="12" x2="21" y2="12"></line><line x1="3" y1="6" x2="21" y2="6"></line><line x1="3" y1="18" x2="21" y2="18"></line> </svg> </symbol> <symbol id="svg-arrow-right" viewBox="0 0 24 24"> <title>Expand</title> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-chevron-right"> <polyline points="9 18 15 12 9 6"></polyline> </svg> </symbol> <symbol id="svg-doc" viewBox="0 0 24 24"> <title>Document</title> <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-file"> <path d="M13 2H6a2 2 0 0 0-2 2v16a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V9z"></path><polyline points="13 2 13 9 20 9"></polyline> </svg> </symbol> </svg> <div class="side-bar"> <div class="site-header"> <a href="https://specs.status.im/" class="site-title lh-tight"> Status Specification </a> <a href="#" id="menu-button" class="site-button"> <svg viewBox="0 0 24 24" class="icon"><use xlink:href="#svg-menu"></use></svg> </a> </div> <nav role="navigation" aria-label="Main" id="site-nav" class="site-nav"> <ul class="nav-list"><li class="nav-list-item active"><a href="#" class="nav-list-expander"><svg viewBox="0 0 24 24"><use xlink:href="#svg-arrow-right"></use></svg></a><a href="https://specs.status.im/spec/" class="nav-list-link">Stable specs</a><ul class="nav-list "><li class="nav-list-item "><a href="https://specs.status.im/spec/1" class="nav-list-link">1/CLIENT</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/10" class="nav-list-link">10/WAKU-USAGE</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/11" class="nav-list-link">11/WAKU-MAILSERVER</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/15" class="nav-list-link">15/NOTIFICATIONS</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/2" class="nav-list-link">2/ACCOUNT</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/3" class="nav-list-link">3/WHISPER-USAGE</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/4" class="nav-list-link">4/WHISPER-MAILSERVER</a></li><li class="nav-list-item active"><a href="https://specs.status.im/spec/5" class="nav-list-link active">5/SECURE-TRANSPORT</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/6" class="nav-list-link">6/PAYLOADS</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/8" class="nav-list-link">8/EIPS</a></li><li class="nav-list-item "><a href="https://specs.status.im/spec/9" class="nav-list-link">9/ETHEREUM-USAGE</a></li></ul></li><li class="nav-list-item"><a href="#" class="nav-list-expander"><svg viewBox="0 0 24 24"><use xlink:href="#svg-arrow-right"></use></svg></a><a href="https://specs.status.im/draft/" class="nav-list-link">Draft specs</a><ul class="nav-list "><li class="nav-list-item "><a href="https://specs.status.im/draft/12" class="nav-list-link">12/IPFS gateway for Sticker Pack</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/13" class="nav-list-link">13/3RD-PARTY-USAGE</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/14" class="nav-list-link">14/Dapp browser API usage</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/16" class="nav-list-link">16/Keycard Usage for Wallet and Chat Keys</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/3" class="nav-list-link">3/WHISPER-USAGE</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/6" class="nav-list-link">6/PAYLOADS</a></li><li class="nav-list-item "><a href="https://specs.status.im/draft/7" class="nav-list-link">7/GROUP-CHAT</a></li></ul></li><li class="nav-list-item"><a href="#" class="nav-list-expander"><svg viewBox="0 0 24 24"><use xlink:href="#svg-arrow-right"></use></svg></a><a href="https://specs.status.im/raw/" class="nav-list-link">Raw specs</a><ul class="nav-list "><li class="nav-list-item "><a href="https://specs.status.im/raw/16" class="nav-list-link">16/PUSH-NOTIFICATION-SERVER</a></li></ul></li><li class="nav-list-item"><a href="https://specs.status.im/development" class="nav-list-link">DEVELOPMENT</a></li><li class="nav-list-item"><a href="https://specs.status.im/style-guideline" class="nav-list-link">STYLE-GUIDELINE</a></li></ul> </nav> <footer class="site-footer"> This site uses <a href="https://github.com/pmarsceill/just-the-docs">Just the Docs</a>, a documentation theme for Jekyll. </footer> </div> <div class="main" id="top"> <div id="main-header" class="main-header"> <div class="search"> <div class="search-input-wrap"> <input type="text" id="search-input" class="search-input" tabindex="0" placeholder="Search Status Specification" aria-label="Search Status Specification" autocomplete="off"> <label for="search-input" class="search-label"><svg viewBox="0 0 24 24" class="search-icon"><use xlink:href="#svg-search"></use></svg></label> </div> <div id="search-results" class="search-results"></div> </div> </div> <div id="main-content-wrap" class="main-content-wrap"> <nav aria-label="Breadcrumb" class="breadcrumb-nav"> <ol class="breadcrumb-nav-list"> <li class="breadcrumb-nav-list-item"><a href="https://specs.status.im/spec/">Stable specs</a></li> <li class="breadcrumb-nav-list-item"><span>5/SECURE-TRANSPORT</span></li> </ol> </nav> <div id="main-content" class="main-content" role="main"> <h1 id="5secure-transport"> <a href="#5secure-transport" class="anchor-heading" aria-labelledby="5secure-transport"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> 5/SECURE-TRANSPORT </h1> <blockquote> <p>Version: 0.3</p> <p>Status: Stable</p> <p>Authors: Andrea Piana <a href="mailto:andreap@status.im">andreap@status.im</a>, Pedro Pombeiro <a href="mailto:pedro@status.im">pedro@status.im</a>, Corey Petty <a href="mailto:corey@status.im">corey@status.im</a>, Oskar Thorén <a href="mailto:oskar@status.im">oskar@status.im</a>, Dean Eigenmann <a href="mailto:dean@status.im">dean@status.im</a></p> </blockquote> <h2 id="abstract"> <a href="#abstract" class="anchor-heading" aria-labelledby="abstract"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Abstract </h2> <p>This document describes how Status provides a secure channel between two peers, and thus provide confidentiality, integrity, authenticity and forward secrecy. It is transport-agnostic and works over asynchronous networks.</p> <p>It builds on the <a href="https://signal.org/docs/specifications/x3dh/">X3DH</a> and <a href="https://signal.org/docs/specifications/doubleratchet/">Double Ratchet</a> specifications, with some adaptations to operate in a decentralized environment.</p> <h2 id="table-of-contents"> <a href="#table-of-contents" class="anchor-heading" aria-labelledby="table-of-contents"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Table of Contents </h2> <ul> <li><a href="#abstract">Abstract</a></li> <li><a href="#table-of-contents">Table of Contents</a></li> <li><a href="#introduction">Introduction</a> <ul> <li><a href="#definitions">Definitions</a></li> <li><a href="#design-requirements">Design Requirements</a></li> <li><a href="#conventions">Conventions</a></li> <li><a href="#transport-layer">Transport Layer</a></li> <li><a href="#user-flow-for-1-to-1-communications">User flow for 1-to-1 communications</a> <ul> <li><a href="#account-generation">Account generation</a></li> <li><a href="#account-recovery">Account recovery</a></li> </ul> </li> </ul> </li> <li><a href="#messaging">Messaging</a> <ul> <li><a href="#end-to-end-encryption">End-to-end encryption</a></li> <li><a href="#prekeys">Prekeys</a></li> <li><a href="#bundle-retrieval">Bundle retrieval</a></li> <li><a href="#11-chat-contact-request">1:1 chat contact request</a> <ul> <li><a href="#initial-key-exchange-flow-x3dh">Initial key exchange flow (X3DH)</a></li> <li><a href="#double-ratchet">Double Ratchet</a></li> </ul> </li> </ul> </li> <li><a href="#security-considerations">Security Considerations</a></li> <li><a href="#session-management">Session management</a> <ul> <li><a href="#abstract">Abstract</a></li> <li><a href="#introduction">Introduction</a></li> <li><a href="#initialization">Initialization</a></li> <li><a href="#concurrent-sessions">Concurrent sessions</a></li> <li><a href="#re-keying">Re-keying</a></li> <li><a href="#multi-device-support">Multi-device support</a></li> <li><a href="#pairing">Pairing</a></li> <li><a href="#sending-messages-to-a-paired-group">Sending messages to a paired group</a></li> <li><a href="#account-recovery">Account recovery</a></li> <li><a href="#partitioned-devices">Partitioned devices</a></li> </ul> </li> <li><a href="#changelog">Changelog</a> <ul> <li><a href="#version-03">Version 0.3</a></li> </ul> </li> </ul> <h2 id="introduction"> <a href="#introduction" class="anchor-heading" aria-labelledby="introduction"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Introduction </h2> <p>This document describes how nodes establish a secure channel, and how various conversational security properties are achieved.</p> <h3 id="definitions"> <a href="#definitions" class="anchor-heading" aria-labelledby="definitions"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Definitions </h3> <ul> <li> <p><strong>Perfect Forward Secrecy</strong> is a feature of specific key-agreement protocols which provide assurances that session keys will not be compromised even if the private keys of the participants are compromised. Specifically, past messages cannot be decrypted by a third-party who manages to get a hold of a private key.</p> </li> <li> <p><strong>Secret channel</strong> describes a communication channel where Double Ratchet algorithm is in use.</p> </li> </ul> <h3 id="design-requirements"> <a href="#design-requirements" class="anchor-heading" aria-labelledby="design-requirements"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Design Requirements </h3> <ul> <li><strong>Confidentiality</strong>: The adversary should not be able to learn what data is being exchanged between two Status clients.</li> <li><strong>Authenticity</strong>: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data from any third party as though it came from the other endpoint.</li> <li><strong>Forward Secrecy</strong>: The adversary should not be able to learn what data was exchanged between two Status clients if, at some later time, the adversary compromises one or both of the endpoint devices.</li> <li><strong>Integrity</strong>: The adversary should not be able to cause either endpoint of a Status 1:1 chat to accept data that has been tampered with.</li> </ul> <p>All of these properties are ensured by the use of <a href="https://signal.org/docs/specifications/doubleratchet/">Signal’s Double Ratchet</a></p> <h3 id="conventions"> <a href="#conventions" class="anchor-heading" aria-labelledby="conventions"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Conventions </h3> <p>Types used in this specification are defined using <a href="https://developers.google.com/protocol-buffers/">Protobuf</a>.</p> <h3 id="transport-layer"> <a href="#transport-layer" class="anchor-heading" aria-labelledby="transport-layer"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Transport Layer </h3> <p><a href="3-whisper-usage.md">Whisper</a> and <a href="10-waku-usage.md">Waku</a> serves as the transport layers for the Status chat protocol.</p> <h3 id="user-flow-for-1-to-1-communications"> <a href="#user-flow-for-1-to-1-communications" class="anchor-heading" aria-labelledby="user-flow-for-1-to-1-communications"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> User flow for 1-to-1 communications </h3> <h4 id="account-generation"> <a href="#account-generation" class="anchor-heading" aria-labelledby="account-generation"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Account generation </h4> <p>See <a href="./2-account.md">Account specification</a></p> <h4 id="account-recovery"> <a href="#account-recovery" class="anchor-heading" aria-labelledby="account-recovery"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Account recovery </h4> <p>If Alice later recovers her account, the Double Ratchet state information will not be available, so she is no longer able to decrypt any messages received from existing contacts.</p> <p>If an incoming message (on the same Whisper/Waku topic) fails to decrypt, the node replies a message with the current bundle, so that the node notifies the other end of the new device. Subsequent communications will use this new bundle.</p> <h2 id="messaging"> <a href="#messaging" class="anchor-heading" aria-labelledby="messaging"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Messaging </h2> <p>All 1:1 and group chat messaging in Status is subject to end-to-end encryption to provide users with a strong degree of privacy and security. Public chat messages are publicly readable by anyone since there’s no permission model for who is participating in a public chat.</p> <p>The rest of this document is purely about 1:1 and private group chat. Private group chat largely reduces to 1:1 chat, since there’s a secure channel between each pair-wise participant.</p> <h3 id="end-to-end-encryption"> <a href="#end-to-end-encryption" class="anchor-heading" aria-labelledby="end-to-end-encryption"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> End-to-end encryption </h3> <p>End-to-end encryption (E2EE) takes place between two clients. The main cryptographic protocol is a <a href="https://github.com/status-im/doubleratchet/">Status implementation</a> of the Double Ratchet protocol, which is in turn derived from the <a href="https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html">Off-the-Record protocol</a>, using a different ratchet. The transport protocol subsequently encrypt the message payload - Whisper/Waku (see section <a href="#transport-layer">Transport Layer</a>) -, using symmetric key encryption. Furthermore, Status uses the concept of prekeys (through the use of <a href="https://signal.org/docs/specifications/x3dh/">X3DH</a>) to allow the protocol to operate in an asynchronous environment. It is not necessary for two parties to be online at the same time to initiate an encrypted conversation.</p> <p>Status uses the following cryptographic primitives:</p> <ul> <li>Whisper/Waku <ul> <li>AES-256-GCM</li> <li>ECIES</li> <li>ECDSA</li> <li>KECCAK-256</li> </ul> </li> <li>X3DH <ul> <li>Elliptic curve Diffie-Hellman key exchange (secp256k1)</li> <li>KECCAK-256</li> <li>ECDSA</li> <li>ECIES</li> </ul> </li> <li>Double Ratchet <ul> <li>HMAC-SHA-256 as MAC</li> <li>Elliptic curve Diffie-Hellman key exchange (Curve25519)</li> <li>AES-256-CTR with HMAC-SHA-256 and IV derived alongside an encryption key</li> </ul> <p>The node achieves key derivation using HKDF.</p> </li> </ul> <h3 id="prekeys"> <a href="#prekeys" class="anchor-heading" aria-labelledby="prekeys"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Prekeys </h3> <p>Every client initially generates some key material which is stored locally:</p> <ul> <li>Identity keypair based on secp256k1 - <code class="language-plaintext highlighter-rouge">IK</code></li> <li>A signed prekey based on secp256k1 - <code class="language-plaintext highlighter-rouge">SPK</code></li> <li>A prekey signature - <code class="language-plaintext highlighter-rouge">Sig(IK, Encode(SPK))</code></li> </ul> <p>More details can be found in the <code class="language-plaintext highlighter-rouge">X3DH Prekey bundle creation</code> section of <a href="https://specs.status.im/spec/2#x3dh-prekey-bundles">2/ACCOUNT</a>.</p> <p>Prekey bundles can be extracted from any user’s messages, or found via searching for their specific topic, <code class="language-plaintext highlighter-rouge">{IK}-contact-code</code>.</p> <p>TODO: See below on bundle retrieval, this seems like enhancement and parameter for recommendation</p> <h3 id="bundle-retrieval"> <a href="#bundle-retrieval" class="anchor-heading" aria-labelledby="bundle-retrieval"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Bundle retrieval </h3> <!-- TODO: Potentially move this completely over to [Trust Establishment](./status-account-spec.md) --> <p>X3DH works by having client apps create and make available a bundle of prekeys (the X3DH bundle) that can later be requested by other interlocutors when they wish to start a conversation with a given user.</p> <p>In the X3DH specification, nodes typically use a shared server to store bundles and allow other users to download them upon request. Given Status’ goal of decentralization, Status chat clients cannot rely on the same type of infrastructure and must achieve the same result using other means. By growing order of convenience and security, the considered approaches are:</p> <ul> <li>contact codes;</li> <li>public and one-to-one chats;</li> <li>QR codes;</li> <li>ENS record;</li> <li>Decentralized permanent storage (e.g. Swarm, IPFS).</li> <li>Whisper/Waku</li> </ul> <!-- TODO: Comment, it isn't clear what we actually _do_. It seems as if this is exploring the problem space. From a protocol point of view, it might make sense to describe the interface, and then have a recommendation section later on that specifies what we do. See e.g. Signal's specs where they specify specifics later on. --> <p>Currently, only public and one-to-one message exchanges and Whisper/Waku is used to exchange bundles.</p> <p>Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the approach taken is to rotate more frequently the bundle (once every 24 hours), which will be propagated by the app through the channel available.</p> <h3 id="11-chat-contact-request"> <a href="#11-chat-contact-request" class="anchor-heading" aria-labelledby="11-chat-contact-request"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> 1:1 chat contact request </h3> <p>There are two phases in the initial negotiation of a 1:1 chat:</p> <ol> <li><strong>Identity verification</strong> (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval;</li> <li><strong>Asynchronous initial key exchange</strong>, using X3DH.</li> </ol> <p>For more information on account generation and trust establishment, see <a href="https://specs.status.im/spec/2">2/ACCOUNT</a></p> <h4 id="initial-key-exchange-flow-x3dh"> <a href="#initial-key-exchange-flow-x3dh" class="anchor-heading" aria-labelledby="initial-key-exchange-flow-x3dh"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Initial key exchange flow (X3DH) </h4> <p><a href="https://signal.org/docs/specifications/x3dh/#sending-the-initial-message">Section 3 of the X3DH protocol</a> describes the initial key exchange flow, with some additional context:</p> <ul> <li>The users’ identity keys <code class="language-plaintext highlighter-rouge">IK_A</code> and <code class="language-plaintext highlighter-rouge">IK_B</code> correspond to their respective Status chat public keys;</li> <li>Since it is not possible to guarantee that a prekey will be used only once in a decentralized world, the one-time prekey <code class="language-plaintext highlighter-rouge">OPK_B</code> is not used in this scenario;</li> <li>Nodes do not send Bundles to a centralized server, but instead served in a decentralized way as described in <a href="#bundle-retrieval">bundle retrieval</a>.</li> </ul> <p>Alice retrieves Bob’s prekey bundle, however it is not specific to Alice. It contains:</p> <p>(<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L12">protobuf</a>)</p> <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">// X3DH prekey bundle</span>
<span class="kd">message</span> <span class="nc">Bundle</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">identity</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">map</span><span class="o">&lt;</span><span class="kt">string</span><span class="p">,</span><span class="n">SignedPreKey</span><span class="err">&gt;</span> <span class="na">signed_pre_keys</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">signature</span> <span class="o">=</span> <span class="mi">4</span><span class="p">;</span>
<span class="kt">int64</span> <span class="na">timestamp</span> <span class="o">=</span> <span class="mi">5</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div> <ul> <li><code class="language-plaintext highlighter-rouge">identity</code>: Identity key <code class="language-plaintext highlighter-rouge">IK_B</code></li> <li><code class="language-plaintext highlighter-rouge">signed_pre_keys</code>: Signed prekey <code class="language-plaintext highlighter-rouge">SPK_B</code> for each device, indexed by <code class="language-plaintext highlighter-rouge">installation-id</code></li> <li><code class="language-plaintext highlighter-rouge">signature</code>: Prekey signature <i>Sig(<code class="language-plaintext highlighter-rouge">IK_B</code>, Encode(<code class="language-plaintext highlighter-rouge">SPK_B</code>))</i></li> <li><code class="language-plaintext highlighter-rouge">timestamp</code>: When the bundle was created locally</li> </ul> <p>(<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L5">protobuf</a>)</p> <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">message</span> <span class="nc">SignedPreKey</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">signed_pre_key</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">uint32</span> <span class="na">version</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div> <p>The <code class="language-plaintext highlighter-rouge">signature</code> is generated by sorting <code class="language-plaintext highlighter-rouge">installation-id</code> in lexicographical order, and concatenating the <code class="language-plaintext highlighter-rouge">signed-pre-key</code> and <code class="language-plaintext highlighter-rouge">version</code>:</p> <p><code class="language-plaintext highlighter-rouge">installation-id-1signed-pre-key1version1installation-id2signed-pre-key2-version-2</code></p> <h4 id="double-ratchet"> <a href="#double-ratchet" class="anchor-heading" aria-labelledby="double-ratchet"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Double Ratchet </h4> <p>Having established the initial shared secret <code class="language-plaintext highlighter-rouge">SK</code> through X3DH, it can be used to seed a Double Ratchet exchange between Alice and Bob.</p> <p>Please refer to the <a href="https://signal.org/docs/specifications/doubleratchet/">Double Ratchet spec</a> for more details.</p> <p>The initial message sent by Alice to Bob is sent as a top-level <code class="language-plaintext highlighter-rouge">ProtocolMessage</code> (<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L65">protobuf</a>) containing a map of <code class="language-plaintext highlighter-rouge">DirectMessageProtocol</code> indexed by <code class="language-plaintext highlighter-rouge">installation-id</code> (<a href="https://github.com/status-im/status-go/blob/1ac9dd974415c3f6dee95145b6644aeadf02f02c/services/shhext/chat/encryption.proto#L56">protobuf</a>):</p> <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">message</span> <span class="nc">ProtocolMessage</span> <span class="p">{</span>
<span class="kt">string</span> <span class="na">installation_id</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="k">repeated</span> <span class="n">Bundle</span> <span class="na">bundles</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="c1">// One to one message, encrypted, indexed by installation_id</span>
<span class="n">map</span><span class="o">&lt;</span><span class="kt">string</span><span class="p">,</span><span class="n">DirectMessageProtocol</span><span class="err">&gt;</span> <span class="na">direct_message</span> <span class="o">=</span> <span class="mi">101</span><span class="p">;</span>
<span class="c1">// Public chats, not encrypted</span>
<span class="kt">bytes</span> <span class="na">public_message</span> <span class="o">=</span> <span class="mi">102</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div> <ul> <li><code class="language-plaintext highlighter-rouge">bundles</code>: a sequence of bundles</li> <li><code class="language-plaintext highlighter-rouge">installation_id</code>: the installation id of the sender</li> <li><code class="language-plaintext highlighter-rouge">direct_message</code> is a map of <code class="language-plaintext highlighter-rouge">DirectMessageProtocol</code> indexed by <code class="language-plaintext highlighter-rouge">installation-id</code></li> <li><code class="language-plaintext highlighter-rouge">public_message</code>: unencrypted public chat message.</li> </ul> <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">message</span> <span class="nc">DirectMessageProtocol</span> <span class="p">{</span>
<span class="n">X3DHHeader</span> <span class="na">X3DH_header</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">DRHeader</span> <span class="na">DR_header</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="n">DHHeader</span> <span class="na">DH_header</span> <span class="o">=</span> <span class="mi">101</span><span class="p">;</span>
<span class="c1">// Encrypted payload</span>
<span class="kt">bytes</span> <span class="na">payload</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div></div> <ul> <li> <p><code class="language-plaintext highlighter-rouge">X3DH_header</code>: the <code class="language-plaintext highlighter-rouge">X3DHHeader</code> field in <code class="language-plaintext highlighter-rouge">DirectMessageProtocol</code> contains:</p> <p>(<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L47">protobuf</a>)</p> <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code> <span class="kd">message</span> <span class="nc">X3DHHeader</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">key</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">id</span> <span class="o">=</span> <span class="mi">4</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div> </div> <ul> <li><code class="language-plaintext highlighter-rouge">key</code>: Alice’s ephemeral key <code class="language-plaintext highlighter-rouge">EK_A</code>;</li> <li><code class="language-plaintext highlighter-rouge">id</code>: Identifier stating which of Bob’s prekeys Alice used, in this case Bob’s bundle signed prekey.</li> </ul> <p>Alice’s identity key <code class="language-plaintext highlighter-rouge">IK_A</code> is sent at the transport layer level (Whisper/Waku);</p> </li> <li><code class="language-plaintext highlighter-rouge">DR_header</code>: Double ratchet header (<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L31">protobuf</a>). Used when Bob’s public bundle is available: <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code> <span class="kd">message</span> <span class="nc">DRHeader</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">key</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="kt">uint32</span> <span class="na">n</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
<span class="kt">uint32</span> <span class="na">pn</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
<span class="kt">bytes</span> <span class="na">id</span> <span class="o">=</span> <span class="mi">4</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div> </div> <ul> <li><code class="language-plaintext highlighter-rouge">key</code>: Alice’s current ratchet public key (as mentioned in <a href="https://signal.org/docs/specifications/doubleratchet/#symmetric-key-ratchet">DR spec section 2.2</a>);</li> <li><code class="language-plaintext highlighter-rouge">n</code>: number of the message in the sending chain;</li> <li><code class="language-plaintext highlighter-rouge">pn</code>: length of the previous sending chain;</li> <li><code class="language-plaintext highlighter-rouge">id</code>: Bob’s bundle ID.</li> </ul> </li> <li><code class="language-plaintext highlighter-rouge">DH_header</code>: Diffie-Helman header (used when Bob’s bundle is not available): (<a href="https://github.com/status-im/status-go/blob/a904d9325e76f18f54d59efc099b63293d3dcad3/services/shhext/chat/encryption.proto#L42">protobuf</a>) <div class="language-protobuf highlighter-rouge"><div class="highlight"><pre class="highlight"><code> <span class="kd">message</span> <span class="nc">DHHeader</span> <span class="p">{</span>
<span class="kt">bytes</span> <span class="na">key</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="p">}</span>
</code></pre></div> </div> <ul> <li><code class="language-plaintext highlighter-rouge">key</code>: Alice’s compressed ephemeral public key.</li> </ul> </li> <li><code class="language-plaintext highlighter-rouge">payload</code>: <ul> <li>if a bundle is available, contains payload encrypted with the Double Ratchet algorithm;</li> <li>otherwise, payload encrypted with output key of DH exchange (no Perfect Forward Secrecy).</li> </ul> </li> </ul> <!-- TODO: A lot of links to status-go, seems likely these should be updated to status-protocol-go --> <h2 id="security-considerations"> <a href="#security-considerations" class="anchor-heading" aria-labelledby="security-considerations"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Security Considerations </h2> <p>The same considerations apply as in <a href="https://signal.org/docs/specifications/x3dh/#security-considerations">section 4 of the X3DH spec</a> and <a href="https://signal.org/docs/specifications/doubleratchet/#security-considerations">section 6 of the Double Ratchet spec</a>, with some additions detailed below.</p> <!-- TODO: Add any additional context here not covered in the X3DH and DR specs --> <!-- TODO: description here ### --- Security and Privacy Features #### Confidentiality (YES) > Only the intended recipients are able to read a message. Specifically, the message must not be readable by a server operator that is not a conversation participant - Yes. - There's a layer of encryption at Whisper as well as above with Double Ratchet - Relay nodes and Mailservers can only read a topic of a Whisper message, and nothing within the payload. #### Integrity (YES) > No honest party will accept a message that has been modified in transit. - Yes. - Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validate its signature from the sender, then it is not able to be altered in transit. * [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything) * [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easily create a random account) #### Authentication (YES) > Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source - 1:1 --- one-to-one messages are encrypted with the recipient's public key, and digitally signed by the sender's. In order to provide Perfect Forward Secrecy, we build on the X3DH and Double Ratchet specifications from Open Whisper Systems, with some adaptations to operate in a decentralized environment. - group --- group chat is pairwise - public --- A user subscribes to a public channel topic and the decryption key is derived from the topic name **TODO:** Need to verify that this is actually the case **TODO:** Fill in explicit details here #### Participant Consistency (YES?) > At any point when a message is accepted by an honest party, all honest parties are guaranteed to have the same view of the participant list - **TODO:** Need details here #### Destination Validation (YES?) > When a message is accepted by an honest party, they can verify that they were included in the set of intended recipients for the message. - Users are aware of the topic that a message was sent to, and that they have the ability to decrypt it. - #### Forward Secrecy (PARTIAL) > Compromising all key material does not enable decryption of previously encrypted data - After first back and forth between two contacts with PFS enabled, yes. #### Backward Secrecy (YES) > Compromising all key material does not enable decryption of succeeding encrypted data - PFS requires both backward and forwards secrecy [Andrea: This is not true, (Perfect) Forward Secrecy does not imply backward secrecy (which is also called post-compromise security, as signal calls it, or future secrecy, it's not well defined). Technically this is a NO , double ratchet offers good Backward secrecy, but not perfect. Effectively if all the key material is compromised, any future message received will be also compromised (due to the hash ratchet), until a DH ratchet step is completed (i.e. the compromised party generate a new random key and ratchet)] #### Anonymity Preserving (PARTIAL) > Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not de-anonymize users by linking key identifiers). - by default, yes - ENS Naming system attaches an identifier to a given public key #### Speaker Consistency (PARTIAL) > All participants agree on the sequence of messages sent by each participant. A protocol might perform consistency checks on blocks of messages during the protocol, or after every message is sent. - We use Lamport timestamps for ordering of events. - In addition to this, we use local timestamps to attempt a more intuitive ordering. [Andrea: currently this was introduced as a regression during performance optimization and might result in out-of-order messages if sent across day boundaries, so I consider it a bug and not part of the specs (it does not make the order more intuitive, quite the opposite as it might result in causally related messages being out-of-order, but helps dividing the messages in days)] - Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistently, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally), of course is not useful, you want to have causal + global to be meaningful] TODO: Understand how this is different from Global Transcript [Andrea: This is basically Global transcript for a single participants, we offer global transcript] #### Causality Preserving (PARTIAL) > Implementations can avoid displaying a message before messages that causally precede it - Not yet, but in pipeline (data sync layer) [Andrea: Messages are already causally ordered, we don't display messages that are causally related out-of-order, that's already granted by lamport timestamps] TODO: Verify if this can be done already by looking at Lamport clock difference #### Global Transcript (PARTIAL) > All participants see all messages in the same order - See directly above [Andrea: messages are globally (total) ordered, so all participants see the same ordering] #### Message Unlinkability (NO) > If a judge is convinced that a participant authored one message in the conversation, this does not provide evidence that they authored other messages - Currently, the Status software signs every messages sent with the user's public key, thus making it unable to provide unlinkability. - This is not necessary though, and could be built in to have an option to not sign. - Side note: moot account allows for this but is a function of the anonymity set that uses it. The more people that use this account the stronger the unlinkability. #### Message Repudiation (NO) > Given a conversation transcript and all cryptographic keys, there is no evidence that a given message was authored by any particular user - All messages are digitally signed by their sender. - The underlying transport, Whisper/Waku, does allow for unsigned messages, but we don't use it. #### Participant Repudiation (NO) > Given a conversation transcript and all cryptographic key material for all but one accused (honest) participant, there is no evidence that the honest participant was in a conversation with any of the other participants. ### --- Group related features #### Computational Equality (YES) > All chat participants share an equal computational load - One a message is sent, all participants in a group chat perform the same steps to retrieve and decrypt it. - If proof of work is actually used at the Whisper layer (basically turned off in Status) then the sender would have to do additional computational work to send messages. #### Trust Equality (PARTIAL) > No participant is more trusted or takes on more responsibility than any other - 1:1 chats and public chats are equal - group chats have admins (on purpose) - Private Group chats have Administrators and Members. Upon construction, the creator is made an admin. These groups have the following privileges: - Admins: - Add group members - Promote group members to admin - Change group name - Members: - Accept invitation to group - Leave group - Non-Members: - Invited by admins show up as "invited" in group; this leaks contact information - Invited people don't opt-in to being invited TODO: Group chat dynamics should have a documented state diagram TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behavior for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easily, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)] #### Subgroup Messaging (NO) > Messages can be sent to a subset of participants without forming a new conversation - This would require a new topic and either a new public chat or a new group chat [Andrea: This is a YES, as messages are pairwise encrypted, and client-side fanout, so anyone could potentially send a message only to a subset of the group] #### Contractible Membership (PARTIAL) > After the conversation begins, participants can leave without restarting the protocol - For 1:1, there is no way to ignore or block a user from sending you a message. This is currently in the pipeline. - For public chats, Yes. A member simply stops subscribing to a specific topic and will no longer receive messages. - For group chats: this assumes pairwise encryption OR key is renegotiated - This only currently works on the identity level, and not the device level. A ghost device will have access to anything other devices have. [Andrea: For group chats, that's possible as using pairwise encryption, also with group chats (which use device-to-device encryption), ghost devices is a bit more complicated, in general, they don't have access to the messages you send, i.e. If I send a message from device A1 to the group chat and there is a ghost device A2, it will not be able to decrypt the content, but will see that a message has been sent (as only paired devices are kept in sync, and those are explicitly approved by the user). Messages that you receive are different, so a ghost device (A2) will potentially be able to decrypt the message, but A1 can detect the ghost device (in most cases, it's complicated :), the pfs docs describe multi-device support), for one-to-one ghost devices are undetectable] #### Expandable Membership (PARTIAL) > After the conversation begins, participants can join without restarting the protocol. - 1:1: no, only 1:1 - private group: yes, since it is pair-wise, each person in the group just creates a pair with the new member - public: yes, as members of a public chat are only subscribing to a topic and receiving anyone sending messages to it. ### --- Usability and Adoption #### Out-of-Order Resilient (PARTIAL) > If a message is delayed in transit, but eventually arrives, its contents are accessible upon arrival - Due to asynchronous forward secrecy and no additional services, private keys might be rotated [Andrea: That's correct, in some cases if the message is delayed for too long, or really out-of-order, the specific message key might have been deleted, as we only keep the last 3000 message keys] [Igor: TTL of a Whisper message can expire, so any node-in-transit will drop it. Also, I believe we ignore messages with skewed timestamps] #### Dropped Message Resilient (PARTIAL) > Messages can be decrypted without receipt of all previous messages. This is desirable for asynchronous and unreliable network services - Public chats: yes, users are able to decrypt any message received at any time. - 1-to-1/group chat also, this is a YES in my opinion #### Asynchronous (PARTIAL) > Messages can be sent securely to disconnected recipients and received upon their next connection - The semantics around message reliability are currently poor * [Igor: messages are stored on mailservers for way longer than TTL (30 days), but that requires Status infrastructure] - There's a TTL in Whisper and mailserver can deliver messages after the fact TODO: this requires more detail #### Multi-Device Support (YES) > A user can participate in the conversation using multiple devices at once. Each device must be able to send and receive messages. Ideally, all devices have identical views of the conversation. The devices might use a synchronized long-term key or distinct keys. - Yes - There is currently work being done to improve the syncing process between a user's devices. #### No Additional Service (NO) > The protocol does not require any infrastructure other than the protocol participants. Specifically, the protocol must not require additional servers for relaying messages or storing any kind of key material. - The protocol requires Whisper/Waku relay servers and mailservers currently. - The larger the number of Whisper/Waku relay servers, the better the transport security but there might be potential scaling problems. - Mailservers act to provide asynchronicity so users can retrieve messages after coming back from an offline period. --> <h2 id="session-management"> <a href="#session-management" class="anchor-heading" aria-labelledby="session-management"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Session management </h2> <p>A node identifies a peer by two pieces of data:</p> <p>1) An <code class="language-plaintext highlighter-rouge">installation-id</code> which is generated upon creating a new account in the <code class="language-plaintext highlighter-rouge">Status</code> application 2) Their identity Whisper/Waku key</p> <h3 id="initialization"> <a href="#initialization" class="anchor-heading" aria-labelledby="initialization"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Initialization </h3> <p>A node initializes a new session once a successful X3DH exchange has taken place. Subsequent messages will use the established session until re-keying is necessary.</p> <h3 id="concurrent-sessions"> <a href="#concurrent-sessions" class="anchor-heading" aria-labelledby="concurrent-sessions"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Concurrent sessions </h3> <p>If a node creates two sessions concurrently between two peers, the one with the symmetric key first in byte order SHOULD be used, this marks that the other has expired.</p> <h3 id="re-keying"> <a href="#re-keying" class="anchor-heading" aria-labelledby="re-keying"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Re-keying </h3> <p>On receiving a bundle from a given peer with a higher version, the old bundle SHOULD be marked as expired and a new session SHOULD be established on the next message sent.</p> <h3 id="multi-device-support"> <a href="#multi-device-support" class="anchor-heading" aria-labelledby="multi-device-support"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Multi-device support </h3> <p>Multi-device support is quite challenging as there is not a central place where information on which and how many devices (identified by their respective <code class="language-plaintext highlighter-rouge">installation-id</code>) belongs to a whisper-identity / waku-identity.</p> <p>Furthermore, account recovery always needs to be taken into consideration, where a user wipes clean the whole device and the nodes loses all the information about any previous sessions.</p> <p>Taking these considerations into account, the way the network propagates multi-device information using x3dh bundles, which will contain information about paired devices as well as information about the sending device.</p> <p>This means that every time a new device is paired, the bundle needs to be updated and propagated with the new information, the user has the responsibility to make sure the pairing is successful.</p> <p>The method is loosely based on https://signal.org/docs/specifications/sesame/ .</p> <h3 id="pairing"> <a href="#pairing" class="anchor-heading" aria-labelledby="pairing"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Pairing </h3> <p>When a user adds a new account in the <code class="language-plaintext highlighter-rouge">Status</code> application, a new <code class="language-plaintext highlighter-rouge">installation-id</code> will be generated. The device should be paired as soon as possible if other devices are present. Once paired the contacts will be notified of the new device and it will be included in further communications.</p> <p>If a bundle received from the <code class="language-plaintext highlighter-rouge">IK</code> is different to the <code class="language-plaintext highlighter-rouge">installation-id</code>, the device will be shown to the user and will have to be manually approved, to a maximum of 3. Once that is done any message sent by one device will also be sent to any other enabled device.</p> <p>Once a user enables a new device, a new bundle will be generated which will include pairing information.</p> <p>The bundle will be propagated to contacts through the usual channels.</p> <p>Removal of paired devices is a manual step that needs to be applied on each device, and consist simply in disabling the device, at which point pairing information will not be propagated anymore.</p> <h3 id="sending-messages-to-a-paired-group"> <a href="#sending-messages-to-a-paired-group" class="anchor-heading" aria-labelledby="sending-messages-to-a-paired-group"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Sending messages to a paired group </h3> <p>When sending a message, the peer will send a message to other <code class="language-plaintext highlighter-rouge">installation-id</code> that they have seen. The node caps the number of devices to 3, ordered by last activity. The node sends messages using pairwise encryption, including their own devices.</p> <h3 id="account-recovery-1"> <a href="#account-recovery-1" class="anchor-heading" aria-labelledby="account-recovery-1"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Account recovery </h3> <p>Account recovery is no different from adding a new device, and it is handled in exactly the same way.</p> <h3 id="partitioned-devices"> <a href="#partitioned-devices" class="anchor-heading" aria-labelledby="partitioned-devices"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Partitioned devices </h3> <p>In some cases (i.e. account recovery when no other pairing device is available, device not paired), it is possible that a device will receive a message that is not targeted to its own <code class="language-plaintext highlighter-rouge">installation-id</code>. In this case an empty message containing bundle information is sent back, which will notify the receiving end of including this device in any further communication.</p> <h2 id="changelog"> <a href="#changelog" class="anchor-heading" aria-labelledby="changelog"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Changelog </h2> <h3 id="version-03"> <a href="#version-03" class="anchor-heading" aria-labelledby="version-03"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Version 0.3 </h3> <p>Released <a href="https://github.com/status-im/specs/commit/664dd1c9df6ad409e4c007fefc8c8945b8d324e8">May 22, 2020</a></p> <ul> <li>Added language to include Waku in all relevant places</li> </ul> <h2 id="copyright"> <a href="#copyright" class="anchor-heading" aria-labelledby="copyright"><svg viewBox="0 0 16 16" aria-hidden="true"><use xlink:href="#svg-link"></use></svg></a> Copyright </h2> <p>Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>.</p> </div> </div> <div class="search-overlay"></div> </div> </body> </html>
Reference in New Issue View Git Blame Copy Permalink