From 3dd04d9fed42a80a0f92daf85a12c0cf46f43201 Mon Sep 17 00:00:00 2001 From: Fabian Albert Date: Wed, 9 Oct 2024 14:19:06 +0200 Subject: [PATCH 1/2] Cryptodoc: Sphincs+ -> SLH-DSA --- docs/cryptodoc/src/05_00_pubkey.rst | 2 +- docs/cryptodoc/src/05_07_slh_dsa.rst | 439 ++++++++++++++++++++++++ docs/cryptodoc/src/05_07_spx.rst | 381 -------------------- docs/cryptodoc/src/05_10_frodokem.rst | 2 +- docs/cryptodoc/src/90_bibliographie.rst | 9 +- 5 files changed, 445 insertions(+), 388 deletions(-) create mode 100644 docs/cryptodoc/src/05_07_slh_dsa.rst delete mode 100644 docs/cryptodoc/src/05_07_spx.rst diff --git a/docs/cryptodoc/src/05_00_pubkey.rst b/docs/cryptodoc/src/05_00_pubkey.rst index c7343a4a..39c7b89d 100644 --- a/docs/cryptodoc/src/05_00_pubkey.rst +++ b/docs/cryptodoc/src/05_00_pubkey.rst @@ -19,7 +19,7 @@ encapsulation and decapsulation or the key exchange mechanism. 05_04_rsa 05_05_xmss 05_06_hss_lms - 05_07_spx + 05_07_slh_dsa 05_08_dilithium 05_09_kyber 05_10_frodokem diff --git a/docs/cryptodoc/src/05_07_slh_dsa.rst b/docs/cryptodoc/src/05_07_slh_dsa.rst new file mode 100644 index 00000000..7f36e5f9 --- /dev/null +++ b/docs/cryptodoc/src/05_07_slh_dsa.rst @@ -0,0 +1,439 @@ +.. _pubkey/slh_dsa: + +SLH-DSA +======= + +Botan's implementation of the Stateless Hash-Based Digital Signature Standard +(SLH-DSA) is found in +:srcref:`src/lib/pubkey/sphincsplus/` and follows [FIPS-205]_. + + +Algorithm Internals +------------------- + +SLH-DSA is composed of Forest Of Random Subsets (FORS) few-time signatures +and Winternitz One-Time Signatures (WOTS\ :sup:`+`), which are used within +hypertree signatures (a variant of XMSS\ :sup:`MT`). In short, messages +are signed via FORS. The FORS public key is signed via XMSS with WOTS\ :sup:`+` +as part of the hypertree. The root of the top-level tree in the hypertree +structure then essentially represents the SLH-DSA root. +Table :ref:`SLH-DSA logical components ` +provides an overview of these components and their Botan implementations. The +:ref:`SLH-DSA ` component, by making use of +the other components, provides the overall signature generation and verification +operations. + +.. _signatures/slh_dsa/table: + +.. table:: SLH-DSA logical components and file locations. + :widths: 15 25 45 15 + + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | Component | File | Purpose | Section in [FIPS-205]_ | + +============================================================+===========================================================================+============================================+==============================+ + | :ref:`Types ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_types.h` | Strong types | | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`Address ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_address.h` | Address representation and manipulation | 4.2, 4.3 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`Parameters ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_parameters.h` | Parameter set instantiations | 11 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`Hashes ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_hash.h` | All hash functions | 11.1, 11.2 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`Treehash ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_treehash.h` | Merkle tree hashing for FORS and XMSS | 6.1, 8.2 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`FORS ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_fors.h` | FORS signature | 8 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`WOTS+ ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_wots.h` | WOTS\ :sup:`+` signature | 5 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`XMSS ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_xmss.h` | XMSS signature | 6 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`Hypertree ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_hypertree.h` | Hypertree signature | 7 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`SLH-DSA Internal ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.h` | SLH-DSA internal functions | 9 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + | :ref:`SLH-DSA ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.h` | SLH-DSA signature | 10 | + +------------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ + +.. _signatures/slh_dsa/types: + +Types +^^^^^ + +In Botan's SLH-DSA implementation, the concept of strong types is +used. A strong type can be used to create unique C++ types for data that is +semantically different, but operates on the same internal data structures. +SLH-DSA mainly operates on byte vectors in various contexts (e.g., +XMSS tree nodes, WOTS\ :sup:`+` chain node, public/secret seeds, etc.), as well +as combined contexts like a WOTS\ :sup:`+` signature composed of multiple +WOTS\ :sup:`+` nodes. In SLH-DSA, every context is represented by a +separate strong type. The usage of strong types creates a much clearer and more +self-documenting interface, which also guarantees that no data is misused in the +wrong context. More details on all defined strong types and their interpretation +are documented in the respective header file. + +.. _signatures/slh_dsa/address: + +Address +^^^^^^^ + +Botan's SLH-DSA addresses wrap the address specification of [FIPS-205]_ +into a class ``Sphincs_Address``. Methods for getting, copying, and setting +specified fields of an address are provided as well as constants. All constants, +fields, and representations are set as specified in Section 4.2 of [FIPS-205]_. + +.. _signatures/slh_dsa/parameters: + +Parameters +^^^^^^^^^^ + +The class ``Sphincs_Parameters`` represents all parameters of SLH-DSA. +It checks whether provided parameters are valid and can be created from a given +``Sphincs_Parameter_Set``, representing each set of Table :ref:`Supported +SLH-DSA parameter sets `. +Parameters that can be computed directly from the parameter set are calculated +in the constructor and stored as members instead of being calculated on demand. + +.. _signatures/slh_dsa/hashes: + +Hashes +^^^^^^ + +Botan implements the SHA2 and SHAKE versions of SLH-DSA as different +modules. All hash functions used within SLH-DSA are represented by the +class ``Sphincs_Hash_Functions``, which can be instantiated from given +parameters and the public seed ``pub_seed``. The public seed is given at +creation because all calls to the ``T`` and ``PRF`` functions use the public +seed as input. All underlying hash function members are instantiated in the +constructor according to Sections 11.1 and 11.2 of [FIPS-205]_. The specific +child classes for the SHA2 and SHAKE modules are given in +:srcref:`[src/lib/pubkey/sphincsplus]/sphincsplus_sha2/sp_hash_sha2.h` and +:srcref:`[src/lib/pubkey/sphincsplus]/sphincsplus_shake/sp_hash_shake.h`, +respectively. + +The specification defines three tweaked hash functions that share similarities. +:math:`\mathbf{T_\ell}` is a tweaked hash function with a message input length +of :math:`\ell n` bytes. :math:`\mathbf{F}` and :math:`\mathbf{H}` are simply +defined as :math:`\mathbf{T_1}` and :math:`\mathbf{T_2}`. For clarity and +convenience, Botan omits the additional definitions by only implementing and +calling the method ``T``, which allows for arbitrary input lengths. + +.. _signatures/slh_dsa/treehash: + +Merkle Tree Computation +^^^^^^^^^^^^^^^^^^^^^^^ + +Botan generalizes the Merkle tree creation Algorithms 9 +(:math:`\mathtt{xmss\_node}`) and 15 (:math:`\mathtt{fors\_node}`) of +[FIPS-205]_ using a single function +``treehash``. This +approach minimizes duplicate code while being in accordance with the +specification. However, in contrast to the algorithms specified in [FIPS-205]_ +Botan uses an iterative approach instead of a recursive one. +The only difference between the Merkle tree root node computation +of FORS and XMSS is the creation of leaf nodes. Therefore, ``treehash`` +takes a callback function for the leaf creation logic as an additional argument. +This callback function also handles the hash function addresses according to its +purpose. The used callback functions are ``xmss_gen_leaf`` (for XMSS; see +:ref:`SLH-DSA XMSS `) and ``fors_gen_leaf`` +(for FORS; see :ref:`SLH-DSA FORS `). + +Another generalization of the specification that is also adapted from the +reference implementation is the integration of authentication path computations +into the ``treehash`` function. To achieve this, the function also takes the +index of the leaf for which to compute the authentication path. When building up +the Merkle tree, the function adds currently computed nodes to the +authentication path if they are contained in it. Alternatively, if only the root +node is requested (i.e. when computing :math:`\mathbf{PK}.\mathsf{root}`), the +leaf index can be set to an empty value, in which case no authentication path is +computed. + +Furthermore, the same generalization ideas are applied to the root computation +from a signature, i.e., Algorithms 11 (:math:`\mathtt{xmss\_pkFromSig}`) and 17 +(:math:`\mathtt{fors\_pkFromSig}`) of [FIPS-205]_. Botan's function +``compute_root`` computes the root of a Merkle tree using a leaf and its +authentication path. For both XMSS and FORS, the logic is the same, with the +only condition being that correctly preconfigured hash function addresses must +be passed to the function. + +.. _signatures/slh_dsa/fors: + +FORS +^^^^ + +As recommended in [FIPS-205]_, Section 3.2, the FORS few-time signature scheme +is not part of the public API. Botan only implements the FORS methods relevant +to SLH-DSA. This is :math:`\mathtt{fors\_sign}` of [FIPS-205]_ +(Algorithm 16) and :math:`\mathtt{fors\_pkFromSig}` of [FIPS-205]_ +(Algorithm 17). More concretely, +both methods are combined into Botan's ``fors_sign_and_pkgen``, which computes +both the signature and the FORS public key. The authentication path computation +therein and :math:`\mathtt{fors\_node}` of [FIPS-205]_ (Algorithm 15) are +implemented in the generalized ``treehash`` (see +:ref:`Merkle Tree Computation `), whereby +:math:`\mathtt{fors\_skGen}` of [FIPS-205]_ (Algorithm 14) is implemented +within the callback function ``fors_gen_leaf`` supplied to ``treehash``. +Similarly, the computation of the root and authentication path in the +implementation of :math:`\mathtt{fors\_pkFromSig}` utilizes the generalized +``compute_root`` method (see :ref:`Merkle Tree Computation +`), resulting in the method +``fors_public_key_from_signature``. + +.. _signatures/slh_dsa/wotsplus: + +WOTS\ :sup:`+` +^^^^^^^^^^^^^^ + +The implementation of WOTS\ :sup:`+` in the context of SLH-DSA is +based on [FIPS-205]_ with some adaptions of the SLH-DSA reference +implementations. In the same manner as FORS, it utilizes a generalization that +fuses the WOTS\ :sup:`+` public key and signature creation, i.e., the algorithms +:math:`\mathtt{wots\_pkGen}` (Algorithm 6) and +:math:`\mathtt{wots\_sign}` (Algorithm 7) of [FIPS-205]_, into +one method. When building up an XMSS tree, all leaf nodes must be computed, +which are the hashed WOTS\ :sup:`+` public keys. Only one leaf is used to sign +the underlying root. The WOTS\ :sup:`+` signature consists of values that are +computed in every public key creation; these values are elements of the +WOTS\ :sup:`+` hash chains. This observation leads to Botan's +``wots_sign_and_pkgen`` method that combines both logics, i.e., the entire +WOTS\ :sup:`+` chains are computed for the public key while the WOTS\ :sup:`+` +signature values are extracted at the same time if the current leaf is the +signing one. + +.. _signatures/slh_dsa/XMSS: + +XMSS +^^^^ + +**Remark:** Botan's implementation of the XMSS logic of SLH-DSA is +specifically tailored to SLH-DSA and separate from Botan's standalone +XMSS implementation (see :ref:`XMSS Key Generation ` +and :ref:`XMSS Signatures `). This is due to the differences in +their tweaked hash applications, including a different hash function addressing. +Also, it is in accordance with the implementation considerations given by +[FIPS-205]_, Section 3.2. + +To create a single XMSS signature, the building blocks of the preceding sections +are composed into the function ``xmss_sign_and_pkgen``. The generic ``treehash`` +function (see :ref:`Merkle Tree Computation `) +is the +core logic of XMSS. For generating leaves, it uses the provided callback +function ``xmss_gen_leaf``, which calls ``wots_sign_and_pkgen`` (see :ref:`WOTS+ +`) since XMSS leaves are hashed WOTS\ :sup:`+` +public keys. This callback function contains all necessary parameters including +the index of the leaf to sign, the message to sign (already divided into +:math:`lg_w` sized chunks), and the required hash function addresses. + +While ``xmss_gen_leaf`` creates and stores the neccessary WOTS\ :sup:`+` +signature, ``treehash`` adds the authentication path to the XMSS signature when +building up the XMSS Merkle tree. Therefore, ``xmss_sign_and_pkgen`` creates its +XMSS root node and signature for a given leaf index and message and covers both +Algorithm 10 (:math:`\mathtt{xmss\_sign}`) and Algorithm 11 +(:math:`\mathtt{xmss\_pkFromSig}`) of [FIPS-205]_. + +For public key creation, i.e., the creation of :math:`\mathbf{PK}.\mathsf{root}`, +the function ``xmss_gen_root`` is used. It uses ``xmss_sign_and_pkgen`` with an +empty leaf index to only create the root node (see :ref:`Merkle Tree Computation +` invoked by ``xmss_sign_and_pkgen``). +Algorithm 11 (:math:`\mathtt{xmss\_pkFromSig}`), i.e., the reconstruction of an +XMSS root node using an XMSS signature, is achieved by calling the function +``compute_root`` (see :ref:`Merkle Tree Computation `). + +.. _signatures/slh_dsa/hypertree: + +Hypertree +^^^^^^^^^ + +The XMSS hypertree signature creation according to Algorithm 12 of [FIPS-205]_ +(:math:`\mathtt{ht\_sign}`) is implemented by the method ``ht_sign``. Beginning +at the hypertree's leaves, the hypertree is built up using subsecutive calls of +``xmss_sign_and_pkgen`` (see :ref:`XMSS `) +with each call signing the root of the previous XMSS tree or the hypertree +signature's message for the first call. As described in :ref:`XMSS +`, this also creates the XMSS root node used in the +next iteration. The leaf indices selected to sign the hypertree signature's +message or roots are computed according to the specification. + +The hypertree verification, Algorithm 13 of [FIPS-205]_ +(:math:`\mathtt{ht\_verify}`), is performed in ``ht_verify``. By calling +``compute_root``, it reconstructs the roots from bottom to top using the +concatenated XMSS signatures. For verification, the final root, which is the +root of the hypertree, is compared with :math:`\mathbf{PK}.\mathsf{root}`. + +.. _signatures/slh_dsa/internal: + +SLH-DSA Internal Functions +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The functions :math:`\mathtt{slh\_sign\_internal}` (Algorithm 19) and +:math:`\mathtt{slh\_verify\_internal}` (Algorithm 20) are named in Botan as +specified by [FIPS-205]_. As defined by the specification, these algorithms +utilize the hashes, FORS, and hypertree interfaces to create and verify SLH-DSA +signatures. The function :math:`\mathtt{slh\_keygen\_internal}` (Algorithm 18) +is implemented by the SLH-DSA private key's constructor, which also implements +the logic specified in :math:`\mathtt{slh\_keygen}`. + +.. _signatures/slh_dsa/slh_dsa: + +SLH-DSA +^^^^^^^ + +All the above components are combined to constitute Botan's SLH-DSA +component used for creating or verifying SLH-DSA signatures. + +.. _pubkey_key_generation/slh_dsa: + +Key Generation +-------------- + +Botan supports the parameter sets provided in Table 2 of [FIPS-205]_ for the +SHA2 and SHAKE instantiations of hash functions. +An overview is provided in Table +:ref:`Supported SLH-DSA parameter sets `. + +.. _pubkey_key_generation/slh_dsa/params_table: + +.. table:: Supported SLH-DSA parameter sets (see Table 2 of [FIPS-205]_). can either be ``SHA2`` or ``SHAKE``. + + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | Parameter Set | :math:`n` | :math:`h` | :math:`d` | :math:`h'` | :math:`a` | :math:`k` | :math:`lg_w` | :math:`m` | + +=========================+===========+===========+===========+============+===========+===========+==============+===========+ + | ``SLH-DSA--128s`` | 16 | 63 | 7 | 9 | 12 | 14 | 4 | 30 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | ``SLH-DSA--128f`` | 16 | 66 | 22 | 3 | 6 | 33 | 4 | 34 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | ``SLH-DSA--192s`` | 24 | 63 | 7 | 9 | 14 | 17 | 4 | 39 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | ``SLH-DSA--192f`` | 24 | 66 | 22 | 3 | 8 | 33 | 4 | 42 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | ``SLH-DSA--256s`` | 32 | 64 | 8 | 8 | 14 | 22 | 4 | 47 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + | ``SLH-DSA--256f`` | 32 | 68 | 17 | 4 | 9 | 35 | 4 | 49 | + +-------------------------+-----------+-----------+-----------+------------+-----------+-----------+--------------+-----------+ + +SLH-DSA key generation follows Sections 9.1 and 10.1 of [FIPS-205]_ and is +implemented in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:306|SphincsPlus_PrivateKey` +within the ``SphincsPlus_PrivateKey`` constructor. It works as follows: + +.. admonition:: SLH-DSA Key Generation + + **Input:** + + - ``rng``: random number generator + - ``params``: SLH-DSA parameters + + **Output:** + + - ``SK``, ``PK``: private and public key + + **Steps:** + + 1. Generate new values ``sk_seed``, ``sk_prf``, and ``pub_seed`` using ``rng``. + 2. ``root = xmss_gen_root(sk_seed)`` + (see :ref:`XMSS `). + 3. | ``SK = {sk_seed, sk_prf, pub_seed, root}`` + | ``PK = {pub_seed, root}`` + + **Notes:** + + - Step 1 corresponds to Algorithm 21, and Steps 2-3 correspond to Algorithm 18 of [FIPS-205]_. All are performed in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:306|SphincsPlus_PrivateKey`. + - The creation of a public key is conducted using the + ``public_key`` method of the private key. + - The addresses are set according to Algorithm 18 of [FIPS-205]_. + +SPHINCS\ :sup:`+` +^^^^^^^^^^^^^^^^^ + +Botan supports the SPHINCS\ :sup:`+` Round 3.1 NIST submission [SPX-R3]_. The +SPHINCS\ :sup:`+` instances are activated using the ``sphincsplus_sha2`` and +``sphincsplus_shake`` modules, enabling their selection for key creation. +As with the SLH-DSA instances, they are provided to the constructors of the +SLH-DSA keys. +These instances are maintained solely for version compatibility. It is strongly +recommended to use the SLH-DSA instances instead. + +Signature Creation +------------------ + +**Remark:** Signature creation with non-empty contexts is currently not +supported in Botan. Support for the pre-hash variant of SLH-DSA is also not yet +available. + +An SLH-DSA signature is created in the following manner, following +Algorithm 22 of [FIPS-205]_ (see :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:355|sign`): + +.. admonition:: SLH-DSA Signature Creation + + **Input:** + + - ``rng``: random number generator + - ``m``: message to be signed + - ``SK = {sk_seed, sk_prf, pub_seed, root}``: SLH-DSA secret key + + **Output:** + + - ``sig``: SLH-DSA signature + + **Steps:** + + 1. Generate new value ``addrnd`` using ``rng``. For the deterministic variant, set ``addrnd`` to ``NULL``. + 2. ``internal_msg = 0x00 || 0x00 || m`` (contexts are currently not supported). + 3. Create signature ``sig`` using ``slh_sign_internal`` + + 1. ``opt_rand = SK.pub_seed`` if ``addrnd == NULL``. Otherwise, set ``opt_rand`` to ``addrnd``. + 2. ``msg_random_s = PRF_msg(m, SK.prf, opt_rand)`` and set ``sig = msg_random_s``. + 3. ``(mhash, tree_idx, leaf_idx) = H_msg(msg_random_s, SK.root, m)``. + 4. Set tree address of ``fors_addr`` to ``tree_idx``, its type to ``ForsTree``, and its keypair address to ``leaf_idx``. + 5. ``(fors_sig, fors_root) = fors_sign_and_pkgen(mhash, SK.sk_seed, fors_addr)`` and append ``fors_sig`` to ``sig``. + 6. ``ht_sig = ht_sign(fors_root, SK.sk_seed, tree_idx, leaf_idx)`` and append ``ht_sig`` to ``sig``. + + + **Notes:** + + - Steps 1-3 correspond to Algorithm 22 of [FIPS-205]_ and are performed in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:355|sign`. + - Steps 4-9 correspond to Algorithm 19 of [FIPS-205]_ and are performed in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:375|slh_sign_internal`. + - Steps 3.3, 3.5, 3.6: ``SK.pub_seed`` is omitted as an input because the hash functions are already instantiated with a corresponding member variable. + - ``SK`` is passed to ``slh_sign_internal`` via member variables. + +Signature Validation +-------------------- + +**Remark:** Signature verification with non-empty contexts is currently not +supported in Botan. Support for the pre-hash variant of SLH-DSA is also not yet +available. + +An SLH-DSA signature is verified in the following manner, following +Algorithm 24 of [FIPS-205]_ (see :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:203|is_valid_signature`): + +.. admonition:: SLH-DSA Signature Validation + + **Input:** + + - ``m``: message to be validated + - ``sig``: signature to be validated + - ``PK``: SLH-DSA public key, ``PK = {pub_seed, root}`` + + **Output:** + + - ``true``, if the signature for message ``m`` is valid. ``false`` otherwise + + **Steps:** + + 1. ``internal_msg = 0x00 || 0x00 || m`` (contexts are currently not supported) + 2. The signature is valid iff ``slh_verify_internal(internal_msg, sig, PK) == true`` + + 1. Return ``false`` if the length of ``sig`` is invalid. + 2. Take the first ``n`` bytes of ``sig`` as value ``msg_random_s``. + 3. ``(mhash, tree_idx, leaf_idx) = H_msg(msg_random_s, PK.root, m)``. + 4. Set tree address of ``fors_addr`` to tree_idx, its type to ``ForsTree``, and its keypair address to ``leaf_idx``. + 5. Take the FORS signature bytes of ``sig`` as value ``fors_sig_s``. + 6. ``fors_root = fors_public_key_from_signature(mhash, fors_sig_s, fors_addr)``. + 7. Take the hypertree signature bytes of ``sig`` as value ``ht_sig_s``. + 8. The signature is valid iff ``ht_verify(fors_root, ht_sig_s, PK.root, tree_idx, leaf_idx) == true``. + + **Notes:** + + - Steps 1-2 correspond to Algorithm 24 of [FIPS-205]_ and are performed in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:203|is_valid_signature`. + - Steps 3-10 correspond to Algorithm 20 of [FIPS-205]_ and are performed in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp:212|slh_verify_internal`. + - Steps 2.3, 2.6, 2.8: ``PK.pub_seed`` is omitted as an input because the hash functions are already instantiated with a corresponding member variable. + - ``PK`` is passed to ``slh_verify_internal`` via member variables. + - The lengths of the FORS and the hypertree signatures are precomputed in the ``Sphincs_Parameters`` object. diff --git a/docs/cryptodoc/src/05_07_spx.rst b/docs/cryptodoc/src/05_07_spx.rst deleted file mode 100644 index 30fe3ca5..00000000 --- a/docs/cryptodoc/src/05_07_spx.rst +++ /dev/null @@ -1,381 +0,0 @@ -.. _pubkey/sphincsplus: - -SPHINCS\ :sup:`+` -================= - -Botan's SPHINCS\ :sup:`+` implementation is found in -:srcref:`src/lib/pubkey/sphincsplus/` and follows [SPX-R3]_. -Only the "simple" version of the scheme is available. - -Algorithm Internals -------------------- - -SPHINCS\ :sup:`+` is composed of Forest Of Random Subsets (FORS) few-time signatures -and Winternitz One-Time Signatures (WOTS\ :sup:`+`), which are used within -hypertree signatures (a variant of XMSS\ :sup:`MT`). In short, messages -are signed via FORS. The FORS public key is signed via XMSS with WOTS\ :sup:`+` -as part of the hypertree. The root of the top-level tree in the hypertree -structure then essentially represents the SPHINCS\ :sup:`+` root. -Table :ref:`SPHINCS+ logical components ` -provides an overview of these components and their Botan implementations. The -:ref:`SPHINCS+ ` component, by making use of -the other components, provides the overall signature generation and verification -operations. - -.. _signatures/sphincsplus/table: - -.. table:: SPHINCS\ :sup:`+` logical components and file locations. - :widths: 15 25 45 15 - - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | Component | File | Purpose | Section in [SPX-R3]_ | - +======================================================+===========================================================================+============================================+==============================+ - | :ref:`Types ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_types.h` | Strong types | | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`Address ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_address.h` | Address representation and manipulation | 2.7.3 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`Parameters `| :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_parameters.h` | Parameter set instantiations | 7.1 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`Hashes ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_hash.h` | All hash functions | 7.2 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`Treehash ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_treehash.h` | Merkle tree hashing for FORS and hypertree | 4.1.3, 5.3 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`FORS ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_fors.h` | FORS signature | 5 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`WOTS+ ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_wots.h` | WOTS\ :sup:`+` signature | 3 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`XMSS ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_xmss.h` | XMSS signature | 4.1 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`Hypertree ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sp_hypertree.h` | Hypertree signature | 4.2 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - | :ref:`SPHINCS+ ` | :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.h` | SPHINCS\ :sup:`+` signature | 6 | - +------------------------------------------------------+---------------------------------------------------------------------------+--------------------------------------------+------------------------------+ - -.. _signatures/sphincsplus/types: - -Types -^^^^^ - -In Botan's SPHINCS\ :sup:`+` implementation, the concept of strong types is -used. A strong type can be used to create unique C++ types for data that is -semantically different, but operates on the same internal data structures. -SPHINCS\ :sup:`+` mainly operates on byte vectors in various contexts (e.g., -XMSS tree nodes, WOTS\ :sup:`+` chain node, public/secret seeds, etc.), as well -as combined contexts like a WOTS\ :sup:`+` signature composed of multiple -WOTS\ :sup:`+` nodes. In SPHINCS\ :sup:`+`, every context is represented by a -separate strong type. The NIST status report [IR-8413]_ in Section 4.4.3 notes -that SPHINCS\ :sup:`+` must be implemented with caution due to its complex -nature. The usage of strong types creates a much clearer and more -self-documenting interface, which also guarantees that no data is misused in the -wrong context. More details on all defined strong types and their interpretation -are documented in the respective header file. - -.. _signatures/sphincsplus/address: - -Address -^^^^^^^ - -Botan's SPHINCS\ :sup:`+` addresses wrap the address specification of [SPX-R3]_ -into a class ``Sphincs_Address``. Methods for getting, copying, and setting -specified fields of an address are provided as well as constants. All constants, -fields, and representations are set as specified in Section 2.7.3 of [SPX-R3]_. - -.. _signatures/sphincsplus/parameters: - -Parameters -^^^^^^^^^^ - -The class ``Sphincs_Parameters`` represents all parameters of SPHINCS\ :sup:`+`. -It checks whether provided parameters are valid and can be created from a given -``Sphincs_Parameter_Set``, representing each set of Table :ref:`Supported -SPHINCS+ parameter sets `. -Parameters that can be computed directly from the parameter set are calculated -in the constructor and stored as members instead of being calculated on demand. - -.. _signatures/sphincsplus/hashes: - -Hashes -^^^^^^ - -Botan implements the SHA2 and SHAKE versions of SPHINCS\ :sup:`+` as different -modules. All hash functions used within SPHINCS\ :sup:`+` are represented by the -class ``Sphincs_Hash_Functions``, which can be instantiated from given -parameters and the public seed ``pub_seed``. The public seed is given at -creation because all calls to the ``T`` and ``PRF`` functions use the public -seed as input. All underlying hash function members are instantiated in the -constructor according to Section 7.2 of [SPX-R3]_. The specific child classes -for the SHA2 and SHAKE modules are given in -:srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus_sha2_base/sp_hash_sha2.h` and -:srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus_shake_base/sp_hash_shake.h`, -respectively. - -The specification defines three tweaked hash functions that share similarities. -:math:`\mathbf{T_\ell}` is a tweaked hash function with a message input length -of :math:`\ell n` bytes. :math:`\mathbf{F}` and :math:`\mathbf{H}` are simply -defined as :math:`\mathbf{T_1}` and :math:`\mathbf{T_2}`, for consistency with -other hash-based signature schemes (Section 2.7.1 of [SPX-R3]_). For clarity and -convenience, Botan omits the additional definitions by only implementing and -calling the method ``T``, which allows for arbitrary input lengths. - -.. _signatures/sphincsplus/treehash: - -Treehash -^^^^^^^^ - -Botan generalizes the treehash Algorithms 7 (:math:`\mathtt{treehash}`) and 15 -(:math:`\mathtt{fors\_treehash}`) of [SPX-R3]_ using a single function -``treehash``, similar to SPHINCS\ :sup:`+`'s reference implementation. This -approach minimizes duplicate code while explicitly being in accordance with the -specification (see Section 5.3 of [SPX-R3]_). The only difference between the -treehash of FORS and XMSS is the creation of leaf nodes. Therefore, ``treehash`` -takes a callback function for the leaf creation logic as an additional argument. -This callback function also handles the hash function addresses according to its -purpose. The used callback functions are ``xmss_gen_leaf`` (for XMSS; see -:ref:`SPHINCS+ XMSS `) and ``fors_gen_leaf`` -(for FORS; see :ref:`SPHINCS+ FORS `). - -Another generalization of the specification that is also adapted from the -reference implementation is the integration of authentication path computations -into the ``treehash`` function. To achieve this, the function also takes the -index of the leaf for which to compute the authentication path. When building up -the Merkle tree, the function adds currently computed nodes to the -authentication path if they are contained in it. Alternatively, if only the root -node is requested (i.e. when computing :math:`\mathbf{PK}.\mathsf{root}`), the -leaf index can be set to an empty value, in which case no authentication path is -computed. - -Furthermore, the same generalization ideas are applied to the root computation -from a signature, i.e., Algorithms 10 (:math:`\mathtt{xmss\_pkFromSig}`) and 18 -(:math:`\mathtt{fors\_pkFromSig}`) of [SPX-R3]_. Botan's function -``compute_root`` computes the root of a Merkle tree using a leaf and its -authentication path. For both XMSS and FORS, the logic is the same, with the -only condition being that correctly preconfigured hash function addresses must -be passed to the function. - -.. _signatures/sphincsplus/fors: - -FORS -^^^^ - -Although FORS is a stand-alone few-time signature scheme, only methods relevant -to its overall use in SPHINCS\ :sup:`+` are implemented in Botan. This is -:math:`\mathtt{fors\_sign}` of [SPX-R3]_ (Section 5.5) and -:math:`\mathtt{fors\_pkFromSig}` of [SPX-R3]_ (Section 5.6). More concretely, -both methods are combined into Botan's ``fors_sign_and_pkgen``, which computes -both the signature and the FORS public key. The authentication path computation -therein and :math:`\mathtt{fors\_treehash}` of [SPX-R3]_ (Section 5.3) are -implemented in the generalized ``treehash`` (see -:ref:`SPHINCS+ Treehash `), whereby -:math:`\mathtt{fors\_SKgen}` of [SPX-R3]_ (Section 5.2) is implemented within -the callback function ``fors_gen_leaf`` supplied to ``treehash``. -Similarly, the computation of the root and authentication path in the -implementation of :math:`\mathtt{fors\_pkFromSig}` utilizes the generalized -``compute_root`` method (see :ref:`SPHINCS+ Treehash -`), resulting in the method -``fors_public_key_from_signature``. - -.. _signatures/sphincsplus/wotsplus: - -WOTS\ :sup:`+` -^^^^^^^^^^^^^^ - -The implementation of WOTS\ :sup:`+` in the context of SPHINCS\ :sup:`+` is -based on [SPX-R3]_ with some adaptions of the SPHINCS\ :sup:`+` reference -implementations. In the same manner as FORS, it utilizes a generalization that -fuses the WOTS\ :sup:`+` public key and signature creation, i.e., the algorithms -:math:`\mathtt{wots\_PKgen}` and :math:`\mathtt{wots\_sign}` of [SPX-R3]_, into -one method. When building up an XMSS tree, all leaf nodes must be computed, -which are the hashed WOTS\ :sup:`+` public keys. Only one leaf is used to sign -the underlying root. The WOTS\ :sup:`+` signature consists of values that are -computed in every public key creation; these values are elements of the -WOTS\ :sup:`+` hash chains. This observation leads to Botan's -``wots_sign_and_pkgen`` method that combines both logics, i.e., the entire -WOTS\ :sup:`+` chains are computed for the public key while the WOTS\ :sup:`+` -signature values are extracted at the same time if the current leaf is the -signing one. - -.. _signatures/sphincsplus/XMSS: - -XMSS -^^^^ - -**Remark:** Botan's implementation of the XMSS logic of SPHINCS\ :sup:`+` is -specifically tailored to SPHINCS\ :sup:`+` and separate from Botan's standalone -XMSS implementation (see :ref:`XMSS Key Generation ` -and :ref:`XMSS Signatures `). This is due to the differences in -their tweaked hash applications, including a different hash function addressing. - -To create a single XMSS signature, the building blocks of the preceding sections -are composed into the function ``xmss_sign_and_pkgen``. The generic ``treehash`` -function (see :ref:`SPHINCS+ Treehash `) is the -core logic of XMSS. For generating leaves, it uses the provided callback function -``xmss_gen_leaf``, which calls ``wots_sign_and_pkgen`` (see :ref:`SPHINCS+ WOTS+ -`) since XMSS leaves are hashed WOTS\ :sup:`+` -public keys. This callback function contains all necessary parameters including -the index of the leaf to sign, the message to sign (already divided into -:math:`log(w)` sized chunks), and the required hash function addresses. - -While ``xmss_gen_leaf`` creates and stores the neccessary WOTS\ :sup:`+` -signature, ``treehash`` adds the authentication path to the XMSS signature when -building up the XMSS Merkle tree. Therefore, ``xmss_sign_and_pkgen`` creates its -XMSS root node and signature for a given leaf index and message and covers both -Algorithm 8 (:math:`\mathtt{xmss\_PKgen}`) and Algorithm 9 -(:math:`\mathtt{xmss\_sign}`) of [SPX-R3]_. - -For public key creation, i.e., the creation of :math:`\mathbf{PK}.\mathsf{root}`, -the function ``xmss_gen_root`` is used. It uses ``xmss_sign_and_pkgen`` with an -empty leaf index to only create the root node (see :ref:`SPHINCS+ Treehash -` invoked by ``xmss_sign_and_pkgen``). -Algorithm 10 (:math:`\mathtt{xmss\_pkFromSig}`), i.e., the reconstruction of an -XMSS root node using an XMSS signature, is achieved by calling the function -``compute_root`` (see :ref:`SPHINCS+ Treehash `). - -.. _signatures/sphincsplus/hypertree: - -Hypertree -^^^^^^^^^ - -The XMSS hypertree signature creation according to Algorithm 12 of [SPX-R3]_ -(:math:`\mathtt{ht\_sign}`) is implemented by the method ``ht_sign``. Beginning -at the hypertree's leaves, the hypertree is built up using subsecutive calls of -``xmss_sign_and_pkgen`` (see :ref:`SPHINCS+ XMSS `) -with each call signing the root of the previous XMSS tree or the hypertree -signature's message for the first call. As described in :ref:`SPHINCS+ XMSS -`, this also creates the XMSS root node used in the -next iteration. The leaf indices selected to sign the hypertree signature's -message or roots are computed according to the specification. - -The hypertree verification, Algorithm 13 of [SPX-R3]_ -(:math:`\mathtt{ht\_verify}`), is performed in ``ht_verify``. By calling -``compute_root``, it reconstructs the roots from bottom to top using the -concatenated XMSS signatures. For verification, the final root, which is the -root of the hypertree, is compared with :math:`\mathbf{PK}.\mathsf{root}`. - -.. _signatures/sphincsplus/sphincsplus: - -SPHINCS\ :sup:`+` -^^^^^^^^^^^^^^^^^ - -All the above components are combined to constitute Botan's SPHINCS\ :sup:`+` -component used for creating or verifying SPHINCS\ :sup:`+` signatures. - -.. _pubkey_key_generation/sphincsplus: - -Key Generation --------------- - -Botan supports the parameter sets provided in Table 3 of [SPX-R3]_ for the SHA2 -and SHAKE instantiations of hash functions (note that currently, the instantiations -with Haraka are not supported). An overview is provided in Table :ref:`Supported -SPHINCS+ parameter sets `. - -.. _pubkey_key_generation/sphincsplus/params_table: - -.. table:: Supported SPHINCS+ parameter sets (see Table 3 of [SPX-R3]_). can either be ``sha2`` or ``shake``. - - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | Parameter Set | :math:`n` | :math:`h` | :math:`d` | :math:`log(t)` | :math:`k` | :math:`w` | - +==================================+=============+=============+===========+=================+===========+===========+ - | ``SphincsPlus--128s-r3.1`` | 16 | 63 | 7 | 12 | 14 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | ``SphincsPlus--128f-r3.1`` | 16 | 66 | 22 | 6 | 33 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | ``SphincsPlus--192s-r3.1`` | 24 | 63 | 7 | 14 | 17 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | ``SphincsPlus--192f-r3.1`` | 24 | 66 | 22 | 8 | 33 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | ``SphincsPlus--256s-r3.1`` | 32 | 64 | 8 | 14 | 22 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - | ``SphincsPlus--256f-r3.1`` | 32 | 68 | 17 | 9 | 35 | 16 | - +----------------------------------+-------------+-------------+-----------+-----------------+-----------+-----------+ - -SPHINCS\ :sup:`+` key generation follows Section 6.2 of [SPX-R3]_ and is -implemented in :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp` -within the ``SphincsPlus_PrivateKey`` constructor. It works as follows: - -.. admonition:: SPHINCS+ Key Generation - - **Input:** - - - ``rng``: random number generator - - ``params``: SPHINCS\ :sup:`+` parameters - - **Output:** - - - ``SK``, ``PK``: private and public key - - **Steps:** - - 1. Generate new values ``secret_seed``, ``prf``, and ``public_seed`` using ``rng``. - 2. ``sphincs_root = xmss_gen_root(secret_seed)`` - (see :ref:`SPHINCS+ XMSS `). - 3. | ``SK = {secret_seed, prf, public_seed, sphincs_root}`` - | ``PK = {public_seed, sphincs_root}`` - - **Notes:** - - - The creation of a public key is conducted using the - ``public_key`` method of the private key. - -Signature Creation ------------------- - -A SPHINCS\ :sup:`+` signature is created in the following manner, following -Algorithm 20 of [SPX-R3]_ (see :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp`): - -.. admonition:: SPHINCS+ Signature Creation - - **Input:** - - - ``m``: message to be signed - - ``SK``: SPHINCS\ :sup:`+` secret key, ``SK = {secret_seed, prf, public_seed, sphincs_root}`` - - **Output:** - - - ``sig``: SPHINCS\ :sup:`+` signature - - **Steps:** - - 1. ``opt_rand`` is set to ``SK.public_seed``. If the scheme is randomized, ``opt_rand`` is instead set to a freshly generated random byte vector. - 2. ``msg_random_s = PRF_msg(m, SK.prf, opt_rand)`` and append ``msg_random_s`` to ``sig``. - 3. ``mhash || tree_idx || leaf_idx = H_msg(msg_random_s, SK.sphincs_root, m)``. - 4. Set type of ``fors_addr`` to FORS tree, its tree to ``tree_idx``, and its keypair address to ``leaf_idx``. - 5. ``fors_sig, fors_root = fors_sign_and_pkgen(mhash, SK.secret_seed, fors_addr)`` and append ``fors_sig`` to ``sig``. - 6. ``ht_sig = ht_sign(fors_root, SK.secret_seed, tree_idx, leaf_idx)`` and append ``ht_sig`` to ``sig``. - - **Notes:** - - - ``SK.public_seed`` is omitted as an input because the hash functions are already instantiated with a corresponding member variable. - -Signature Validation --------------------- - -A SPHINCS\ :sup:`+` signature is verified in the following manner, following -Algorithm 21 of [SPX-R3]_ (see :srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus.cpp`): - -.. admonition:: SPHINCS+ Signature Validation - - **Input:** - - - ``m``: message to be validated - - ``sig``: signature to be validated - - ``PK``: SPHINCS\ :sup:`+` public key, ``PK = {public_seed, sphincs_root}`` - - **Output:** - - - ``true``, if the signature for message ``m`` is valid. ``false`` otherwise - - **Steps:** - - 1. Take the first ``n`` bytes of ``sig`` as value ``msg_random_s``. - 2. ``mhash || tree_idx || leaf_idx = H_msg(msg_random_s, PK.sphincs_root, m)``. - 3. Set type of ``fors_addr`` to FORS tree, its tree to ``tree_idx``, and its keypair address to ``leaf_idx``. - 4. Take the FORS signature bytes of ``sig`` as value ``fors_sig_s``. - 5. ``fors_root = fors_public_key_from_signature(mhash, fors_sig_s, fors_addr)``. - 6. Take the hypertree signature bytes of ``sig`` as value ``ht_sig_s``. - 7. The signature is valid iff ``ht_verify(fors_root, ht_sig_s, PK.sphincs_root, tree_idx, lead_idx) = true``. - - **Notes:** - - - The lengths of the FORS and the hypertree signatures are precomputed in the ``Sphincs_Parameters`` object. - - ``PK.public_seed`` is omitted as an input because the hash functions are already instantiated with a corresponding member variable. diff --git a/docs/cryptodoc/src/05_10_frodokem.rst b/docs/cryptodoc/src/05_10_frodokem.rst index b4f91ee3..dd824cae 100644 --- a/docs/cryptodoc/src/05_10_frodokem.rst +++ b/docs/cryptodoc/src/05_10_frodokem.rst @@ -90,7 +90,7 @@ Algorithm Internals Types ^^^^^ -For similar reasons as for :ref:`SPHINCS+ strong types `, +For similar reasons as for :ref:`SPHINCS+ strong types `, Botan's FrodoKEM implementation relies on the use of strong types. As most data is just defined as byte sequences, the usage of strong types ensures that the correct data is used at each step of the computation. diff --git a/docs/cryptodoc/src/90_bibliographie.rst b/docs/cryptodoc/src/90_bibliographie.rst index c072e2f7..3401783c 100644 --- a/docs/cryptodoc/src/90_bibliographie.rst +++ b/docs/cryptodoc/src/90_bibliographie.rst @@ -51,6 +51,10 @@ SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf +.. [FIPS-205] Federal Information Processing Standards Publication 205. + Stateless Hash-Based Digital Signature Standard + http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf + .. [FrodoKEM-ISO] Erdem Alkim, Joppe W. Bos, Léo Ducas, Patrick Longa, Ilya Mironov, Michael Naehrig, Valeria Nikolaenko, Chris Peikert, Ananth Raghunathan, Douglas Stebila "FrodoKEM: Learning With Errors Key Encapsulation Preliminary Standardization Proposal (2023-03-14)", Preliminary Standardization Proposal submitted to ISO, 2023, @@ -82,11 +86,6 @@ https://ieeexplore.ieee.org/document/8637988, 25 January 2019 -.. [IR-8413] NIST Interagency or Internal Report 8413 Upd. 1: - "Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process", - https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413-upd1.pdf, - September 2022 - .. [ISO-9594-8] ISO/IEC 9594-8:2017: Information technology -- Open Systems Interconnection -- The Directory -- Part 8: Public-key and attribute certificate frameworks From e2ab5e3c59c2a7d01e75fab00e2ed1b8733dd91a Mon Sep 17 00:00:00 2001 From: Fabian Albert Date: Thu, 24 Oct 2024 15:45:55 +0200 Subject: [PATCH 2/2] Fix source references --- docs/cryptodoc/src/05_07_slh_dsa.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/cryptodoc/src/05_07_slh_dsa.rst b/docs/cryptodoc/src/05_07_slh_dsa.rst index 7f36e5f9..120de39e 100644 --- a/docs/cryptodoc/src/05_07_slh_dsa.rst +++ b/docs/cryptodoc/src/05_07_slh_dsa.rst @@ -106,8 +106,9 @@ creation because all calls to the ``T`` and ``PRF`` functions use the public seed as input. All underlying hash function members are instantiated in the constructor according to Sections 11.1 and 11.2 of [FIPS-205]_. The specific child classes for the SHA2 and SHAKE modules are given in -:srcref:`[src/lib/pubkey/sphincsplus]/sphincsplus_sha2/sp_hash_sha2.h` and -:srcref:`[src/lib/pubkey/sphincsplus]/sphincsplus_shake/sp_hash_shake.h`, +:srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus_sha2_base/sp_hash_sha2.h` and +:srcref:`[src/lib/pubkey/sphincsplus/sphincsplus_common]/sphincsplus_shake_base/sp_hash_shake.h`. + respectively. The specification defines three tweaked hash functions that share similarities.