Lines Matching +full:fail +full:- +full:fast

4 …tography API specification](https://armmbed.github.io/mbed-crypto/psa/#application-programming-int…
8 …S, see our [PSA Cryptoprocessor driver development examples](../psa-driver-example-and-guide.html).
16 …icies, and dispatches cryptographic operations either to the applicable driver or to built-in code.
24 …ivers can also be pure software implementations that are distributed as plug-ins to a PSA Cryptogr…
25 …tc. An opaque driver is invoked for the specific [key location](#lifetimes-and-locations) that the…
29 The present specification was designed to fulfill the following high-level requirements.
35 …erate on keys in cleartext; cryptoprocessors that can wrap keys with a built-in keys but not store…
37 …does not involve any platform-specific consideration. Driver calls are simple C function calls. In…
51 …is JSON file is specified in the section [“Driver description syntax”](#driver-description-syntax).
57 …ow drivers to be provided as source files and compiled with the core instead of being pre-compiled.
59 …de the driver description file, the C header files and the object code is implementation-dependent.
73 #### Driver description top-level element
77 * `"prefix"` (mandatory, string). This must be a valid, non-empty prefix for a C identifier. All th…
79 …rs of the platform. Whether they may include other headers is implementation-specific. If omitted,…
80 * `"capabilities"` (mandatory, array of [capabilities](#driver-description-capability)).
82 …or opaque drivers): information about the [representation of keys](#key-format-for-opaque-drivers).
83 …es of the [persistent state of the driver](#opaque-driver-persistent-state). This may be either a …
84 …-and-locations) for which this driver is invoked. In other words, this determines the lifetimes fo…
94 …t of strings). Each element is the name of a [driver entry point](#driver-entry-points) or driver …
95 …l, list of strings). Each element is an [algorithm specification](#algorithm-specifications). If s…
96 * `"key_types"` (optional, list of strings). Each element is a [key type specification](#key-type-s…
99 …T_SUPPORTED`, in which case the core should call another driver or use built-in code to perform th…
103 …able driver entry points as described in the section [“Driver entry points”](#driver-entry-points).
110 …y's `"algorithms"` property includes an [algorithm specification](#algorithm-specifications) that …
116 …ability's `"key_types"` property includes a [key type specification](#key-type-specifications) tha…
123 …ey size, the first matching driver in the [specification list](#driver-description-list) is invoke…
137 …s that the driver can perform deterministic ECDSA signatures using SHA-256 or SHA-384 with a SECP2…
154 Spaces are optional after commas. Whether other whitespace is permitted is implementation-specific.
194 …try points that involve a multi-part operation, the operation state type (`psa_XXX_operation_t`) i…
203 …#random-generation-entry-points). Separately, transparent and opaque drivers can have [entropy col…
211 * An in-out buffer has the type `uint8_t *` and is immediately followed by a parameter of type `siz…
213 Buffers of size 0 may be represented with either a null pointer or a non-null pointer.
215 …-only parameters (`const` pointers) may be in read-only memory. Overlap is possible between input …
217 #### Driver entry points for single-part cryptographic operations
219 The following driver entry points perform a cryptographic operation in one shot (single-part operat…
236 ### Driver entry points for multi-part operations
238 #### General considerations on multi-part operations
240 …ts that implement each step of a multi-part operation are grouped into a family. A driver that imp…
242 1. The core initializes operation context objects to either all-bits-zero or to logical zero (`{0}`…
248 …ti-part operation but not the corresponding single-part operation, the core calls the driver's mul…
250 #### Multi-part operation entry point family `"hash_multipart"`
262 * `"hash_abort"`: called by all multi-part hash functions of the PSA Cryptography API.
322 …the core calls the secure element driver's [`"export_key"`](#key-management-with-opaque-drivers) e…
323 2. Otherwise ([or on fallback?](#fallback-for-key-derivation-in-opaque-drivers)), if there is a tra…
324 3. Otherwise, or on fallback, the core uses its built-in implementation.
330 …des the [initial inputs](#key-derivation-driver-initial-inputs). See [“Key derivation driver setup…
331 …t have extra inputs. See [“Key derivation driver long inputs”](#key-derivation-driver-long-inputs).
332 …phic material and output it. See [“Key derivation driver outputs”](#key-derivation-driver-outputs).
333 …ide the same secure element. See [“Key derivation driver outputs”](#key-derivation-driver-outputs).
334 …-raw-data key types; ignored for other opaque drivers; not permitted for transparent drivers): upd…
348 typedef ... psa_crypto_driver_key_derivation_inputs_t; // implementation-specific type
351 …ey_derivation_inputs_t` can retrieve its contents by calling one of the type-specific functions be…
373 …ake a copy of the input data (design note: [why a copy?](#key-derivation-inputs-and-buffer-ownersh…
397 The get-data functions take the following parameters:
409 …ror. The driver will receive the input later as a [long input](#key-derivation-driver-long-inputs).
412 …TION_DETECTED` or `PSA_ERROR_COMMUNICATION_FAILURE` to convey implementation-specific error condit…
424 * `operation` is a zero-initialized operation object.
426 * `inputs` is an opaque pointer to the [initial inputs](#key-derivation-driver-initial-inputs) for …
430 … it would not be practical to pass in the [initial inputs](#key-derivation-driver-initial-inputs).…
443 …n: opaque drivers that support [`"key_derivation_output_key"`](#key-derivation-driver-outputs), i.…
497 … to implement a single call from the application when deriving a cooked (non-raw) key as described…
501 …e_key"` entry point. See [“Transparent cooked key derivation”](#transparent-cooked-key-derivation).
506 …-bit key consists of the next *n* bytes of output from the key derivation, and *cooked* otherwise.…
508 …lowing properties (this is not a subset of [the usual entry point properties](#capability-syntax)):
511 …datory, list of strings). Each element is a [key type specification](#key-type-specifications). Th…
528 …the attributes of the specified key. Note that only the key type and the bit-size are guaranteed t…
531 …for the output material, in the appropriate [export format](#key-format-for-transparent-drivers) f…
541 …address may change between calls. Before the first call, `*memory` is initialized to all-bits-zero.
546 …`, `PSA_KEY_TYPE_DH_KEY_PAIR(…)`: $m$ bytes, where the bit-size of the key $n$ satisfies $8 (m-1) …
547 * `PSA_KEY_TYPE_RSA_KEY_PAIR`: an implementation-defined length. A future version of this specifica…
550 See [“Open questions around cooked key derivation”](#open-questions-around-cooked-key-derivation) f…
592 …eeping inputs and core set-data functions do not have driver entry points. Collected inputs are av…
599 - if there is a transparent driver for the specified ciphersuite, the core calls that driver's `"pa…
600 - otherwise, or on fallback, the core uses its built-in implementation.
602 - the core calls the `"pake_setup"` entry point of the secure element driver and subsequent entry p…
624 typedef ... psa_crypto_driver_pake_inputs_t; // implementation-specific type
627 …pto_driver_pake_inputs_t` can retrieve its contents by calling one of the get-data functions below.
663 The get-data functions take the following parameters:
680 * `operation` is a zero-initialized operation object.
681 * `inputs` is an opaque pointer to the [inputs](#pake-driver-inputs) for the PAKE operation.
683 The setup driver function should preserve the inputs using get-data functions.
758 …etween [transparent drivers](#key-management-with-transparent-drivers) and [opaque drivers](#key-m…
775 …-derivation-driver-outputs) and [`"key_agreement_key"`](#key-agreement) entry points. Transparent …
780 … input in the `data` buffer is either the export format or an implementation-specific format that …
781 …-format-for-transparent-drivers). For an opaque driver, this is the size determined from the drive…
783 …escribed in the section [“Key size determination on import”](#key-size-determination-on-import) be…
785 …e resulting key is valid as specified in the section [“Key validation”](#key-validation) below. Th…
793 …f this size is `0`, the `"import_key"` entry point must set the `bits` input-output parameter to t…
797 …alue but returns `PSA_SUCCESS`, the core will consider the key as invalid and the import will fail.
831 * `flags`: a bit-mask of [entropy collection flags](#entropy-collection-flags).
833 * `output`: on success, this buffer contains non-deterministic data with an estimated entropy of at…
849 …KEEPALIVE`: This flag is intended to help with energy management for entropy-generating peripheral…
853 …entropy-collection-flags) is to support drivers for TRNG (True Random Number Generator, i.e. an en…
881 …ed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_key) and [`psa_export_public_k…
887 * [`"import_key"`](#key-import-with-transparent-drivers): called by `psa_import_key()`, only when i…
896 …n [the general section about key management entry points](#driver-entry-points-for-key-management)…
909 …ed in the description of [`psa_import_key()`](https://armmbed.github.io/mbed-crypto/html/api/keys/…
910 …ta. The necessary validation is described in the section [“Key validation”](#key-validation) above.
911 3. [Determine the key size](#key-size-determination-on-import) and output it through `*bits`.
912 …ed.github.io/mbed-crypto/html/api/keys/management.html#c.psa_export_key) or [`psa_export_public_ke…
918 …entropy source must be fed through a CSPRNG (cryptographically secure pseudo-random number generat…
919 … to be fast. (If a device can provide entropy but is slow at generating random data, declare it as…
920 …enerator peripheral can be declared as an [entropy source](#entropy-collection-entry-point) instea…
921 …-deterministic (including its own entropy source). In other words, this interface is suitable both…
928 …ptional): if this function is present, [the core calls it once](#random-generator-initialization) …
929 …-injection). This entry point is optional if the driver is for a peripheral that includes an entro…
930 …he core calls this function whenever it needs to [obtain random data](#the-get_random-entry-point).
932 … bytes of entropy that the core should supply via [`"add_entropy"`](#entropy-injection) when the d…
944 … once after allocating a random generation context. Initially, the context object is all-bits-zero.
946 …context object passed to the first call to `"add_entropy"` or `"get_random"` will be all-bits-zero.
960 …call to the driver's `"init_random"` entry point if one is present, and to all-bits-zero otherwise.
961 * `entropy`: a buffer containing full-entropy data to seed the random generator. “Full-entropy” mea…
975 …ovides guidance on combining one or more [entropy sources](#entropy-collection-entry-point) (each …
977 …he core must apply a mixing algorithm to the output of `"get_entropy"` to obtain full-entropy data.
979 …le mixing scheme based on a pseudorandom function family $(F_k)$ with an $E$-bit output where $E =…
1005 …, the core must have called `"init_random"` if present, and otherwise the context is all-bits zero.
1006 …cess), the first `*output_length` bytes of this buffer contain cryptographic-quality random data. …
1012 * `PSA_SUCCESS`: the `output` buffer contains `*output_length` bytes of cryptographic-quality rando…
1020 …parent driver can declare that it only supports a [capability](#driver-description-capability) par…
1022 …re considers drivers in the order given by the [driver description list](#driver-description-list).
1024 …bled and return `PSA_ERROR_NOT_SUPPORTED`, the core will perform the operation using built-in code.
1025 …value is returned to the application, without attempting to call any other driver or built-in code.
1042 The `"key_context"` property in the [driver description](#driver-description-top-level-element) spe…
1050 …ext for [built-in keys](#built-in-keys). This allows drivers to efficiently represent application …
1100 …a different [location](#lifetimes-and-locations), or [as a fallback for key derivation](#key-deriv…
1105 …called by `psa_copy_key()` when copying a key within the same [location](#lifetimes-and-locations).
1106 …lled by functions that access a key to retrieve information about a [built-in key](#built-in-keys).
1154 * Fail the creation of the key without indicating this to the driver. This can happen, in particula…
1159 …er but are part of the key namespace for different clients is implementation-dependent and is not …
1186 If the driver has an [`"allocate_key"` entry point](#key-management-in-a-secure-element-with-storag…
1209 …ds to have an adequate size; see [“Key format for opaque drivers”](#key-format-for-opaque-drivers).
1215 …ersistent_state_size"` property in the [driver description](#driver-description-top-level-element).
1217 …tent state in memory before it calls the driver's [init entry point](#driver-initialization). It i…
1219 * The first time the driver is loaded on a system, the persistent state is all-bits-zero.
1220 …s smaller than the declared size, the core pads the persistent state with all-bits-zero at the end.
1237 #### Built-in keys
1239 Opaque drivers may declare built-in keys. Built-in keys can be accessed, but not created, through t…
1241 A built-in key is identified by its location and its **slot number**. Drivers that support built-in…
1255 …ze` bytes. If the driver has a [`"builtin_key_size"` property](#key-format-for-opaque-drivers) pro…
1257 …-in key, the key context is a reference to key material that is kept inside the secure element, si…
1266 … destroy a built-in key to the [`"destroy_key"`](#key-management-in-a-secure-element-with-storage)…
1276 Each opaque driver is assigned a [location](#lifetimes-and-locations). The driver is invoked for al…
1278 For example, the following snippet creates an AES-GCM key which is only accessible inside the secur…
1296 …-crypto/html/api/keys/attributes.html?highlight=psa_key_lifetime_t#c.psa_key_lifetime_t) as an att…
1305 …-time constant for each opaque driver indicating its location called `PSA_KEY_LOCATION_`*prefix* w…
1330 …ntegers (which could be e.g. a macro defined in some header file)? C compile-time constants (allow…
1345 It should be ok for driver functions to be function-like macros or function pointers.
1365 Should 0-size buffers be guaranteed to have a non-null pointers?
1398 …_key"` property. Is this good enough or should the specification include non-functional requiremen…
1406 …or key management”](#driver-entry-points-for-key-management) states that the input to `"import_key…
1408 …e size of the key representation until it knows the bit-size of the key, but determining the bit-s…
1418 …river needs to remember which driver it's calling. This may require a thread-local variable in a m…
1424 …omplex calculation or even on random data, e.g. if doing a randomized pseudo-primality test. Howev…
1428 Should [dispatch to an opaque driver](#key-derivation-driver-dispatch-logic) allow fallback, so tha…
1430 Should the ["`key_derivation_output_key`"](#key-derivation-driver-outputs) capability indicate whic…
1436 Should the input to the [`"add_entropy"` entry point](#entropy-injection) be a full-entropy buffer …
1444 Are the [entropy collection flags](#entropy-collection-flags) well-chosen?
1452 <!--
1454 time-stamp-line-limit: 40
1455 time-stamp-start: "Time-stamp: *\""
1456 time-stamp-end: "\""
1457 time-stamp-format: "%04Y/%02m/%02d %02H:%02M:%02S %Z"
1458 time-stamp-time-zone: "GMT"
1460 -->