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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
