#include "include/jxmssaddr.h"

Detailed Description

The eXtended Merkel Signature Scheme (XMSS), a hash-bashed digital signature scheme that is based on existing descriptions in scientific literature. There are three types of signatures specified for Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main bulding block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collison resistance of the underlying hash function is broken. Its is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers

QuantumResist

There are three different types of addresses for the different use cases. One type is used for the hashes in OTS schemes, one is used for hashes within the main Merkle tree construction, and one is used for hashes in the L-trees. The latter is used to compress one-time public keys. All these types share as much format as possible

The structure of an address complies with word borders, with a word being 32-bits long Only the tree address is too long to fit in a single word, but it can fit in a double word. Addresses are structed as follows

An address always starts with a layer address of one word followed by a tree address of two words. Both of these addresses are needed for single and multi-tree variants and describe the position of a tree within a multi-tree. They are therefore set to zero in a single tree implementation

For multi-tree hash-based signatures, the layer address describes the height of a tree within the multi-tree, starting from height zero for trees at the bottom layer. The tree address describes the position of a tree within a layer of a multi-tree starting with index zero for the leftmost tree

The next word in the address defines the type of address with the following possible values

OTS address - value of 0
L-tree address - value of 1
Hash tree address - value of 2

NOTE: Whenever a the type is changed, all following words should be initialzed to zero to prevent non-zero values in unused padding words

OTS Address

For the OTSADDR type, the type word is followed by the OTS address word that encodes the index of the OTS key pair within the tree. The next word encodes the chain address followed by a word that encodes the address of the hash function call within the chain The last word, called keyAndMask, is used to generate two different addresses for one hash function call. The word is set to zero to generate the key. To generate the n-byte bitmask, the word is set to one

The OTS Address structure is as follows. All bytes are in networkd byte order (bit-endian)

+--------------------------+
| layer address  (32 bits) |
+--------------------------+
| tree address   (64 bits) |
+--------------------------+
| type = 0       (32 bits) |
+--------------------------+
| OTS Address    (32 bits) |
+--------------------------+
| chain address  (32 bits) |
+--------------------------+
| hash address   (32 bits) |
+--------------------------+
| keyAndMash     (32 bits) |
+--------------------------+

L-tree Address

For the L-tree address, the type is set to one (which resets all words below the type). The type word is followed by the L-tree address word that encodes the index of the leaf computed with this L-tree. The following word encodes the index of the node at that height, inside the L-tree. This time, the last word, keyAndMask, is used to generate three different addresses for one function call. The keyAndMask word is set to zero to generate the key To generate the most significant 'n' bytes of the 2n-byte bitmask, the word is set to one The least significant bytes are generated using the address with the word set to two

The L-tree Address structure is as follows. All bytes are in networkd byte order (bit-endian)

+--------------------------+
| layer address  (32 bits) |
+--------------------------+
| tree address   (64 bits) |
+--------------------------+
| type = 1       (32 bits) |
+--------------------------+
| L-tree Adddress(32 bits) |
+--------------------------+
| tree height    (32 bits) |
+--------------------------+
| tree index     (32 bits) |
+--------------------------+
| keyAndMash     (32 bits) |
+--------------------------+

Hash tree Address

For the 'hash tree address', the type word is set to two, followed by a zero padding of one word. The next word encodes the height of the tree node being input for the next computation, followed by a word that encodes the index of this node at that height. Just like the L-tree address, the last word, keyAndMask, is used to generate three different addresses for one function call. The word is set to zero to generate the key. To generate the most significant 'n' bytes of the 2n-byte bitmask, the word is set to one. The least significant bytes are generated using the address with the word set to two

+--------------------------+
| layer address  (32 bits) |
+--------------------------+
| tree address   (64 bits) |
+--------------------------+
| type = 2       (32 bits) |
+--------------------------+
| Padding = 0    (32 bits) |
+--------------------------+
| tree height    (32 bits) |
+--------------------------+
| tree index     (32 bits) |
+--------------------------+
| keyAndMash     (32 bits) |
+--------------------------+

All fields within these addresses encode unsigned integers. The spec assumes the setType() methods sets the four words following the type word to zero

XMSS Tree

[1] RFC8391 XMSS_eXtended Merkle Signature Scheme

For API Documentation:

See also: ProtocolPP::jprotocol; ProtocolPP::jxmssaddr; ProtocolPP::jxmssa; ProtocolPP::jwots; ProtocolPP::jxmss

For Additional Documentation:

See also: jprotocol; jxmssaddr; jxmssa; jwots; jxmss

The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)

No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing

Licensing information can be found at www.protocolpp.com/license with use of the binary forms permitted provided that the following conditions are met:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
Commercial use (incidental or not) requires a fee-based license obtainable at www.protocolpp.com/shop
Academic or research use requires prior written and notarized permission from John Peter and Sheila Rocha Greninger

Use of the source code requires purchase of the source code. Source code can be purchased at www.protocolpp.com/shop

US Copyrights at https://www.copyright.gov/
- TXu002059872 (Version 1.0.0)
- TXu002066632 (Version 1.2.7)
- TXu002082674 (Version 1.4.0)
- TXu002097880 (Version 2.0.0)
- TXu002169236 (Version 3.0.1)
- TXu002182417 (Version 4.0.0)
- TXu002219402 (Version 5.0.0)
- TXu002272076 (Version 5.2.1)

The name of its contributor may not be used to endorse or promote products derived from this software without specific prior written permission and licensing

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER AND CONTRIBUTOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

The documentation for this class was generated from the following file:

jxmss/include/jxmssaddr.h