[with no hat yet] Thank you for the review and suggestions, Bob. They are welcome, even if a bit belated.
The intent in this document is a fixed-length hash. With your suggested text, I believe that changes the third paragraph in Section 3.3 to: """ Unlike the SHA-2 hash functions, no algorithm identifier is created for shorter lengths. 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. """ Since the intent is a fixed-length, it does not seem to me the suggested additions to the Security Considerations are needed. Is that a correct read? - m&m Matthew A. Miller On Mon, Nov 16, 2020 at 2:21 PM Robert Moskowitz <[email protected]> wrote: > > 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
