Clarify half-duplex.rev33test

3 files changed, 2 insertions, 2 deletions

diff --git a/noise.md b/noise.md
index 8a816dc..84eb9c5 100644
--- a/noise.md
+++ b/noise.md
@@ -1562,7 +1562,7 @@ are outside the scope of this document.
 
 11.5. Half-duplex protocols
 ----------------------------
-In some application protocols the parties strictly alternate sending messages.  In this case Noise can be used in a "half-duplex" mode [@blinker] where the first `CipherState` returned by `Split()` is used for encrypting messages in both directions.  This provides a small optimization, since `Split()` only has to output a single `CipherState`, and both parties only need to store a single `CipherState` during the transport phase.
+In some application protocols the parties strictly alternate sending messages.  In this case Noise can be used in a "half-duplex" mode [@blinker] where the first `CipherState` returned by `Split()` is used for encrypting messages in both directions, and the second `CipherState` returned by `Split()` is unused.  This allows some small optimizations, since `Split()` only has to calculate a single output `CipherState`, and both parties only need to store a single `CipherState` during the transport phase.
 
 This feature must be used with extreme caution.  In particular, it would be a catastrophic security failure if the protocol is not strictly alternating and both parties encrypt different messages using the same `CipherState` and nonce value.
 
diff --git a/output/noise.html b/output/noise.html
index 51a959c..2f77040 100644
--- a/output/noise.html
+++ b/output/noise.html
@@ -1073,7 +1073,7 @@ XXfallback(e, s, rs):
 <p>Recipients doing this must track the received <code>n</code> values for which decryption was successful and reject any message which repeats such a value, to prevent replay attacks.</p>
 <p>Note that lossy and out-of-order message delivery introduces many other concerns (including out-of-order handshake messages and denial of service risks) which are outside the scope of this document.</p>
 <h2 id="half-duplex-protocols">11.5. Half-duplex protocols</h2>
-<p>In some application protocols the parties strictly alternate sending messages. In this case Noise can be used in a &quot;half-duplex&quot; mode <span class="citation">[<a href="#ref-blinker">6</a>]</span> where the first <code>CipherState</code> returned by <code>Split()</code> is used for encrypting messages in both directions. This provides a small optimization, since <code>Split()</code> only has to output a single <code>CipherState</code>, and both parties only need to store a single <code>CipherState</code> during the transport phase.</p>
+<p>In some application protocols the parties strictly alternate sending messages. In this case Noise can be used in a &quot;half-duplex&quot; mode <span class="citation">[<a href="#ref-blinker">6</a>]</span> where the first <code>CipherState</code> returned by <code>Split()</code> is used for encrypting messages in both directions, and the second <code>CipherState</code> returned by <code>Split()</code> is unused. This allows some small optimizations, since <code>Split()</code> only has to calculate a single output <code>CipherState</code>, and both parties only need to store a single <code>CipherState</code> during the transport phase.</p>
 <p>This feature must be used with extreme caution. In particular, it would be a catastrophic security failure if the protocol is not strictly alternating and both parties encrypt different messages using the same <code>CipherState</code> and nonce value.</p>
 <h1 id="dh-functions-cipher-functions-and-hash-functions">12. DH functions, cipher functions, and hash functions</h1>
 <h2 id="the-25519-dh-functions">12.1. The <code>25519</code> DH functions</h2>
diff --git a/output/noise.pdf b/output/noise.pdf
index 1c9a962..8985623 100644
--- a/output/noise.pdf
+++ b/output/noise.pdf