Use precomputed/cached values to speed up operations as in the legacy API #456

New issue

Open

opened 2025-09-14 09:39:04 -05:00 by Emill · 0 comments

Emill commented

2025-09-14 09:39:04 -05:00

(Migrated from github.com)

Suggested enhancement

In the legacy crypto API, e.g. RSA and GCM contexts precalculated values either at initialization or at the first use to speed up operations when the same key is used multiple times.

For RSA, the context value "RN" is calculated once to store R^2 mod N, which is used to convert an integer to its Montgomery form. At every operation, it is not recalculated if it has already been calculated before. So, if you want to verify multiple signatures using the same key or encrypt many values using the same key, you will benefit from this.

For GCM, there is a precomputed table that will be used in the GHASH operation to significantly speed up the operation on platforms that don't have native carry-less multiplication instructions or hw accelerators.

Unfortunately, currently TF-PSA-Crypto creates a new RSA/GCM context at every operation and discards it immediately when a single operation has finished. Hence, the speedups these caching techniques are doing are not working as intended. It seems like the current obstacle holding this back lies in the fact that the buffer allocated for a particular key in a PSA key slot is not bigger than the size of the original key buffer supplied by the user when the key was imported. Hence, it is not possible for an algorithm to store cached precomputations.

Justification

TF-PSA-Crypto needs this because it might be important for performance. It was used in the legacy API and hence it seems no reason not to use the same optimizations in TF-PSA-Crypto library.
In TLS, a new GCM operation is started every time a record is received or sent. Recomputing the whole table all the time seems like wasting CPU cycles.
For the ESP32* family, which has hw accelerator for bignum exponentiation given a precomputed R^2 mod N, the R^2 mod N computation can be quite slow, in some cases even slower than the whole modular exponentiation itself since it has no hardware to perform this precomputation operation.

### Suggested enhancement In the legacy crypto API, e.g. RSA and GCM contexts precalculated values either at initialization or at the first use to speed up operations when the same key is used multiple times. For RSA, the context value "RN" is calculated once to store R^2 mod N, which is used to convert an integer to its Montgomery form. At every operation, it is not recalculated if it has already been calculated before. So, if you want to verify multiple signatures using the same key or encrypt many values using the same key, you will benefit from this. For GCM, there is a precomputed table that will be used in the GHASH operation to significantly speed up the operation on platforms that don't have native carry-less multiplication instructions or hw accelerators. Unfortunately, currently TF-PSA-Crypto creates a new RSA/GCM context at every operation and discards it immediately when a single operation has finished. Hence, the speedups these caching techniques are doing are not working as intended. It seems like the current obstacle holding this back lies in the fact that the buffer allocated for a particular key in a PSA key slot is not bigger than the size of the original key buffer supplied by the user when the key was imported. Hence, it is not possible for an algorithm to store cached precomputations. ### Justification TF-PSA-Crypto needs this because it might be important for performance. It was used in the legacy API and hence it seems no reason not to use the same optimizations in TF-PSA-Crypto library. In TLS, a new GCM operation is started every time a record is received or sent. Recomputing the whole table all the time seems like wasting CPU cycles. For the ESP32* family, which has hw accelerator for bignum exponentiation given a precomputed R^2 mod N, the R^2 mod N computation can be quite slow, in some cases even slower than the whole modular exponentiation itself since it has no hardware to perform this precomputation operation.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#456

No description provided.

Rows
Columns