Script updating gh-pages from 3588c74. [ci skip]

proofreading/draft-irtf-cfrg-aegis-aead.html

@@ -3615,7 +3615,7 @@ <h4 id="name-committing-security">
           </h4>
 <p id="section-10.1.2-1">An authentication tag may verify under multiple keys, nonces, or associated data, but AEGIS is assumed to be key committing in the receiver-binding game. This mitigates common attacks when used with low-entropy keys such as passwords. Finding distinct keys and/or nonces that successfully verify the same <code>(ad, ct, tag)</code> tuple is expected to require ~2<sup>64</sup> attempts with a 128-bit authentication tag and ~2<sup>128</sup> attempts with a 256-bit tag.<a href="#section-10.1.2-1" class="pilcrow">¶</a></p>
 <p id="section-10.1.2-2">AEGIS is fully committing in the restricted setting where an adversary cannot control the associated data. As shown in <span>[<a href="#IR23" class="cite xref">IR23</a>]</span>, with the ability to alter the associated data, it is possible to efficiently find multiple keys that will verify the same authenticated ciphertext.<a href="#section-10.1.2-2" class="pilcrow">¶</a></p>
-<p id="section-10.1.2-3">Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the <code>ad</code> parameter of the <code>Encrypt</code> and <code>Decrypt</code> functions. For AEGIS-128L and AEGIS-128X, the selected hash function must ensure a minimum of 128-bit collision and preimage resistance. An instance of such a function is SHA-256 <span>[<a href="#RFC6234" class="cite xref">RFC6234</a>]</span>.<a href="#section-10.1.2-3" class="pilcrow">¶</a></p>
+<p id="section-10.1.2-3">Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the <code>ad</code> parameter of the <code>Encrypt</code> and <code>Decrypt</code> functions. The selected hash function must ensure a minimum of 128-bit collision and preimage resistance. An instance of such a function is SHA-256 <span>[<a href="#RFC6234" class="cite xref">RFC6234</a>]</span>.<a href="#section-10.1.2-3" class="pilcrow">¶</a></p>
 <p id="section-10.1.2-4">Alternatively, the associated data can be fed into a collision-resistant KDF, such as HKDF <span>[<a href="#RFC5869" class="cite xref">RFC5869</a>]</span>, via the <code>info</code> input to derive the <code>key</code> parameter. The <code>ad</code> parameter can then be left empty. Note that the <code>salt</code> input <span class="bcp14">MUST NOT</span> be used since large salts get hashed, which affects commitment. Furthermore, this requires values concatenated to form the <code>info</code> input to be unambiguously encoded, like by appending their lengths.<a href="#section-10.1.2-4" class="pilcrow">¶</a></p>
 </section>
 </div>

proofreading/draft-irtf-cfrg-aegis-aead.txt

@@ -1877,10 +1877,9 @@ return tag
    Protocols mandating a fully committing scheme without that
    restriction can provide the associated data as input to a
    cryptographic hash function and use the output as the ad parameter of
-   the Encrypt and Decrypt functions.  For AEGIS-128L and AEGIS-128X,
-   the selected hash function must ensure a minimum of 128-bit collision
-   and preimage resistance.  An instance of such a function is SHA-256
-   [RFC6234].
+   the Encrypt and Decrypt functions.  The selected hash function must
+   ensure a minimum of 128-bit collision and preimage resistance.  An
+   instance of such a function is SHA-256 [RFC6234].
 
    Alternatively, the associated data can be fed into a collision-
    resistant KDF, such as HKDF [RFC5869], via the info input to derive