moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.3 RC1 added several ideas from ZRTP 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@195 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2006-11-21 15:06:20 +00:00
parent 02d17475e2
commit 45ca755e90
1 changed files with 327 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

464
xep-0188.xml
View File

@ -6,6 +6,19 @@
<!ENTITY dsupx "d<span class='super'>x</span>">
<!ENTITY gsupx "g<span class='super'>x</span>">
<!ENTITY gsupy "g<span class='super'>y</span>">
<!ENTITY Hsube "He">
<!ENTITY AIDsubA "AID<span class='sub'>A</span>">
<!ENTITY AIDsubB "AID<span class='sub'>B</span>">
<!ENTITY RSsubA "RS<span class='sub'>A</span>">
<!ENTITY RSsubB "RS<span class='sub'>B</span>">
<!ENTITY HsubRSA "Hrs<span class='sub'>A</span>">
<!ENTITY HsubRSB "Hrs<span class='sub'>B</span>">
<!ENTITY OSsubA "OS<span class='sub'>A</span>">
<!ENTITY OSsubB "OS<span class='sub'>B</span>">
<!ENTITY HsubOSA "Hos<span class='sub'>A</span>">
<!ENTITY HsubOSB "Hos<span class='sub'>B</span>">
<!ENTITY isPKsubA "isPK<span class='sub'>A</span>">
<!ENTITY isPKsubB "isPK<span class='sub'>B</span>">
<!ENTITY NsubA "N<span class='sub'>A</span>">
<!ENTITY NsubB "N<span class='sub'>B</span>">
<!ENTITY CsubA "C<span class='sub'>A</span>">
@ -25,6 +38,10 @@
<!ENTITY IDB "ID<span class='sub'>B</span>">
<!ENTITY formA "form<span class='sub'>A</span>">
<!ENTITY formB "form<span class='sub'>B</span>">
<!ENTITY form1A "form<span class='sub'>1A</span>">
<!ENTITY form1B "form<span class='sub'>1B</span>">
<!ENTITY form2A "form<span class='sub'>2A</span>">
<!ENTITY form2B "form<span class='sub'>2B</span>">
<!ENTITY macA "mac<span class='sub'>A</span>">
<!ENTITY macB "mac<span class='sub'>B</span>">
<!ENTITY signA "sign<span class='sub'>A</span>">
@ -39,6 +56,12 @@
<!ENTITY signKeysA "signKeys<span class='sub'>A</span>">
<!ENTITY x1xZ "x<span class='sub'>1</span>...x<span class='sub'>Z</span>">
<!ENTITY e1eZ "e<span class='sub'>1</span>...e<span class='sub'>Z</span>">
<!ENTITY He1HeZ "He<span class='sub'>1</span>...He<span class='sub'>Z</span>">
<!ENTITY rfc3711 "<span class='ref'>RFC 3711</span> <note>RFC 3711: Secure Real-time Transport Protocol &lt;<link url='http://www.ietf.org/rfc/rfc3711.txt'>http://www.ietf.org/rfc/rfc3711.txt</link>&gt;.</note>" >
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
@ -58,6 +81,12 @@
<supersededby>None</supersededby>
<shortname>cryptoesession</shortname>
&ianpaterson;
<revision>
<version>0.3</version>
<date>2006-11-21</date>
<initials>ip</initials>
<remark><p>Added PKI Independence and Robustness requirements; added optional public key independence, hash commitment, SAS authentication, retained secrets and other secrets to SIGMA-R key exchange</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2006-07-19</date>
@ -93,10 +122,10 @@
<section1 topic='The Session Approach' anchor='approach'>
<p>Existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> uses "new-style" S/MIME object encryption, both specify the use of object encryption. <!--(Another object encryption technology is &w3xmlsig;, which was rejected as a possible approach to end-to-end encryption for XMPP systems because of its inherent complexity and difficulty of implementation.)--></p>
<p>However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of more secure approaches to encryption that are not feasible for less dynamic technologies (like email).</p>
<p>The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4301; and &rfc4253;) than to traditional encryption of files and standalone email messages.</p>
<p>However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of more secure approaches to encryption (including Perfect Forward Secrecy) that are not feasible for less dynamic technologies (like email).</p>
<p>The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4301; and &rfc4253;) or &zrtp; (an acclaimed &rfc3711; key agreement protocol) than to traditional encryption of files and standalone email messages.</p>
<p>Therefore, this document specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper is read first.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper and the <cite>ZRTP</cite> Internet-Draft are read first.</p>
</section1>
<section1 topic="Dramatis Personae" anchor='personae'>
@ -116,9 +145,11 @@
<li>Integrity</li>
<li>Replay protection</li>
<li>Perfect forward secrecy</li>
<li>PKI Independence</li>
<li>Authentication</li>
<li>Identity Protection</li>
<li>Repudiability</li>
<li>Robustness</li>
<li>Upgradability</li>
</ul>
<p>Each of these requirements is explained in greater depth below.</p>
@ -134,8 +165,11 @@
<section3 topic='Perfect Forward Secrecy' anchor='reqs-forward'>
<p>The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). <note>Long-lived keys are typically used for a few years, whereas Offline ESession keys are destroyed as soon as the stanza is decrypted - they typically exist for just a few hours. So Perfect Forward Secrecy should significantly enhance the security even of Offline ESessions.</note></p>
</section3>
<section3 topic='PKI Independence' anchor='reqs-pki'>
<p>The protocol must not rely on any public key infrastructure (PKI), certification authority, web of trust, or any other trust model that is external to the trust established between Alice and Bob. However, if external authentication or trust models are available then Alice and Bob must be able to use them to enhance any trust that exists between them.</p>
</section3>
<section3 topic='Authentication' anchor='reqs-auth'>
<p>Each party to a conversation MUST know that the other party is who he says he is (Alice must be able to know that Bob really is Bob, and vice versa). <note>The reliable association between an entity and its public keys is beyond the scope of this document.</note></p>
<p>Each party to a conversation MUST know that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, and vice versa). <note>Authentication is not identification, authentication may be as simple as Alice confirming that Bob is the same Bob that she communicated with yesterday or that she talked to on the telephone. The reliable association between an entity and its public keys is "identification" and therefore beyond the scope of this document.</note></p>
</section3>
<section3 topic='Identity Protection' anchor='reqs-id-protect'>
<p>No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. However, the public keys they use SHOULD NOT be revealed to other entities using a passive attack. Bob SHOULD also be able to choose between protecting either his public key or Alice's public key from disclosure through active ("man-in-the-middle") attacks.</p>
@ -143,6 +177,9 @@
<section3 topic='Repudiability' anchor='reqs-repudiate'>
<p>Alice and Bob MUST be able to repudiate any stanza that occurs within an ESession. After an ESession has finished, it SHOULD NOT be possible to <em>prove cryptographically</em> that any transcript has not been modified by a third party. <note>Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this document.</note></p>
</section3>
<section3 topic='Robustness' anchor='reqs-robust'>
<p>The protocol must provide more than one difficult challenge that must be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible - like retained secrets or optional passwords).</p>
</section3>
<section3 topic='Upgradability' anchor='reqs-upgrade'>
<p>The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. <note>It is exceptionally difficult to design a truly secure authenticated key-exchange protocol. Weaknesses are often only discovered after years of expert cryptographic analysis. In many cases, only the widespread use of a protocol will motivate experts to undertake exhaustive analyses and recommend enhancements.</note></p>
</section3>
@ -167,7 +204,7 @@
<p>The only good security technology is an implemented security technology. The solution should be one that typical client developers can implement in a relatively straightforward and interoperable fashion.</p>
</section3>
<section3 topic='Usability' anchor='reqs-usable'>
<p>The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. We can do better.</p>
<p>The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. If the users are prepared to verify the integrity of their copies of each other's keys then the necessary actions should be limited to a one-time out-of-band verification of a string of up to 6 alphanumeric characters.</p>
</section3>
<section3 topic='Efficiency' anchor='reqs-efficient'>
<p>Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large especially public keys and certificates. The solution should perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for ESession negotiation should be minimized.</p>
@ -187,14 +224,16 @@
</section2>
</section1>
<section1 topic='Cryptographic Origins - SIGMA' anchor='foundations'>
<section1 topic='Cryptographic Origins' anchor='foundations'>
<section2 topic='Introduction' anchor='foundations-intro'>
<p>Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the &sigma;<note>Like <cite>RFC 2409</cite>, this protocol uses <em>variant (ii)</em>, as described in Secion 5.4 of the <cite>SIGMA</cite> paper.</note> key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).</p>
<p>Note: Although this section provides an overview of SIGMA, it is recommended that the <cite>SIGMA</cite> paper is read first in order to gain a thorough understanding of this document.</p>
<p>The 3-message SIGMA-I-based key exchange protects the identity of the <em>initiator</em> against active attacks. The 4-message SIGMA-R-based key exchange defends the <em>responder's</em> identity against active attacks. The differences between the two versions of the SIGMA protocol are highlighted in the diagrams below.</p>
<p>Note: Although this section provides an overview of SIGMA, it is strongly recommended that the <cite>SIGMA</cite> paper is read first in order to gain a thorough understanding of this document.</p>
<p>The 3-message SIGMA-I-based key exchange protects the identity of the <em>initiator</em> against active attacks. This SHOULD NOT be used to establish client to client sessions since the <em>responder's</em> identity is not protected against active attacks. However, it SHOULD be used to establish client to service (server) sessions, especially where the identity of the service is well known to third parties.</p>
<p>The two 4-message SIGMA-R-based key exchanges with hash commitment defend the <em>responder's</em> identity against active attacks and facilitate detection of a Man in the Middle attack. They SHOULD be used to establish client to client sessions.</p>
<p>Note: The block cipher function, <em>cipher</em>, uses CTR mode.</p>
</section2>
<section2 topic='SIGMA Parameter Descriptions' anchor='foundations-parameters'>
<table caption='SIGMA Overview Parameters'>
<table caption='SIGMA and SAS Overview Parameters'>
<tr>
<th>Parameter</th>
<th>Description</th>
@ -211,9 +250,13 @@
<td>&gsupx;, &gsupy;</td>
<td>Alice and Bob's public Diffie-Hellman keys</td>
</tr>
<tr>
<td>H&gsupx;</td>
<td>Hash of Alice's public Diffie-Hellman key</td>
</tr>
<tr>
<td>&KSsubA;, &KSsubB;</td>
<td>The MAC keys that Alice and Bob use to calculate &macA; and &macB;</td>
<td>The MAC keys (derived from K) that Alice and Bob use to calculate &macA; and &macB;</td>
</tr>
<tr>
<td>&pubKeyA;, &pubKeyB;</td>
@ -233,12 +276,16 @@
</tr>
<tr>
<td>&KCsubA;, &KCsubB;</td>
<td>The cipher keys that Alice and Bob use to encrypt</td>
<td>The cipher keys (derived from K) that Alice and Bob use to encrypt</td>
</tr>
<tr>
<td>&IDA;, &IDB;</td>
<td>The encrypted parameters that identify Alice and Bob to each other</td>
</tr>
<tr>
<td>SAS</td>
<td>Short Authentication string</td>
</tr>
</table>
<table caption='Key Exchange Parameters'>
<tr>
@ -253,9 +300,13 @@
<td>e, d</td>
<td>Alice and Bob's public Diffie-Hellman keys (the same as &gsupx;, &gsupy;)</td>
</tr>
<tr>
<td>&Hsube;</td>
<td>Hash of Alice's public Diffie-Hellman key</td>
</tr>
<tr>
<td>K</td>
<td>Shared secret</td>
<td>Shared secret (derived by Alice from &gsupy; and x, or by Bob from &gsupx; and y)</td>
</tr>
<tr>
<td>HASH</td>
@ -275,12 +326,36 @@
</tr>
<tr>
<td>&KMsubA;, &KMsubB;</td>
<td>The MAC keys that Alice and Bob use to protect the integrity of encrypted data</td>
<td>The MAC keys (derived from K) that Alice and Bob use to protect the integrity of encrypted data</td>
</tr>
<tr>
<td>&MsubA;, &MsubB;</td>
<td>The MAC values that Alice and Bob use to confirm the integrity of encrypted data</td>
</tr>
<tr>
<td>&RSsubA;, &RSsubB;</td>
<td>Retained secrets of Alice and Bob (derived from K in previous session)</td>
</tr>
<tr>
<td>&HsubRSA;, &HsubRSB;</td>
<td>Hashes of retained secrets of Alice and Bob</td>
</tr>
<tr>
<td>&OSsubA;, &OSsubB;</td>
<td>Other secrets of Alice and Bob (e.g. hashes of known strings and a shared password)</td>
</tr>
<tr>
<td>&HsubOSA;, &HsubOSB;</td>
<td>Hashes of other secrets of Alice and Bob</td>
</tr>
<tr>
<td>&isPKsubA;, &isPKsubB;</td>
<td>Whether or not Alice and Bob have a private key (booleans)</td>
</tr>
<tr>
<td>&AIDsubA;, &AIDsubB;</td>
<td>Anonymous IDs of Alice and Bob</td>
</tr>
</table>
</section2>
@ -294,10 +369,10 @@
&macB; = <em>HMAC</em>(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, {&pubKeyB;, &signB;})
&gsupy;, <highlight>&IDB;</highlight>&#160;
&gsupy;, &IDB;&#160;
&lt;------------
<highlight><em>authenticate</em>(&IDB;)</highlight>&#160;
<em>authenticate</em>(&IDB;)&#160;
&macA; = <em>HMAC</em>(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
&signA; = <em>sign</em>(&signKeyA;, &macA;)
&IDA; = <em>cipher</em>(&KCsubA;, {&pubKeyA;, &signA;})
@ -308,49 +383,75 @@
</pre>
</section2>
<section2 topic='SIGMA-R Overview' anchor='foundations-skeleton-r'>
<p>The logic of the SIGMA-R protocol is similar to the SIGMA-I protocol. The diagram below demonstrates the skeleton of the key exchange. After receiving the first message from Alice, Bob chooses to protect his identity from active attacks by by delaying communicating his identity to Alice until he has authenticated her.</p>
<section2 topic='SAS-Only Overview' anchor='foundations-skeleton-sas'>
<p>The diagram below demonstrates the skeleton of the Diffie-Hellman key exchange that employs out-of-band SAS authentication. If Alice and Bob's public keys are not yet trusted, or if their private keys have been compromised, then the hash commitment sent in the first step enables Alice and Bob to verify their copies of each other's Diffie-Hellman (and public) keys and detect a Man in the Middle more easily.</p>
<p>If a Man in the Middle changes the public Diffie-Hellman keys that Alice and Bob receive, then he could potentially use his knowledge of the SAS that Bob will eventually calculate when choosing the key he will send to Alice in the second step. However, the fact that the value he received in the first step is only a hash means the Man in the Middle must choose the key he sends to Alice before he can predict the SAS that she will calculate with it. Therefore, even if the SAS is very short, he is unable to use his resources to choose a key that will (have a better than random chance to) result in a SAS that matches Bob's. So only a truncated version of the HASH of Alice and Bob's keys needs to be verified out-of-band in the final step.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
H&gsupx;
------------&gt;
&gsupy;
&lt;------------
SAS = <em>truncate</em>(HASH(&gsupx;, &gsupy;))
&gsupx;
------------&gt;
&macB; = <em>HMAC</em>(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, {&pubKeyB;, &signB;})
<em>assert</em> H&gsupx; = HASH(&gsupx;)
SAS = <em>truncate</em>(HASH(&gsupx;, &gsupy;))
SAS
&lt;===========&gt;
</pre>
</section2>
<section2 topic='SIGMA-R with SAS Overview' anchor='foundations-skeleton-r'>
<p>The logic of the four-step SIGMA-R protocol is similar to the three-step SIGMA-I protocol. The difference being that Bob protects his identity from active attacks by by delaying communicating his identity to Alice until he has authenticated her. The diagram below demonstrates the skeleton of the key exchange. Note that it also takes advantage of the extra step required for SIGMA-R to incorporate a hash commitment, thus enabling <em>optional</em> out-of-band SAS authentication.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
H&gsupx;
------------&gt;
&gsupy;
&lt;------------
&macA; = <em>HMAC</em>(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
&signA; = <em>sign</em>(&signKeyA;, &macA;)
&IDA; = <em>cipher</em>(&KCsubA;, {&pubKeyA;, &signA;})
&IDA;
SAS = <em>truncate</em>(HASH(&gsupx;, &gsupy;))
&gsupx;, &IDA;
------------&gt;
<em>authenticate</em>(&IDA;)
<highlight>&IDB;
&lt;------------
<em>assert</em> H&gsupx; = HASH(&gsupx;)
SAS = <em>truncate</em>(HASH(&gsupx;, &gsupy;))
SAS
&lt;===========&gt;
<em>authenticate</em>(&IDB;)</highlight>
<em>authenticate</em>(&IDA;)
&macB; = <em>HMAC</em>(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, {&pubKeyB;, &signB;})
&IDB;
&lt;------------
<em>authenticate</em>(&IDB;)
</pre>
<p>Note: In practice, Bob could delay calculating &IDB; until after he has authenticated &IDA;.</p>
</section2>
<section2 topic='SIGMA-I Key Exchange' anchor='foundations-core-i'>
<p>The diagram below describes exactly the same SIGMA-I key exchange protocol as the <link url='#foundations-skeleton-i'>SIGMA-I skeleton</link> above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, <em>cipher</em>, uses CTR mode.</p>
<p>The diagram below describes exactly the same SIGMA-I key exchange protocol as the <link url='#foundations-skeleton-i'>SIGMA-I Overview</link> above. It provides much more detail, without specifying any ESession-specific details. The differences between it and the <link url='#foundations-core-r'>SIGMA-R with SAS Key Exchange</link> are highlighted.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
&NsubA; = <em>random</em>()
x = <em>random</em>()
e = &gsupx; mod p
&NsubA; = <em>random</em>()
e, &NsubA;
<span class='highlight'>e,</span>&#160;&NsubA;
------------&gt;
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; e &lt; p-1
&NsubB; = <em>random</em>()
<span class='highlight'><em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
@ -358,14 +459,13 @@ e = &gsupx; mod p
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&NsubB; = <em>random</em>()
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)</span>&#160;
d, &CsubA;, &NsubB;
&lt;------------
<highlight>&IDB;, &MsubB;</highlight>&#160;
<span class='highlight'>&IDB;, &MsubB;</span>&#160;
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; d &lt; p-1
K = HASH(&dsupx; mod p)
@ -375,10 +475,10 @@ K = HASH(&dsupx; mod p)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
<highlight><em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
<span class='highlight'><em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = <em>decipher</em>(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
<em>verify</em>(&signB;, &pubKeyB;, &macB;)</highlight>&#160;
<em>verify</em>(&signB;, &pubKeyB;, &macB;)</span>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
&signA; = <em>sign</em>(&signKeyA;, &macA;)
&IDA; = <em>cipher</em>(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
@ -393,35 +493,29 @@ K = HASH(&dsupx; mod p)
</pre>
</section2>
<section2 topic='SIGMA-R Key Exchange' anchor='foundations-core-r'>
<p>The diagram below describes exactly the same SIGMA-R key exchange protocol as the <link url='#foundations-skeleton-r'>SIGMA-R skeleton</link> above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, <em>cipher</em>, uses CTR mode.</p>
<section2 topic='SIGMA-R with SAS Key Exchange' anchor='foundations-core-r'>
<p>The Short Authentication String technique enables protection against a Man in the Middle without the need to generate, distribute or authenticate any public keys. As long as a hash commitment is used at the start of the key exchange then only a short human-friendly string needs to be verified out-of-band (e.g. by recognizable voice communication).</p>
<p>Furthermore, if each entity (or each user of a client installation) is assigned a large random Anonymous ID (AID) upon first use, and if retained secrets associated with the AID are employed <em>consistently</em> during key exchanges, then the Man in the Middle would need to be present for every session, including the first, and the out-of-band verification would only need to be performed once to verify the absence of a Man in the Middle for all sessions between the parties (past, present and future). <note>This combination of techniques underpins the <cite>ZRTP</cite> key agreement protocol.</note></p>
<p>Public keys are optional in the diagram below. It describes the same SIGMA-R with SAS key exchange protocol as the <link url='#foundations-skeleton-r'>SIGMA-R Overview</link>. It provides much more detail including the use of retained secrets and other secrets. Note: These <em>optional</em> security enhancements are especially important when the protocol is being used without public keys.</p>
<p>The diagram does not specify any ESession-specific details. The differences between it and the <link url='#foundations-core-i'>SIGMA-I Key Exchange</link> are highlighted.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
&NsubA; = <em>random</em>()
x = <em>random</em>()
e = &gsupx; mod p
&NsubA; = <em>random</em>()
e, &NsubA;
<span class='highlight'>&Hsube; = HASH(e, &NsubA;)
&Hsube;, &isPKsubA;</span>
------------&gt;
&NsubA;&#160;
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
&KMsubA; = HASH(2, K)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&NsubB; = <em>random</em>()
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
d, &CsubA;, &NsubB;
&lt;------------
<span class='highlight'>&isPKsubB;</span>&#160;
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; d &lt; p-1
K = HASH(&dsupx; mod p)
@ -431,33 +525,80 @@ K = HASH(&dsupx; mod p)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
&signA; = <em>sign</em>(&signKeyA;, &macA;)
&IDA; = <em>cipher</em>(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
<span class='highlight'>SAS = <em>truncate</em>(HASH(e, d))
<em>if</em>&#160;&isPKsubA;&#160;<em>is false:</em>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &AIDsubA;, &HsubRSA;, &HsubOSA;})
&IDA; = <em>cipher</em>(&KCsubA;, &CsubA;, {&AIDsubA;, &macA;})
<em>else:</em></span>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &HsubRSA;, &HsubOSA;})
&signA; = <em>sign</em>(&signKeyA;, &macA;)
&IDA; = <em>cipher</em>(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;
&IDA;, &MsubA;, <span class='highlight'>e</span>
------------&gt;
&MsubA;&#160;
<span class='highlight'>&HsubRSA;, &HsubOSA;&#160;
<em>assert</em>&#160;&Hsube; = HASH(e, &NsubA;)
SAS = <em>truncate</em>(HASH(e, d))
SAS
&lt;===========&gt;
<em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
&KMsubA; = HASH(2, K)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)</span>&#160;
<em>assert</em>&#160;&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
{&pubKeyA;, &signA;} = <em>decipher</em>(&KCsubA;, &CsubA;, &IDA;)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
<em>verify</em>(&signA;, &pubKeyA;, &macA;)
<highlight>&IDB;
<span class='highlight'><em>if</em>&#160;&isPKsubA;&#160;<em>is false:</em>&#160;
{&AIDsubA;, &macA;} = <em>decipher</em>(&KCsubA;, &CsubA;, &IDA;)
<em>assert</em>&#160;&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &AIDsubA;, &HsubRSA;, &HsubOSA;})
<em>else:</em></span>&#160;
{&pubKeyA;, &signA;} = <em>decipher</em>(&KCsubA;, &CsubA;, &IDA;)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &HsubRSA;, &HsubOSA;})
<em>verify</em>(&signA;, &pubKeyA;, &macA;)
<span class='highlight'><em>assert</em>&#160;&HsubRSA; = HASH(&RSsubA;)
<em>assert</em>&#160;&HsubOSA; = HASH(&OSsubA;)
&KCsubA; = HASH(&KCsubA;, &RSsubA;, &OSsubA;)
&KCsubB; = HASH(&KCsubB;, &RSsubB;, &OSsubB;)
&RSsubA; = HASH(6, K)
&RSsubB; = HASH(7, K)
<em>if</em>&#160;&isPKsubB;&#160;<em>is false:</em>&#160;
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &AIDsubB;, &CsubA;, &HsubRSB;, &HsubOSB;})
&IDB; = <em>cipher</em>(&KCsubB;, &CsubB;, {&AIDsubB;, &macB;})&#160;
<em>else:</em>&#160;
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;, &HsubRSB;, &HsubOSB;})
&signB; = <em>sign</em>(&signKeyB;, &macB;)
&IDB; = <em>cipher</em>(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
&IDB;, &MsubB;
&lt;------------
&MsubB;&#160;
&HsubRSB;, &HsubOSB;&#160;
<em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = <em>decipher</em>(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
<em>verify</em>(&signB;, &pubKeyB;, &macB;)</highlight>
<em>if</em>&#160;&isPKsubB;&#160;<em>is false:</em>&#160;
<span class='highlight'>{&AIDsubB;, &macB;} = <em>decipher</em>(&KCsubB;, &CsubB;, &IDB;)
<em>assert</em>&#160;&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &AIDsubB;, &CsubA;, &HsubRSB;, &HsubOSB;})
<em>else:</em></span>&#160;
{&pubKeyB;, &signB;} = <em>decipher</em>(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;, &HsubRSB;, &HsubOSB;})
<em>verify</em>(&signB;, &pubKeyB;, &macB;)
<em>assert</em>&#160;&HsubRSB; = HASH(&RSsubB;)
<em>assert</em>&#160;&HsubOSB; = HASH(&OSsubB;)
&KCsubA; = HASH(&KCsubA;, &RSsubA;, &OSsubA;)
&KCsubB; = HASH(&KCsubB;, &RSsubB;, &OSsubB;)
&RSsubA; = HASH(6, K)
&RSsubB; = HASH(7, K)</span>
</pre>
</section2>
</section1>
<section1 topic='Cryptographic Design' anchor='design'>
<p>This section provides an overview of the full ESession key-exchange protocol from a cryptographic point of view. This protocol is based on the <em>full fledge</em> protocol, as described in Appendix B of the <cite>SIGMA</cite> paper. It also uses <em>variant (ii)</em>, as described in Secion 5.4 of the same paper.</p>
<section2 topic='ESession Parameter Descriptions' anchor='design-parameters'>
<p>The table below describes the parameters that are not found in the <link url='#foundations-parameters'>Parameter Descriptions</link> tables at the start of the previous section.</p>
<p>The table below describes the parameters that are not found in the <link url='#foundations-parameters'>Parameter Descriptions</link> tables above.</p>
<table caption='ESession Negotiation Parameters'>
<tr>
<th>Parameter</th>
@ -495,6 +636,10 @@ K = HASH(&dsupx; mod p)
<td>&e1eZ;</td>
<td>The choice of public Diffie-Hellman keys that Alice offers Bob - each value corresponds to one of Z different DH groups (and a different value of x)</td>
</tr>
<tr>
<td>&He1HeZ;</td>
<td>The list of hash commitments that Alice sends to Bob (hashes of &e1eZ;)</td>
</tr>
<tr>
<td>*&signKeysA;</td>
<td>All the private keys that Alice is able to use to create signatures</td>
@ -511,26 +656,28 @@ K = HASH(&dsupx; mod p)
<p>* Offline negotiation only</p>
</section2>
<section2 topic='Online ESession-I Negotiation' anchor='design-online-i'>
<p>Alice uses this protocol when Bob is Online. In addition to the key exchange described in the <link url='#foundations-core-i'>SIGMA-I Key Exchange</link> protocol above, she offers Bob a choice of Diffie-Hellman groups with her corresponding values of e, various algorithms and other parameters.</p>
<p>Alice uses this protocol when Bob is Online. In addition to the key exchange described in the <link url='#foundations-core-i'>SIGMA-I Key Exchange</link> protocol above, she offers Bob a choice of Diffie-Hellman groups with her corresponding values of e, various algorithms and other parameters. The differences between this protocol and <link url='#design-online-r'>Online ESession-R Negotiation</link> are highlighted.</p>
<!--The first two forms below negotiate policy, swap Diffie-Hellman public values and the ancillary data necessary for the exchange and authentication. The second message also authenticates the responder. The third message authenticates the initiator and exchanges the final Diffie-Hellman public value.-->
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
&NsubA; = <em>random</em>()
<em>for</em> g,p &#8712; options
x = <em>random</em>()
e = &gsupx; mod p
&NsubA; = <em>random</em>()
&formA; = {&e1eZ;, options, &NsubA;}
&formA; = {<span class='highlight'>&e1eZ;</span>, options, &NsubA;}
&formA;
---------&gt;
chosen = {p,g,HASH,CIPHER,SIGN...} = <em>choose</em>(options)
e = <em>choose</em>(&e1eZ;, p)
<span class='highlight'>e</span> = <em>choose</em>(<span class='highlight'>&e1eZ;</span>, p)
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; e &lt; p-1
&NsubB; = <em>random</em>()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
<span class='highlight'><em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
@ -538,15 +685,13 @@ K = HASH(&dsupx; mod p)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&NsubB; = <em>random</em>()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)</span>&#160;
&formB;
&lt;---------
<highlight>&IDB;, &MsubB;</highlight>&#160;
<span class='highlight'>&IDB;, &MsubB;</span>&#160;
<em>assert</em> chosen &#8712; options
x = <em>choose</em>(&x1xZ;, p)
e = &gsupx; mod p
@ -559,17 +704,17 @@ K = HASH(&dsupx; mod p)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
<highlight><em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
<span class='highlight'><em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
VERIFY(&signB;, &pubKeyB;, &macB;)</highlight>&#160;
VERIFY(&signB;, &pubKeyB;, &macB;)</span>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
&signA; = SIGN(&signKeyA;, &macA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;
&IDA;
---------&gt;
&NsubB;, &MsubA;&#160;
&MsubA;, <span class='highlight'>&NsubB;</span>&#160;
<em>assert</em>&#160;&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
{&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
@ -578,41 +723,30 @@ VERIFY(&signB;, &pubKeyB;, &macB;)</highlight>&#160;
</section2>
<section2 topic='Online ESession-R Negotiation' anchor='design-online-r'>
<p>This protocol is similar to the <link url='#design-online-i'>Online ESession-I Negotiation</link> above, except that after receiving the first message from Alice, Bob chooses to protect his identity from active attacks (by by delaying communicating his identity to Alice until he has authenticated her).</p>
<p>This protocol is similar to the <link url='#design-online-i'>Online ESession-I Negotiation</link> above, except that Bob's identity is protected from active attacks (by by delaying communicating his identity to Alice until he has authenticated her). The optional use of SAS, retained secrets and other secrets means the protocol may be used without any public keys. The differences between this protocol and <link url='#design-online-i'>Online ESession-I Negotiation</link> are highlighted.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
<strong>ALICE</strong>&#160; <strong>BOB</strong>&#160;
&NsubA; = <em>random</em>()
<em>for</em> g,p &#8712; options
x = <em>random</em>()
e = &gsupx; mod p
&NsubA; = <em>random</em>()
&formA; = {&e1eZ;, options, &NsubA;}
&formA;
---------&gt;
<span class='highlight'>He = HASH(e, &NsubA;)</span>&#160;
&form1A; = {<span class='highlight'>&He1HeZ;</span>, options, &NsubA;, <span class='highlight'>&isPKsubA;</span>}
chosen = {p,g,HASH,CIPHER,SIGN...} = <em>choose</em>(options)
e = <em>choose</em>(&e1eZ;, p)
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
<em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
&KMsubA; = HASH(2, K)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&NsubB; = <em>random</em>()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
&form1A;
------------&gt;
&formB;
&lt;---------
chosen = {p,g,HASH,CIPHER,SIGN...} = <em>choose</em>(options)
<span class='highlight'>&Hsube;</span> = <em>choose</em>(<span class='highlight'>&He1HeZ;</span>, p)
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
&NsubB; = <em>random</em>()
&form1B; = {&CsubA;, chosen, d, &NsubA;, &NsubB;, <span class='highlight'>&isPKsubB;</span>}
&form1B;
&lt;------------
<em>assert</em> chosen &#8712; options
x = <em>choose</em>(&x1xZ;, p)
e = &gsupx; mod p
@ -625,61 +759,119 @@ K = HASH(&dsupx; mod p)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
&signA; = SIGN(&signKeyA;, &macA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
<span class='highlight'>SAS = <em>truncate</em>(HASH(e, d))
&form2A; = {e, &NsubB;, &HsubRSA;, &HsubOSA;}
<em>if</em>&#160;&isPKsubA;&#160;<em>equals false:</em>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, &form2A;, &AIDsubA;, &form1A;})
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&AIDsubA;, &macA;})
<em>else:</em>&#160;</span>&#160;
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, &form2A;, &pubKeyA;, &form1A;})
&signA; = SIGN(&signKeyA;, &macA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;
---------&gt;
&NsubB;, &MsubA;&#160;
<em>assert</em>&#160;&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
{&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
VERIFY(&signA;, &pubKeyA;, &macA;)
<highlight>&IDB;
&lt;---------
&NsubA;, &MsubB;&#160;
&IDA;, &MsubA;
------------&gt;
<span class='highlight'>&form2A;&#160;
<em>assert</em>&#160;&Hsube; = HASH(e, &NsubA;)
SAS = <em>truncate</em>(HASH(e, d))
SAS
&lt;===========&gt;
<em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
&KCsubB; = HASH(1, K)
&KMsubA; = HASH(2, K)
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
</span><em>assert</em>&#160;&MsubA; = <em>HMAC</em>(HASH, &KMsubA;, &CsubA;, &IDA;)
<span class='highlight'><em>if</em>&#160;&isPKsubA;&#160;<em>equals false:</em>&#160;
{&AIDsubA;, &macA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
<em>assert</em>&#160;&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, &form2A;, &AIDsubA;, &form1A;})
<em>else:</em></span>&#160;
{&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
&macA; = <em>HMAC</em>(HASH, &KSsubA;, {&NsubB;, &NsubA;, &form2A;, &pubKeyA;, &form1A;})
VERIFY(&signA;, &pubKeyA;, &macA;)
<span class='highlight'><em>if</em>&#160;&HsubOSA;&#160;<em>equals</em> HASH(&OSsubA;)
&KCsubA; = HASH(&KCsubA;, &OSsubA;)
&KCsubB; = HASH(&KCsubB;, &OSsubB;)
<em>if</em>&#160;&HsubRSA;&#160;<em>equals</em> HASH(&RSsubA;)
&KCsubA; = HASH(&KCsubA;, &RSsubA;)
&KCsubB; = HASH(&KCsubB;, &RSsubB;)
&RSsubA; = HASH(6, K)
&RSsubB; = HASH(7, K)
&form2B; = {&NsubA;, &HsubRSB;, &HsubOSB;}
<em>if</em>&#160;&isPKsubB;&#160;<em>equals false:</em>&#160;
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &AIDsubB;, &form1B;, &form2B;})
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&AIDsubB;, &macB;})&#160;
<em>else:</em>&#160;
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &form1B;, &form2B;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
&IDB;, &MsubB;&#160;
&lt;------------
&form2B;&#160;
<em>assert</em>&#160;&MsubB; = <em>HMAC</em>(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
VERIFY(&signB;, &pubKeyB;, &macB;)</highlight>
<em>if</em>&#160;&isPKsubB;&#160;<em>equals false:</em>&#160;
{&AIDsubB;, &macB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
<em>assert</em>&#160;&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &AIDsubB;, &form1B;, &form2B;})
<em>else:</em>&#160;
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &form1B;, &form2B;})
VERIFY(&signB;, &pubKeyB;, &macB;)
<em>if</em>&#160;&HsubOSB;&#160;<em>equals</em> HASH(&OSsubB;)
&KCsubA; = HASH(&KCsubA;, &OSsubA;)
&KCsubB; = HASH(&KCsubB;, &OSsubB;)
<em>if</em>&#160;&HsubRSB;&#160;<em>equals</em> HASH(&RSsubB;)
&KCsubA; = HASH(&KCsubA;, &RSsubA;)
&KCsubB; = HASH(&KCsubB;, &RSsubB;)
&RSsubA; = HASH(6, K)
&RSsubB; = HASH(7, K)</span>
</pre>
</section2>
<section2 topic='Offline ESession Negotiation' anchor='design-offline'>
<p>Bob uses this protocol to send stanzas to Alice when she is Offline. Note: Since the full <cite>SIGMA</cite> protocol cannot be used if Alice is offline, her identity is not protected.</p>
<p>Bob uses this protocol to send stanzas to Alice when she is Offline. Note: Since the full <cite>SIGMA</cite> protocol cannot be used if Alice is offline, her identity is not protected at all.</p>
<p>The diagram is split into three phases. First Alice publishes her ESession options before going offline. Later Bob completes the key exchange (and sends her encrypted stanzas that are not shown below) these are all stored by Alice's server. Finally when Alice comes online again she verifies and calculates the decryption key.</p>
<p>The differences between this offline protocol and the <link url='#design-online-i'>Online ESession-I Negotiation</link> protocol above are highlighted in the diagram below.</p>
<pre>
<strong>ALICE</strong>&#160; <strong>ALICE'S SERVER</strong>&#160; <strong>BOB</strong>&#160;
&NsubA; = <em>random</em>()
<em>for</em> g,p &#8712; options
x = <em>random</em>()
e = &gsupx; mod p
&NsubA; = <em>random</em>()
<highlight>&formA; = {&e1eZ;, options, &NsubA;}
&signsA; = <em>multi_sign</em>(&signKeysA;, &formA;)
<em>store</em>(&NsubA;, &x1xZ;, expireTime)
&formA; = {&e1eZ;, options, &NsubA;}
<span class='highlight'>&signsA; = <em>multi_sign</em>(&signKeysA;, &formA;)
<em>store</em>(&NsubA;, &x1xZ;, expireTime)</span>&#160;
&formA;
--------&gt;
&signsA;&#160;
<span class='highlight'>&signsA;&#160;
<em>store</em>(&formA;, &signsA;)
---------------------------------------------------------------------------------------------------------
<em>retrieve</em>(&formA;, &signsA;)
<em>retrieve</em>(&formA;, &signsA;)</span>&#160;
&formA;
--------&gt;
&signsA;&#160;
<span class='highlight'>&signsA;&#160;
<em>verify_one</em>(&signsA;, &pubKeysA;, &formA;)</highlight>
<em>verify_one</em>(&signsA;, &pubKeysA;, &formA;)</span>
chosen = {p,g,HASH,CIPHER,SIGN...} = <em>choose</em>(options)
e = <em>choose</em>(&e1eZ;, p)
&CsubA; = <em>random</em>()
y = <em>random</em>()
d = &gsupy; mod p
&CBeCAx2n1;&#160;
&NsubB; = <em>random</em>()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
<em>assert</em> 1 &lt; e &lt; p-1
K = HASH(&esupy; mod p)
&KCsubA; = HASH(0, K)
@ -688,8 +880,6 @@ VERIFY(&signB;, &pubKeyB;, &macB;)</highlight>
&KMsubB; = HASH(3, K)
&KSsubA; = HASH(4, K)
&KSsubB; = HASH(5, K)
&NsubB; = <em>random</em>()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
@ -699,15 +889,15 @@ VERIFY(&signB;, &pubKeyB;, &macB;)</highlight>
&lt;--------
&IDB;, &MsubB;&#160;
<highlight><em>store</em>(&formB;,&IDB;,&MsubB;)
<span class='highlight'><em>store</em>(&formB;,&IDB;,&MsubB;)
---------------------------------------------------------------------------------------------------------
<em>retrieve</em>(&formB;,&IDB;,&MsubB;)</highlight>&#160;
<em>retrieve</em>(&formB;,&IDB;,&MsubB;)</span>&#160;
&formB;
&lt;--------
&IDB;, &MsubB;&#160;
<highlight><em>retrieve</em>(&NsubA;, &x1xZ;, expireTime)</highlight>&#160;
<em>assert</em> now &lt; expireTime
<span class='highlight'><em>retrieve</em>(&NsubA;, &x1xZ;, expireTime)
<em>assert</em> now &lt; expireTime</span>&#160;
<em>assert</em> chosen &#8712; options
x = <em>choose</em>(&x1xZ;, p)
e = &gsupx; mod p