Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

I don't know what Jim is arguing.  I think that I am trying to say that
there may be some language that is not clear at some point in the future
although it is perfectly fine today (mostly).  I do not remember ever seeing
any language in any of the hash signature documents that say that the same
hash function should be used from top to bottom.  I also think that there
will be some push in the not so near future to have some other hash
functions be permitted because of things like the better efficiency of
SHA-512 in many cases or the move to SHAKE as a different hash function.  I
worry that this means that the same hash function may not be used from top
to bottom in a hash signature key.  I also worry that my current code base
does not have any way to get the parameters for the bottom of the tree and
the same thing may be true for an HSM.  The top algorithms can be retrieved
from the public key, but not the bottom algorithms.

Jim

From: Russ Housley <housley@vigilsec.com> 
Sent: Saturday, March 16, 2019 4:33 PM
To: Daniel Van Geest <Daniel.VanGeest@isara.com>
Cc: Jim Schaad <ietf@augustcellars.com>;
draft-ietf-lamps-cms-hash-sig@ietf.org; SPASM <spasm@ietf.org>
Subject: Re: [lamps] Question on draft-ietf-lamps-cms-hash-sig

Daniel:

I believe that Jim is arguing that the same hash function should always be
used for both the content and the HSS/LMS tree,

Russ

On Mar 15, 2019, at 3:30 PM, Daniel Van Geest <Daniel.VanGeest@isara.com
<mailto:Daniel.VanGeest@isara.com> > wrote:

My thoughts,

On 2019-03-14, 2:39 PM, "Spasm on behalf of Jim Schaad" <
<mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org on behalf of
<mailto:ietf@augustcellars.com> ietf@augustcellars.com> wrote:

I was tossing together some code to look at producing some samples and I

ended up with a pair of questions:

1.  If I have a hash signature tree which uses multiple different hash

algorithms in it, which of those hash algorithms am I to placed in the

digestAlgorithm field?  For example, suppose that I am using an LMS type

with a hash of SHAKE128 and an LMOTS type with a hash of SHA256.  Or as a

different example, suppose that I have a two deep tree and the top level

uses SHA512 in both places but the next level down uses SHAH256 in both

places?  

RFC 5652 section 5.3 defines the digestAlgorithm member of SignerInfo as:

      digestAlgorithm identifies the message digest algorithm, and any

      associated parameters, used by the signer.  The message digest is

      computed on either the content being signed or the content

      together with the signed attributes using the process described in

      Section 5.4.

In HSS, the hash algorithm used to digest the content is the one in the
LMOTS type of the bottom-most tree.  The other hash algorithms are used to
hash within the Merkle tree, or to hash the LMS public key of a lower tree.
So in both your examples the answer would be SHA256.

2.  If there are signed attributes present, then it t required that the body

digest algorithm match that of the hash signature tree or can it be

different.  If it is different, is that not the value that should be placed

in the digestAlgorithm field?  Consider digesting the body with SHA512, but

only using SHA256 in the hash function on the assumption that the random

field in the signing operation provides a higher level of security and thus

a weak attempt is being made to match them together.  (I am sure that this

is not the correct pairing for matching, just demonstrating a point.)

cms-hash-sigs says:

      digestAlgorithm MUST contain the one-way hash function used to in

         the HSS/LMS tree.

This statement plus the one I quoted from RFC 5652 would imply that the body
digest algorithm must match that of the HSS algorithm.

However, you are correct that the random field added during signing
increases the collision resistance of the signature and so using the same
algorithm to create the message-digest attribute in the signed attributes
would reduce the collision resistance of the system.  If you wanted to allow
a different hash algorithm in the signed attributes message digest, I think
cms-hash-sigs would need to be modified to further specify signed-data
conventions with/without signed attributes, similar to RFC 8419.

Daniel

Jim

_______________________________________________

Spasm mailing list

 <mailto:Spasm@ietf.org> Spasm@ietf.org

 <https://www.ietf.org/mailman/listinfo/spasm>
https://www.ietf.org/mailman/listinfo/spasm