Lines Matching full:api
12 G4. Have a clean, unified API for Crypto (retire the legacy API).
92 <https://github.com/ARM-software/psa-crypto-api/pull/536> for that).
124 These abstraction layers typically provide, in addition to the API for crypto
140 crypto API.
251 dispatch to PSA, but not the low-level legacy API, for all operations.
254 2. Have users of these algorithms not depend on the legacy API for information
284 ciphers. For example,`ctr_drbg.c` calls the legacy API `mbedtls_aes`.
304 The most satisfying situation here is when we can just use the PSA Crypto API
307 (such as `mbedtls_md_type_t`) in their API and can't assume PSA to be
323 API, or for `MBEDTLS_MD_C && MBEDTLS_SHA256_C` if using the `mbedtls_md` API.
328 available via the legacy API(s) is it using (MD and/or low-level).
370 Migrating away from the legacy API
394 same context type for hashes and HMACs, while the PSA API (rightfully) has
396 type for unauthenticated and AEAD ciphers, which again the PSA API
401 only AEAD) or differs significantly from the existing API (for example,
406 Another possibility is to keep most or all of the existing API for the PK, MD
413 pointers, just call the corresponding PSA API).
421 existing API unchanged. Their might be conflicts between this goal and that of
439 Crypto API.
454 API. (The compatibility implementation of the existing PK, MD, Cipher APIs
476 `mbedtls_ssl_conf_groups()` API, see #4859).
485 API for tests, or manually migrate tests to the PSA Crypto API. Perhaps a