Thanks Tamas,

Did you try with CC312 disabled as well? I am wondering if you would be able to at least reproduce what I saw.

Ray

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Tamas Ban via TF-M Sent: Thursday, March 19, 2020 4:30 AM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] FW: 2048-bit RSA Keypair generation is slow

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi,

We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang.

But for sure we have not seen any run which could take minutes.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com>; Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow

If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash.

Adrian ________________________________ From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Cc: nd <nd@arm.commailto:nd@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow

Hi Ray,

That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues

Best Regards

Soby Mathew

From: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow

Hi Soby,

Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with.

However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes.

Thanks,

Ray

From: Soby Mathew <Soby.Mathew@arm.commailto:Soby.Mathew@arm.com> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow

Hi Raymond

Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have.

Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto :

#warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! "

This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay.

If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M.

I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source.

Best Regards

Soby Mathew

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] 2048-bit RSA Keypair generation is slow

Hi all,

When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng.

Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation?

Thank you,

Ray

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.