open-quantum-safe
Always almost blank and the same secret key - LMS
Hi everyone,
I am experimenting with stateful signatures in order to measure how much heap and stack memory they consume. For some reason, I want to store them in a file, but I first wanted to see them in hex on the terminal. I am able to print public and secret keys of XMSS variants, but I have no luck at printing secret key of LMS variants although there is no problem with printing their public keys. I use fprint_l_str function that I found in one of the test files. It prints all the keys very well, and I obtain different values at every run as expected, except for the LMS secret key. It always prints an unreasonable and the same value, which is
01000000000000000500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Is it so by design or am I doing something wrong? Isn't it possible to save the current state of the secret key in a file and read it and use for signing later on?
I'd appreciate if you help me comprehending the reason of this issue.
Best, Samet
The LMS secret key is a pointer to a data structure. Are printing the pointer value or dereferenced fields within it?
I am referring to the block of bytes within the secret key by using the secret_key_data field. You can find the entire function call that I use below.
fprint_l_str(stdout, "sk = ", secret_key_keygen->secret_key_data, sig->length_secret_key);.
Without the field, it fails at compile time.
Edit: I tried serializing the key first. Then, it suddenly became 10,980 bytes long, which doesn't make sense to me. However, the output is more reasonable this time and changes at every run. A sample is given below.
000000000000000051ffffffffffffff775122e95cf33f2b691c85703b7728f1df31b9e634e97be6a88328b7d36067e8b12777d8518e41430d1c6ec32f293d2b8000000ab6e3ec78d90fd1a1ce5d4c1de097daac7826167c50cd5c3bd128b6cbc2dc3d1b36c250ad8c12b271dd6dd99a5b33b676417819862589ed326a2cb5a7732c34cfb31bc6a65c999bd2732caaec5e20bc033044bddbffe6f02e48b086ac97e2e1561c2f4e74d9ce58cb3db87d43f2a0ea7fb04287acebe5dee01f4cd8b40dd8072ad7524c4e0423f1190aeab15983e4196c1473e7b789b0a42c5555cf2a042e704a21c13e03ead6c534992fece4332a644ecfed18e364cc612cb2d297b7851d28646b5f1791547b2cfb0d371561c69acb81c30c6d30f317a2023d057e0a2ccf7a6898ab0a595c19a4dafa533881460da554e5fa56b12a0af3f9c3f2fcb1e031c0584835ef06a09f7575e7528368d847dbef2c8ffb6d516c80db7ffe7d6bce94fae1da602c5e6b3cd08b977d07fd7a619c91115087c10174f4410874de2d8286eabd67d0b804e3184bceb423b3fce509ebb01f35cdffe3f80fe6faa2530d76995b1a00...00
@ashman-p Are you able to take a look at this and see if it's expected behaviour?
@ashman-p Are you able to take a look at this and see if it's expected behaviour?
Yes. I will take a look.
