You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: