Lines Matching refs:from
36 so that my customers maximally benefit from my hardware.
54 In the long term, all code using cryptography should use PSA interfaces, to benefit from PSA driver…
92 …ffectively brings those modules to a partial use-PSA behavior (benefiting from PSA accelerators wh…
138 (when called from pkparse).
141 * Cipher, generically, selected from ASN.1 or function parameters;
202 …_CRYPTO`. On the other hand, if `mbedtls_rsa_rsassa_pss_sign()` is called from X.509 code, it shou…
239 * When called from `psa_sign_hash` and other PSA functions, it must call the PSA hash accelerator i…
240 * When called from user code, it must call the built-in hash implementation if PSA is not available…
248 This maximally preserves backward compatibility, but then no non-PSA code benefits from PSA acceler…
258 …not `MBEDTLS_SHA256_C` is enabled (which implies that PSA's SHA-256 comes from an accelerator driv…
264 … use cases where calling the server has overhead that negates the savings from using acceleration,…
265 …hen just call `mbedtls_sha256`, it's all there is, and it doesn't matter (from an API perspective)…
273 …(#classification-of-callers), i.e. code that can be called both from legacy code and from PSA code.
312 * It has an extra step of converting from `mbedtls_md_type_t` to `const mbedtls_md_info_t *`.
314 * The md module has some legacy baggage dating from when it was more open, which we don't care abou…
318 * `mbedtls_md_info_t` can become a very thin type. We can't remove the extra function call from the…
324 This section documents things that we chose to temporarily exclude from the scope in the 3.x branch…
354 …e to its smaller block size) and CTR-DRBG directly uses the low-level API from `aes.h`. In all cas…
482 The implementation needs to convert from a legacy type encoding to a PSA encoding.
533 Remove hash names from `mbedtls_md_info_t`. Use a simple switch-case or a separate list to implemen…
535 #### Remove metadata from the info structure