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 <[email protected]> 
Sent: Thursday, February 28, 2019 4:48 PM
To: Jim Schaad <[email protected]>
Cc: cose <[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

 





On Feb 27, 2019, at 9:09 PM, Jim Schaad <[email protected]
<mailto:[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 <[email protected] <mailto:[email protected]> >
Sent: Wednesday, February 27, 2019 12:54 PM
To: Jim Schaad <[email protected] <mailto:[email protected]> >
Cc: cose <[email protected] <mailto:[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 <[email protected]
<mailto:[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 <[email protected] <mailto:[email protected]> >
Sent: Tuesday, February 26, 2019 7:04 AM
To: Jim Schaad <[email protected] <mailto:[email protected]> >
Cc: cose <[email protected] <mailto:[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 <[email protected]
<mailto:[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

Jim





-----Original Message-----
From: COSE <[email protected] <mailto:[email protected]> > On Behalf
Of Matthew A. Miller
Sent: Monday, February 25, 2019 4:16 PM
To: cose <[email protected] <mailto:[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
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/cose

 



_______________________________________________
COSE mailing list
[email protected] <mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/cose

 

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to