[COSE] Comments on SHAKE usage in draft-ietf-cose-hash-algs-09.txt

[Robert Moskowitz <[e-mail]>]

I appologize for only reviewing this draft now.  My focus has been on 
DRIP where I have been using Keccak derived functions...

Review and suggested editorial additions to sec 3.3:

"The length of the hash value stored is 256-bits
    for SHAKE-128 and 512-bits for SHAKE-256."

I am reading this as there is a field where the length of the hash 
output is carried, and it is 256 bits long for SHAKE-128 and 512-bits 
for SHAKE-256.  This is extreme overkill and would only be justified in 
a protocol that is concerned about bits on the wire if these are the 
sizes of these fields for other algorithms.  A length field of 8 bits 
would handle a hash length of 255 bits, so the max needed should only be 
12 bits.

But if this is what is used elsewhere and simplfies coding, I can see 
why it was specified this way, but it is a bad choice for bits on the 
wire, or the meaning of the text is wrong.

Perhaps it should be:

"The hash length of the hash value is stored in 256-bits
    for SHAKE-128 and 512-bits for SHAKE-256."


If the meaning is this is the fixed SIZE of the hash outputs, I would 
clear up the text as follows:

"Although SHAKE can create any length hash, here it is fixed.
The fixed length of the hash value stored is 256-bits
    for SHAKE-128 and 512-bits for SHAKE-256."

Obviously, I as an outside reader that has worked with Keccak functions 
is confused.  What about readers that have not spent time with the 
various Keccak functions?

Now if your intent is a variable length hash support, then the Security 
Considerations needs to reflect the warning in FIPS 202, Appendix A.1 
and A.2:

"The security strengths for SHAKE are provided in [FIPS 202], Appendix 
A.1, Table 4. Further, considering Appendix A.2, note that SHAKE has the 
potential for generating related outputs—a property that designers of 
security applications/protocols/systems may not expect of hash 
functions.  This property is important to consider in the development of 
applications of SHAKE.  If an attacker is able to induce one of the 
parties to use a different value for keylength, say 168 bits, but the 
same value for hashmaterial, then the two parties will end up with the 
following hashs:

SHAKE128(hashmaterial, 112) = fg
SHAKE128(hashmaterial, 168) = fgh,

By incorporating the length of the output and/or other information with 
the message input to the hash, a disagreement or misunderstanding 
between two users of SHAKE about the length of the hash they are 
deriving would almost certainly not lead to
related outputs."

Thank you for your consideration.

Robert Moskowitz