Updates per review comments

docs/algorithms/sig_stfl/lms.md

@@ -1,12 +1,13 @@
 # LMS
 
 - **Algorithm type**: Digital signature scheme.
-- **Main cryptographic assumption**: stateful hash-based signatures.
+- **Main cryptographic assumption**: hash function second-preimage resistance.
 - **Principal submitters**: Scott Fluhrer.
+- **Auxiliary submitters**: C Martin, Maurice Hieronymus.
 - **Authors' website**: https://www.rfc-editor.org/info/rfc8554
 - **Specification version**: None.
 - **Primary Source**<a name="primary-source"></a>:
-  - **Source**: None
+  - **Source**: https://github.com/cisco/hash-sigs
   - **Implementation license (SPDX-Identifier)**: MIT
 
 

docs/algorithms/sig_stfl/lms.yml

@@ -3,14 +3,16 @@ type: stateful signature
 principal-submitters:
 - Scott Fluhrer
 auxiliary-submitters:
+- C Martin
+- Maurice Hieronymus
 
-crypto-assumption: stateful hash-based signatures
+crypto-assumption: hash function second-preimage resistance
 website: https://www.rfc-editor.org/info/rfc8554
 nist-round: 
 spec-version: 
 spdx-license-identifier: 
 primary-upstream:
-  source: 
+  source: https://github.com/cisco/hash-sigs
   spdx-license-identifier: MIT
   upstream-ancestors:
 parameter-sets:

docs/algorithms/sig_stfl/sig_stfl.md

@@ -1,27 +1,29 @@
 
-Stateful Hash Based Signature
+# **Stateful Hash Based Signatures**
 
-The security of hash based signatures (HBS) is based on the underlaying hash functions on which they are built.
+The security of hash based signatures (HBS) is based on the underlying hash functions on which they are built.
 NIST recommendation is that they are suitable for near term use to mitigate against attacks mounted by quantum computers.
 While not a general purpose solution, they are useful means to authenticate boot or firmware images.
 
+<ins>**General**</ins>
+
 This package provides full support for a variety of variants for XMSS and LMS. 
 Key generation, signature generation, and signature verification. 
 Security of HBS also depends on the management of the state of the secret key. Secret keys can only used once to generate a signature.
 Multiple signing with same key can reveal that key to an attacker.
-Because of this, NIST recommends that key and signature aeration be done in hardware security modules.
-Having said that, this library is fully functional for research purposes. Storage and management of the secret keys are left update applications using this feature.
-Secret key storage is easily done when by supplying a callback function to the library.
+Because of this, NIST recommends that key and signature generation be done in hardware security modules.
+Having said that, this library is fully functional for research purposes. Secret keys are incremented after each sign operation.
+However, secure storage and lifecycle management of the secret keys are left to applications using this feature.
+Secret key storage is easily done by supplying a callback function to the library. This callback is invoked to store the secret key.
+
 
+<ins>**Key State Management**</ins>
 
-Key State Management:
 Application writers have to supply callback functions to store and update secret keys.
 After a sign operation the secret key index is advanced and stored. This ensures one-time use of the key.
-Signing operations will fail without this callback set because the private key cannot be advance (to prevent reuse).
+Signing operations will fail without this callback set because the private key cannot be advanced (to prevent reuse).
 
-Stateful keys can generate a finite number signatures. A counter tracks the limit when the key is created and is decremented after each signature is generated.
-When the counter is down to 0, signature generations fails. Applications can query the remaining count via an API.
+Stateful keys can generate a finite number of signatures. A counter tracks the limit when the key is created and is decremented after each signature is generated.
+When the counter is down to 0, signature generation fails. Applications can query the remaining count via an API.
 
-Multithreaded application will need to set lock and unlock callbacks for the library to use. This is needed to ensure that only one thread can access a given secret key
-for signing and update operations.
 

docs/algorithms/sig_stfl/xmss.md

@@ -1,7 +1,7 @@
 # XMSS
 
 - **Algorithm type**: Digital signature scheme.
-- **Main cryptographic assumption**: stateful hash-based signatures.
+- **Main cryptographic assumption**: hash function second-preimage resistance.
 - **Principal submitters**: Joost Rijneveld, A. Huelsing, David Cooper, Bas Westerbaan.
 - **Authors' website**: https://www.rfc-editor.org/info/rfc8391
 - **Specification version**: None.

docs/algorithms/sig_stfl/xmss.yml

@@ -7,7 +7,7 @@ principal-submitters:
 - Bas Westerbaan
 auxiliary-submitters:
 
-crypto-assumption: stateful hash-based signatures
+crypto-assumption: hash function second-preimage resistance
 website: https://www.rfc-editor.org/info/rfc8391
 nist-round: 
 spec-version: