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

From: Robert Moskowitz <[email-masked]>
Date: Mon, 16 Nov 2020 16:21:09 -0500

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

---

From: Matthew Miller <[email-masked]>
Date: Mon, 16 Nov 2020 18:03:20 -0700

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 16 Nov 2020 21:06:22 -0500

Matt,

Your text merges my comment well into the original and I feel that 
outside readers will get it right.

Since your intent is fixed length, there is no need to add to the 
Security Considerations section.

On 11/16/20 8:03 PM, Matthew Miller wrote:
> 3.3 to:https://www.linkedin.com/comm/in/richlangston?midToken=AQFG4x8T0hPDDw&midSig=051yXA7iyTkpw1&trk=eml-email_m2m_invite_single_01-hero-4-prof%7Ecta&trkEmail=eml-email_m2m_invite_single_01-hero-4-prof%7Ecta-null-6fvyf1%7Ekhlarqf3%7Eol-null-neptune%2Fprofile%7Evanity%2Eview&lipi=urn%3Ali%3Apage%3Aemail_email_m2m_invite_single_01%3BLqJbZZv6Rw%2B6dvfcy%2BAssA%3D%3DMatt
>
> """

---

From: Matthew Miller <[email-masked]>
Date: Tue, 17 Nov 2020 08:36:55 -0700

[now with a chair hat]

Unless the working group objects, Murray will add an RFC Editor note:

Please change the third paragraph in Section
3.3 from:

"""
Unlike the SHA-2 hash functions, no algorithm identifier is created
for shorter lengths.  The length of the hash value stored is 256-bits
for SHAKE-128 and 512-bits for SHAKE-256.
"""

to instead read:

"""

- Ivaylo and Matthew
COSE Chairs