Subject: [Cfrg] [Probable spam]XMSS draft: some comments and questions

From: "И.Л." <[email-masked]>
Date: Wed, 27 Jul 2016 17:21:05 +0300

Dear Andreas, dear all!

I've read the proposed draft, and have some editorial comments and a small question.

First part of editorial comments is refers to proposed notations and pseudocodes. As we can see roughly all mathematical and logical operations are stated during the text, but during the pseudocodes sometimes appears operations that wasn't stated, for example, +=, -=, ++. Their definition is clear from programmers point of view, but may be it would be better to use the 'same' notations throughout the draft. 

Second part of editorial comments is refers to the operations << and >>. As i know it's better to state that appeared vacant-bit positions are filled with zeroes, cause without this statement it could lead us to misreading.  

The question is about design rationales stated in section 5.
As i know there are three main methods to create keyed hash function from keyless (in case we don't want to use NMAC-like constructions): secret prefix (H(K||x)), secret suffix (H(x||K)) and envelope method (H(K1||x||K2)). All this methods have their good and bad sides, but as we can see your design couldn't be incorporated in any of them. What was the purpose of this choice? Was the cryptography qualities of this 'construction' somehow measured? 
BTW: what is the purpose to introduce a mandatory hash function accounting that anyone could add new parameter sets, as you said? 

Thank you,
I.L.

---

From: "A. Huelsing" <[email-masked]>
Date: Wed, 27 Jul 2016 17:21:37 +0200

> Second part of editorial comments is refers to the operations << and >>. As i know it's better to state that appeared vacant-bit positions are filled with zeroes, cause without this statement it co…
You are right, especially the shifts should probably be formally defined.
> As i know there are three main methods to create keyed hash function from keyless (in case we don't want to use NMAC-like constructions): secret prefix (H(K||x)), secret suffix (H(x||K)) and envelo…
We actually use the secret prefix, just with minor modifications:
- As we need four function families, we decided to introduce domain separation.
- For stronger security guarantees, you want the secret to fill a full input
block to the underlying iteration in the secret prefix type. This applies
especially to Merkle-Damgard based hash functions like SHA2. Hence, we pad the
key to the internal block length of the hash function.
- To save space, we combined these two things, i.e. we used the padding to also
handle the domain separation.
> BTW: what is the purpose to introduce a mandatory hash function accounting that anyone could add new parameter sets, as you said? 
That was already partially answered by Uri. I just want to add the following. We
left the option to define new parameter sets for two reasons:
1. There always exists a chance that the used hash function gets broken by
advances in cryptanalysis (remember SHA1?).
2. There might be reasons why some people might want to use different hash
functions, e.g. a light weight hash function to use this for signatures on
resource constrained devices.

- Andreas

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 27 Jul 2016 15:24:57 +0000

On 7/27/16, 11:21 , "Cfrg on behalf of A. Huelsing" <[email-masked]
on behalf of [email-masked]> wrote:

>> As i know there are three main methods to create keyed hash function
>>from keyless (in case we don't want to use NMAC-like constructions):
>>secret prefix (H(K||x)), secret suffix (H(x||K)) and envelope method
>>(H(K1||x||K2)). All this methods have their good and bad sides, but as
>>we can see your design couldn't be incorporated in any of them. What was
>>the purpose of this choice? Was the cryptography qualities of this
>>'construction' somehow measured?

I think it was Bart Preneel who showed that you have to pad the prefix to
the full block size.

>handle the domain separation.

Makes sense to me.