xmss / xmss-reference Goto Github PK

Please share the steps to run this repo on WIndows

hash_message expects the message at offset 4n. When padding_len < n, then it computes H(PADDING_HASH || R || Root || 0...0 || M') instead of H(PADDING_HASH || R || Root || M) as described by the NIST draft (where M' is M with last n - padding_len bytes truncated.)

Variable Length Allocations are used in the reference code.

Refactoring of these are recommended for anyone building off this codebase, although it is accepted that the risk posed is minimal.

It would be helpful if I could get a manual on building and executing this repo.

Hi

In the following code:
https://github.com/XMSS/xmss-reference/blob/171ccbd26f098542a67eb5d2b128281c80bd71a6/wots.c#L85C5-L85C5

The types of variables for the following contains both signed and unsigned int:

• params->wots_w: unsigned int
• csum: int
• msg_base_w: const int*

This might cause issues in corner cases.

1. Should csum / msg_base_w be unsigned?
2. Should csum be verified to be positive before the bitshift?

last iteration fails. Here is the output:

  - iteration #1022:
    smlen as expected [2532].
    verification succeeded.
    mlen as expected [32].
    output message as expected.
    flipping a bit of m invalidates signature.
  - iteration #1023:
    smlen as expected [2532].
  X verification failed!
  X mlen incorrect [0 != 32]!
  X output message incorrect!
    flipping a bit of m invalidates signature.

target machine: PC x86_64

Hello,

The description of xmss_xmssmt_initialize_params() suggests that it would initialize a "params" structure from the sort of data that is available in SP 800-208 tables. At least padding_len is left untouched, which causes unpredictable behavior if you try to use it.

Cheers,

• markku

I would like to implement in C#. To do this I need test vectors.

I do not want to look at your code for obvious reasons - I want to see if the spec is clear enough to implement independently.