Script updating gh-pages from aea8a68. [ci skip]

draft-irtf-cfrg-det-sigs-with-noise.html

@@ -1219,7 +1219,7 @@ <h2 id="name-introduction">
 <p id="section-1-5">Government agencies are clearly concerned about these attacks. In <span>[<a href="#Notice-186-5" class="cite xref">Notice-186-5</a>]</span> and <span>[<a href="#FIPS-186-5" class="cite xref">FIPS-186-5</a>]</span>, NIST warns about side-channel and fault injection attacks, but states that deterministic ECDSA may be desirable for devices that lack good randomness. The quantum-resistant ML-DSA <span>[<a href="#FIPS-204" class="cite xref">FIPS-204</a>]</span> standardized by NIST uses hedged signing by default. BSI has published <span>[<a href="#BSI" class="cite xref">BSI</a>]</span> and researchers from BSI have co-authored two research papers <span>[<a href="#ABFJLM17" class="cite xref">ABFJLM17</a>]</span> <span>[<a href="#PSSLR17" class="cite xref">PSSLR17</a>]</span> on attacks on deterministic signatures. For many industries it is important to be compliant with both RFCs and government publications, alignment between IETF, NIST, and BSI recommendations would be preferable.<a href="#section-1-5" class="pilcrow">¶</a></p>
 <p id="section-1-6">Note that deriving per-message secret number deterministically, is also insecure in a multi-party signature setting <span>[<a href="#RFC9591" class="cite xref">RFC9591</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
 <p id="section-1-7">One countermeasure to entropy failures, side-channel attacks, and fault injection attacks recommended by <span>[<a href="#Langley13" class="cite xref">Langley13</a>]</span> <span>[<a href="#RP17" class="cite xref">RP17</a>]</span> <span>[<a href="#ABFJLM17" class="cite xref">ABFJLM17</a>]</span> <span>[<a href="#SBBDS17" class="cite xref">SBBDS17</a>]</span> <span>[<a href="#PSSLR17" class="cite xref">PSSLR17</a>]</span> <span>[<a href="#SB18" class="cite xref">SB18</a>]</span> <span>[<a href="#AOTZ19" class="cite xref">AOTZ19</a>]</span> <span>[<a href="#FG19" class="cite xref">FG19</a>]</span> and implemented in <span>[<a href="#OpenSSL13a" class="cite xref">OpenSSL13a</a>]</span> <span>[<a href="#OpenSSL13b" class="cite xref">OpenSSL13b</a>]</span> <span>[<a href="#XEdDSA" class="cite xref">XEdDSA</a>]</span> <span>[<a href="#libSodium" class="cite xref">libSodium</a>]</span> <span>[<a href="#libHydrogen" class="cite xref">libHydrogen</a>]</span> is to generate the per-message secret number from a random string, a secret key, and the message. This combines the security benefits of fully randomized per-message secret numbers with the security benefits of fully deterministic secret numbers.  Such a hedged construction protects against key compromise due to weak random number generation, but still effectively prevents many side-channel and fault injection attacks that exploit determinism. Hedged constructions require minor changes to the implementation and does not increase the number of elliptic curve point multiplications and is therefore suitable for constrained IoT. Adding randomness to EdDSA is not compliant with <span>[<a href="#RFC8032" class="cite xref">RFC8032</a>]</span>. <span>[<a href="#Kampanakis16" class="cite xref">Kampanakis16</a>]</span> describes an alternative <span>[<a href="#FIPS-186-5" class="cite xref">FIPS-186-5</a>]</span> compliant approach where message specific pseudo-random information is used as an additional input to the random number generation to create per-message secret number. <span>[<a href="#Bernstein14" class="cite xref">Bernstein14</a>]</span> states that generation of the per-message secret number from a subset of a random string, a secret key, the message, and a message counter is common in DSA/ECDSA implementations.<a href="#section-1-7" class="pilcrow">¶</a></p>
-<p id="section-1-8">This document updates <span>[<a href="#RFC6979" class="cite xref">RFC6979</a>]</span> and <span>[<a href="#RFC8032" class="cite xref">RFC8032</a>]</span> to recommend hedged constructions in deployments where side-channel and fault injection attacks are a concern. The updates are invisible to the validator of the signature. Produced signatures remain fully compatible with unmodified ECDSA and EdDSA verifiers and existing key pairs can continue to be used. As the precise use of the noise is specified, test vectors can still be produced, see <a href="#test" class="auto internal xref">Section 6</a>, and implementations can be tested against them.<a href="#section-1-8" class="pilcrow">¶</a></p>
+<p id="section-1-8">This document updates <span>[<a href="#RFC6979" class="cite xref">RFC6979</a>]</span> and <span>[<a href="#RFC8032" class="cite xref">RFC8032</a>]</span> to recommend hedged constructions in deployments where side-channel and fault injection attacks are a concern. The updates are invisible to the validator of the signature. Produced signatures remain fully compatible with unmodified ECDSA and EdDSA verifiers and existing key pairs can continue to be used. As the precise use of random bytes is specified, test vectors can still be produced, see <a href="#test" class="auto internal xref">Section 6</a>, and implementations can be tested against them.<a href="#section-1-8" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="conventions-used-in-this-document">

draft-irtf-cfrg-det-sigs-with-noise.txt

@@ -205,8 +205,8 @@ Table of Contents
    attacks are a concern.  The updates are invisible to the validator of
    the signature.  Produced signatures remain fully compatible with
    unmodified ECDSA and EdDSA verifiers and existing key pairs can
-   continue to be used.  As the precise use of the noise is specified,
-   test vectors can still be produced, see Section 6, and
+   continue to be used.  As the precise use of random bytes is
+   specified, test vectors can still be produced, see Section 6, and
    implementations can be tested against them.
 
 2.  Conventions Used in This Document