It is my understanding that this would be a true statement. SHAKE unlike SHA-2 does not produce the same prefix based on a different output length. This means that one cannot just truncate the resulting hash value to produce a smaller tag.
Jim From: Laurence Lundblade <[email protected]> Sent: Saturday, March 2, 2019 11:42 AM To: Jim Schaad <[email protected]> Cc: Russ Housley <[email protected]>; cose <[email protected]> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document I’m not deeply familiar with SHAKE, but can the length of the bstr containing the SHAKE hash serve as the length parameter? LL On Mar 1, 2019, at 11:01 AM, Jim Schaad <[email protected] <mailto:[email protected]> > wrote: After sleeping on this I want to change what I said slightly. COSE does not support the same type of structure as the ASN.1 AlgorithmIdentifier where the algorithm identifier and a set of parameters are combined together into a single encodable entity. Instead parameters for algorithms are defined and placed into a COSE structure either as protected, unprotected or implicit attributes. Since the general structure I have been telling people to use an array with an algorithm identifier and the hash value with additional elements dealing with thing like how do you find it and other sorts of things. Thus we could indeed define equivalent to the -len version by creating an algorithm parameter. The question would be should we define some type of COSE structure which is similar to AlgorithmIdentifier so that it can be referenced and used in those cases where parameters should be included with the algorithm number/string is placed. Jim From: COSE < <mailto:[email protected]> [email protected]> On Behalf Of Jim Schaad Sent: Thursday, February 28, 2019 5:13 PM To: 'Russ Housley' < <mailto:[email protected]> [email protected]> Cc: 'cose' < <mailto:[email protected]> [email protected]> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document COSE does not support parameters so the later two cannot be supported by themselves. Rather a new code point would be assigned for a fixed parameter set. Thus we would need to decide what lengths should be supported for the latter two options. Jim From: Russ Housley < <mailto:[email protected]> [email protected]> Sent: Thursday, February 28, 2019 4:48 PM To: Jim Schaad < <mailto:[email protected]> [email protected]> Cc: cose < <mailto:[email protected]> [email protected]> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document Jim: Four object identifiers for SHAKE128 and SHAKE256 hash functions are defined by NIST [1]: id-shake128 id-shake256 id-shake128-len id-shake256-len The first two have no parameters, and the second two have an output length parameter. These are the ones that should probably be included in a COSE-friendly manner. Russ [1] <https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration> https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration On Feb 27, 2019, at 9:09 PM, Jim Schaad < <mailto:[email protected]> [email protected]> wrote: I have much less of a problem with just doing the hashes. So which SHAKE hashes do you think we should be defining? To match SHA-2 it would be SHAKE-128/64, SHAKE-128 and SHA-256. I don't know if there is a similar change in processing if you look at the difference between 32 and 64 bit processors which can be found with the SHA-2 implementations. This lead to putting in the SHA-512/256 registration that I put in the current draft. Jim -----Original Message----- From: Russ Housley < <mailto:[email protected]> [email protected]> Sent: Wednesday, February 27, 2019 12:54 PM To: Jim Schaad < <mailto:[email protected]> [email protected]> Cc: cose < <mailto:[email protected]> [email protected]> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document Jim: I as suggesting that SHAKE be added as a hash function. Sure, it might be added to other documents as well, but I was not suggesting that. Russ On Feb 27, 2019, at 3:44 PM, Jim Schaad < <mailto:[email protected]> [email protected]> wrote: I am not sure that I completely agree with that. First adding SHAKE other than as a hash function would mean that this is not a standalone hash algorithm document. Second, I am not sure at this point of all of the different varieties and locations where SHAKE should be added. Hash Functions: Do we have just the two versions or do we have a truncated 64-bit version as well. Not sure about where the variant that had a small b would fall in here, but for now it might just be ignored. Signature Algorithms: At this point I don't know if there would need to be any RSA versions or not. Not sure what to say about DH versions. ECDSA maybe makes some sense. Message Authentication Algorithms: Do we put in a KMAC here or not? Key Derivation Functions: Do we just do HMAC with a KMAC drop in here or does NIST have a different recommended way to do KDF with SHAKE functions? We should definitely be able to get rid of HMAC when doing this as SHAKE already has length extension attacks solved. Key Agreement Functions: Since you need to have a combined key agreement algorithm and KDF for COSE, how many of these are we going to define. Encryption and Key Wrap algorithms: I sorta hope that this can be avoided for now, but I know that there are some AEAD algorithms which are built using Keccak as an underlying primitive and I am not personally ready to try and figure out how it works, but it is something that might need to be discussed here (and in CFRG). Given that the object is to get the hash algorithm assignments done for the SUIT developers, I am not sure that doing this work in this document makes sense. I will also note that the CMS work in LAMPS and CURDLE ignored the issues of new KDFs w/ SHAKE entirely so that maybe groundbreaking work here. Jim -----Original Message----- From: Russ Housley < <mailto:[email protected]> [email protected]> Sent: Tuesday, February 26, 2019 7:04 AM To: Jim Schaad < <mailto:[email protected]> [email protected]> Cc: cose < <mailto:[email protected]> [email protected]> Subject: Re: [COSE] Call for Consensus: Standalone Hash Algorithms Document Jim: It would probably be easy to add SHAKE now. The equivalent document for CMS is draft-ietf-lamps-cms-shakes. Russ On Feb 25, 2019, at 7:38 PM, Jim Schaad < <mailto:[email protected]> [email protected]> wrote: A version of what this document would look like can be found here <https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01> https://tools.ietf.org/html/draft-schaad-cose-hash-algs-01 Jim -----Original Message----- From: COSE < <mailto:[email protected]> [email protected]> On Behalf Of Matthew A. Miller Sent: Monday, February 25, 2019 4:16 PM To: cose < <mailto:[email protected]> [email protected]> Subject: [COSE] Call for Consensus: Standalone Hash Algorithms Document This messages starts a call for consensus to separate the COSE hash algorithms into a separate document, ending on 2018-03-10. In the virtual interim on 02-15, it was proposed to separate them from draft- ietf-cose-x509, to allow the hash algorithm registrations to stabilize more quickly than the rest of the X.509 draft. If the working group agrees with separating the algorithms, then a document will be published that consists of Section 4 (Hash Algorithm Identifiers) and Section 5.3 (COSE Algorithm Registry) from draft-ietf-cose-x509. Please respond with whether or not you support separating the hash algorithms into a separate document. If you do not support this, please indicate why not. - Ivaylo and Matthew COSE Chairs _______________________________________________ COSE mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/cose> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
