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

That would simplify things, and despite the collision resistance reduction, should be "good enough" against a quantum attacker due to properties of Grover's algorithms like parallallizing poorly. I think we may still mention things like this in the security considerations of the x509-hash-sigs draft despite no longer proposing pre-hashed OIDs.

Daniel

From: housley@vigilsec.com
Sent: March 17, 2019 12:33 AM
To: Daniel.VanGeest@isara.com
Cc: ietf@augustcellars.com; draft-ietf-lamps-cms-hash-sig@ietf.org; 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" <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org> on behalf of ietf@augustcellars.com<mailto: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
Spasm@ietf.org<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm