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> 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 <https://www.ietf.org/mailman/listinfo/spasm>