Script updating gh-pages from 8a59ede. [ci skip]

draft-lucas-bkdf.html

@@ -1361,7 +1361,7 @@ <h2 id="name-conventions-and-definitions">
           <p id="section-2-6.6.1"><code>MIN_PERSONALIZATION</code>: the minimum personalization length, which is 2 bytes.<a href="#section-2-6.6.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-2-6.7">
-          <p id="section-2-6.7.1"><code>MAX_PERSONALIZATION</code>: the maximum personalization length, which is 32 bytes.<a href="#section-2-6.7.1" class="pilcrow">¶</a></p>
+          <p id="section-2-6.7.1"><code>MAX_PERSONALIZATION</code>: the maximum personalization length, which is 4294967295 bytes.<a href="#section-2-6.7.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="section-2-6.8">
           <p id="section-2-6.8.1"><code>MIN_SPACECOST</code>: the minimum space cost, which is 0 as an integer.<a href="#section-2-6.8.1" class="pilcrow">¶</a></p>
@@ -1732,7 +1732,7 @@ <h3 id="name-usage-guidelines">
 <p id="section-9.1-4">In all cases, it is <span class="bcp14">RECOMMENDED</span> to use a 128-bit <code>salt</code>. However, a 64-bit <code>salt</code> <span class="bcp14">MAY</span> be used if there are storage constraints. Regardless, the <code>salt</code> length <span class="bcp14">SHOULD NOT</span> vary in your protocol/application.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
 <p id="section-9.1-5">The salt <span class="bcp14">MUST</span> be unique each time you call the function unless verifying a password hash or deriving the same key. It <span class="bcp14">SHOULD</span> be randomly generated using a cryptographically secure pseudorandom number generator (CSPRNG). However, it <span class="bcp14">MAY</span> be deterministic and predictable if random generation is not possible.<a href="#section-9.1-5" class="pilcrow">¶</a></p>
 <p id="section-9.1-6">The salt <span class="bcp14">SHOULD</span> be considered a non-secret value. It <span class="bcp14">SHOULD</span> be stored alongside the password hash for password hashing (see <a href="#encoding-password-hashes" class="auto internal xref">Section 8</a>) or in something like a file header for key derivation. If you have a secret key, the password hash <span class="bcp14">SHOULD</span> be encrypted or the <code>pepper</code> parameter <span class="bcp14">SHOULD</span> be used, as described below.<a href="#section-9.1-6" class="pilcrow">¶</a></p>
-<p id="section-9.1-7">The <code>personalization</code> parameter <span class="bcp14">MUST</span> be a hardcoded, globally unique, and application-specific string for your entire database/application. A good default format is <code>UTF8("[application name] [commit timestamp] [purpose]")</code>, where the timestamp is the Unix epoch and the purpose is <code>"kdf"</code> or <code>"ph"</code> to distinguish between key derivation and password hashing. This binds the buffer, memory access pattern, and output to your application even if multiple applications have the same name, which helps hinder attackers. It <span class="bcp14">MUST NOT</span> be unique per user in the database/application; that is the purpose of the salt.<a href="#section-9.1-7" class="pilcrow">¶</a></p>
+<p id="section-9.1-7">The <code>personalization</code> parameter <span class="bcp14">MUST</span> be a hardcoded, globally unique, and application-specific string for your entire database/application. A good default format is <code>UTF8("[application] [commit timestamp] [purpose]")</code>. For instance, <code>"example.com 2024-11-03 14:36:48 password hashing"</code>. This binds the buffer, memory access pattern, and output to your application even if multiple applications have the same name, which helps hinder attackers. It <span class="bcp14">MUST NOT</span> be unique per user in the database/application; that is the purpose of the salt.<a href="#section-9.1-7" class="pilcrow">¶</a></p>
 <p id="section-9.1-8">The <code>spaceCost</code>, <code>timeCost</code>, and <code>parallelism</code> parameters <span class="bcp14">MUST</span> be carefully chosen to avoid denial-of-service and user frustration whilst ensuring adequate protection against password cracking. See <a href="#choosing-the-cost-parameters" class="auto internal xref">Section 7</a> for more information about choosing these parameters.<a href="#section-9.1-8" class="pilcrow">¶</a></p>
 <p id="section-9.1-9">Avoid using hardcoded <code>spaceCost</code>/<code>timeCost</code>/<code>parallelism</code> parameters when performing password hashing; these <span class="bcp14">SHOULD</span> be stored as part of the password hash, as described in <a href="#encoding-password-hashes" class="auto internal xref">Section 8</a>. With key derivation, hardcoded parameters are acceptable if protocol versioning is used.<a href="#section-9.1-9" class="pilcrow">¶</a></p>
 <p id="section-9.1-10">For password hashing, it is <span class="bcp14">RECOMMENDED</span> to use a <code>length</code> of 128 or 256 bits. For key derivation, it is <span class="bcp14">RECOMMENDED</span> to use a <code>length</code> of at least 128 bits.<a href="#section-9.1-10" class="pilcrow">¶</a></p>

draft-lucas-bkdf.txt

@@ -206,7 +206,7 @@ Table of Contents
       2 bytes.
 
    *  MAX_PERSONALIZATION: the maximum personalization length, which is
-      32 bytes.
+      4294967295 bytes.
 
    *  MIN_SPACECOST: the minimum space cost, which is 0 as an integer.
 
@@ -595,11 +595,10 @@ $bkdf-sha256$v=1$m=32,t=3,p=1$ZXhhbXBsZXNhbHQ$cWBD3/d3tEqnuI3LqxLAeKvs+snSicW1GV
 
    The personalization parameter MUST be a hardcoded, globally unique,
    and application-specific string for your entire database/application.
-   A good default format is UTF8("[application name] [commit timestamp]
-   [purpose]"), where the timestamp is the Unix epoch and the purpose is
-   "kdf" or "ph" to distinguish between key derivation and password
-   hashing.  This binds the buffer, memory access pattern, and output to
-   your application even if multiple applications have the same name,
+   A good default format is UTF8("[application] [commit timestamp]
+   [purpose]").  For instance, "example.com 2024-11-03 14:36:48 password
+   hashing".  This binds the buffer, memory access pattern, and output
+   to your application even if multiple applications have the same name,
    which helps hinder attackers.  It MUST NOT be unique per user in the
    database/application; that is the purpose of the salt.