Suggestions for Managing KAT Sizes in FIPS 204 Compliance on Embedded Systems

[Sofia Ramirez]

Hi all, 

For FIPS 204 (level 5) the size of public key, secret key and signature are about 12KB in total. For KAT on a embedded system, it needs to store at lease these amounts as test vectors! 

However, memory resources in embedded system are often limited. Do you have any suggestion or best practices for managing the storage requirements effectively?

Thanks!

Best Regards,

Sofia

[Stephan Mueller]

Am Dienstag, 10. September 2024, 02:50:27 GMT-5 schrieb Sofia Ramirez:

Hi Sofia,

What about using the allowance in FIPS 204 (and 203) to maintain the seed in
lieu of the key pair and regenerate the key from the seed?

Ciao
Stephan

[Scott Fluhrer (sfluhrer)]

And, instead of storing the expected signature for the KAT, would it be sufficient to store the (approved) hash of that signature?

With that and Stephan's suggestion (and with the message being fixed and implicit), it'd be possible to shrink the test vector down to 64 bytes of storage.

> --
> You received this message because you are subscribed to the Google Groups
> "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pqc-forum+...@list.nist.gov.
> To view this discussion on the web visit
> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-
> forum/3368790.JSj4u3h8sb%40tauon.atsec.com.

[Stephan Mueller]

Am Dienstag, 10. September 2024, 07:09:14 GMT-5 schrieb 'Scott Fluhrer
(sfluhrer)' via pqc-forum:

Hi Scott,

> And, instead of storing the expected signature for the KAT, would it be
> sufficient to store the (approved) hash of that signature?

If you speak about the FIPS 140-perspective, storing a hash in lieu of the
signature is appropriate. But from a formal point of view, an approved hash
function (SHA2, SHA3, SHAKE) should be used.

Ciao
Stephan

[Sofia Ramirez]

Hi all, 

Thanks you for the suggestion regarding saving seeds and signature hashes; I think it's a

great idea. However, I have some concern about boot time constraints. Running the entire

process from key generation to verify can be too demanding for my needs.

If I only implement the verification on my machine, are there any alternatives or remedies

available for this approach?

Thanks!

Best regards, 

Sofia

[Bas Westerbaan]

Have you timed key generation? You might be surprised how fast it is compared to traditional cryptography.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0d919c0a-c841-42b6-84cd-42f65193797bn%40list.nist.gov.

[Sofia Ramirez]

Hi Bas,

While the key generation process is fast, the bottleneck lies with the signing function in my case.

If I choose to skip the signing part, I would still need to store the signature for the KAT of verification,

which would nearly double the size of my code size!

Best, 

Sofia