Jim:
1. The X9.42 document is the correct place to put sizing on the UKM
material as it is going to be tied to items such as the hash algorithm being
used. I think this means that that the last sentence in the paragraph (on
pubInfo) should be alted to be
"In CMS, it is provided as a parameter in the UserKeyingMaterial field
(encoded as an OCTET STRING). If provided this pubInfo MUST contain 512
bits."
This is fine with me.
2. The number 512 represents a minimum value which is determined by looking
at the hash function and making sure that a complete buffer has been filled.
Not quite. The SHA-1 algorithm has an internal block size of 512 bits.
So, making the UKM longer than 512 bits does not add any additional entropy.
3. The number 512 is not a maximum number. There is no real limit but 1023
would be the maximum number that could possibly make sense as there is no
additional benifit to filling the buffer more than twice.
There is not any limit. SHA-1 will take arbitrary length inputs. There is
diminishing benifit for values larger than 512 bits.
4. If (sizeof(ZZ) + sizeof(OtherInfo) - sizeof(pubInfo)) % 512 = 256, you
fill out this complete block size with random material. You then fill half
of the next block with random material and half with fixed material. Not
knowing enough about how these things work, is there any true benifit to
make sure that the half of fixed material is really random material? From
your message it would appear that the first fill is the most important
portion and thus the minimum from step 1 is really what ever is needed to
fill out the last block following ZZ.
The SHA-1 block is internal to the SHA-1 algorithm. There is no reason for
us to align with the internal block. We are simply using SHA-1 to mix
entropy from pubInfo into the key value.
Russ