-
Notifications
You must be signed in to change notification settings - Fork 39
Description
Use case: I need to sign a large firmware image file (~300MB) but instead of sending the whole image to the signing facility, I only want to send the (randomized) hash 'Q' to minimize data that needs to be transferred.
hss_generate_signature() takes the message as an input and internally calculates the (randomized) hash of the message, denoted as 'Q' in LM-OTS Signature (Section 4.5 of RFC-8554).
'I', 'q' and 'C' are part of either the signature or the public key so I am assuming that they don't need to be private.
Is this assumption correct?
If yes,
An external system that pre-calculates Q will require I, q, D_MESG, C and message.
- 'I' could be queried from the signing facility which would return the 'I' value of the current LMS tree.
- D_MESG is a well-known constant.
- C is a 16-byte random value. Can it be calculated by an external system through a FIPS approved DRBG?
- 'q' Does this value need to be private? If not, it can be queried from the securely stored state.
If 'I', C and 'q' can be made available to the external system, it could calculate the 'Q' value and submit it to the signing facility.
A new function, called hss_generate_signauture_prehashed() could be added that takes two additional parameters Q and C, and calculates the signature.
Is it possible without breaking security?
What other considerations should I be aware of?