diff --git a/docs/html/_sources/api/keys/algorithms.rst.txt b/docs/html/_sources/api/keys/algorithms.rst.txt
new file mode 100644
index 0000000..ea18185
--- /dev/null
+++ b/docs/html/_sources/api/keys/algorithms.rst.txt
@@ -0,0 +1,220 @@
+.. _algorithms:
+
+Algorithms
+==========
+
+Algorithm categories
+--------------------
+
+.. macro:: PSA_ALG_NONE
+    :definition: ((psa_algorithm_t)0)
+
+    .. summary::
+        An invalid algorithm identifier value.
+
+    Zero is not the encoding of any algorithm.
+
+.. macro:: PSA_ALG_IS_HASH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a hash algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a hash algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`hash-algorithms` for a list of defined hash algorithms.
+
+.. macro:: PSA_ALG_IS_MAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a MAC algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a MAC algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`mac-algorithms` for a list of defined MAC algorithms.
+
+.. macro:: PSA_ALG_IS_CIPHER
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a symmetric cipher algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a symmetric cipher algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`cipher-algorithms` for a list of defined cipher algorithms.
+
+.. macro:: PSA_ALG_IS_AEAD
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an authenticated encryption with associated data (AEAD) algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an AEAD algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`aead-algorithms` for a list of defined AEAD algorithms.
+
+.. macro:: PSA_ALG_IS_SIGN
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a public-key signature algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a public-key signature algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`sign-algorithms` for a list of defined signature algorithms.
+
+.. macro:: PSA_ALG_IS_ASYMMETRIC_ENCRYPTION
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a public-key encryption algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a public-key encryption algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`asymmetric-encryption-algorithms` for a list of defined asymmetric encryption algorithms.
+
+.. macro:: PSA_ALG_IS_KEY_AGREEMENT
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a key agreement algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a key agreement algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`key-agreement-algorithms` for a list of defined key agreement algorithms.
+
+.. macro:: PSA_ALG_IS_KEY_DERIVATION
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a key derivation algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a key derivation algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See :title:`key-derivation-algorithms` for a list of defined key derivation algorithms.
+
+.. macro:: PSA_ALG_IS_WILDCARD
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm encoding is a wildcard.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a wildcard algorithm encoding.
+
+        ``0`` if ``alg`` is a non-wildcard algorithm encoding that is suitable for an operation.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    Wildcard algorithm values can only be used to set the usage algorithm field in a policy, wildcard values cannot be used to perform an operation.
+
+    See `PSA_ALG_ANY_HASH` for example of how a wildcard algorithm can be used in a key policy.
+
+.. macro:: PSA_ALG_GET_HASH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Get the hash used by a composite algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        The underlying hash algorithm if ``alg`` is a composite algorithm that uses a hash algorithm.
+
+        `PSA_ALG_NONE` if ``alg`` is not a composite algorithm that uses a hash.
+
+    The following composite algorithms require a hash algorithm:
+
+    - `PSA_ALG_ECDSA()`
+    - `PSA_ALG_HKDF()`
+    - `PSA_ALG_HMAC()`
+    - `PSA_ALG_RSA_OAEP()`
+    - `PSA_ALG_IS_RSA_PKCS1V15_SIGN()`
+    - `PSA_ALG_RSA_PSS()`
+    - `PSA_ALG_TLS12_PRF()`
+    - `PSA_ALG_TLS12_PSK_TO_MS()`
+
+Attribute accessors
+-------------------
+
+.. function:: psa_set_key_algorithm
+
+    .. summary::
+        Declare the permitted algorithm policy for a key.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: psa_algorithm_t alg
+        The permitted algorithm policy to write.
+
+    .. return:: void
+
+    The permitted algorithm policy of a key encodes which algorithm or algorithms are permitted to be used with this key. The following algorithm policies are supported:
+
+    * `PSA_ALG_NONE` does not allow any cryptographic operation with the key. The key can still be used for non-cryptographic actions such as exporting, if permitted by the usage flags.
+    * An algorithm value permits this particular algorithm.
+    * An algorithm wildcard built from `PSA_ALG_ANY_HASH` allows the specified signature scheme with any hash algorithm.
+
+    This function overwrites any algorithm policy previously set in ``attributes``.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_algorithm
+
+    .. summary::
+        Retrieve the algorithm policy from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: psa_algorithm_t
+        The algorithm stored in the attribute object.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
diff --git a/docs/html/_sources/api/keys/attributes.rst.txt b/docs/html/_sources/api/keys/attributes.rst.txt
new file mode 100644
index 0000000..1f849cf
--- /dev/null
+++ b/docs/html/_sources/api/keys/attributes.rst.txt
@@ -0,0 +1,237 @@
+.. _key-attributes:
+
+Key attributes
+==============
+
+Attribute types
+---------------
+
+.. typedef:: uint32_t psa_key_lifetime_t
+
+    .. summary::
+        Encoding of key lifetimes.
+
+    The lifetime of a key indicates where it is stored and which application and system actions will create and destroy it.
+
+    Keys with the lifetime `PSA_KEY_LIFETIME_VOLATILE` are automatically destroyed when the application terminates or on a power reset.
+
+    Keys with a lifetime other than `PSA_KEY_LIFETIME_VOLATILE` are said to be *persistent*. Persistent keys are preserved if the application or the system restarts. Persistent keys have a key identifier of type `psa_key_id_t`.
+
+    See :title:`key-locations` for a list of defined key lifetimes.
+
+.. typedef:: uint32_t psa_key_id_t
+
+    .. summary::
+        Key identifier.
+
+    A key identifiers can be a permanent name for a persistent key, or a transient reference to volatile key. The range of identifier values is divided as follows:
+
+    :code:`PSA_KEY_ID_NULL`
+        Reserved as an invalid key identifier.
+    :code:`PSA_KEY_ID_USER_MIN - PSA_KEY_ID_USER_MAX`
+        Applications can freely choose persistent key identifiers in this range.
+    :code:`PSA_KEY_ID_VENDOR_MIN - PSA_KEY_ID_VENDOR_MAX`
+        Implementations can define additional persistent key identifiers in this
+        range, and allocate key identifiers for volatile keys from this range.
+
+    Key identifiers outside these ranges are reserved for future use.
+
+    See also :title:`key-ids`.
+
+.. typedef:: uint16_t psa_key_type_t
+
+    .. summary::
+        Encoding of a key type.
+
+    This is a structured bitfield that identifies the category and type of key. The range of key type values is divided as follows:
+
+    :code:`PSA_KEY_TYPE_NONE == 0`
+        Reserved as an invalid key type.
+    :code:`0x0001 - 0x7fff`
+        Specification-defined key types.
+        Key types defined by this standard always have bit 15 clear.
+        Unallocated key type values in this range are reserved for future use.
+    :code:`0x8000 - 0xffff`
+        Implementation-defined key types.
+        Implementations that define additional key types must use an encoding with bit 15 set.
+        The related support macros will be easier to write if these key encodings also respect the bitwise structure used by standard encodings.
+
+    See :title:`key-types` for a complete list of key types.
+
+.. typedef:: uint32_t psa_key_usage_t
+
+    .. summary::
+        Encoding of permitted usage on a key.
+
+    See :title:`key-usage` for a full list of key usage policies.
+
+.. typedef:: uint32_t psa_algorithm_t
+
+    .. summary::
+        Encoding of a cryptographic algorithm.
+
+    This is a structured bitfield that identifies the category and type of algorithm. The range of algorithm identifier values is divided as follows:
+
+    :code:`0x00000000`
+        Reserved as an invalid algorithm identifier.
+    :code:`0x00000001 - 0x7fffffff`
+        Specification-defined algorithm identifiers.
+        Algorithm identifiers defined by this standard always have bit 31 clear.
+        Unallocated algorithm identifier values in this range are reserved for future use.
+    :code:`0x80000000 - 0xffffffff`
+        Implementation-defined algorithm identifiers.
+        Implementations that define additional algorithms must use an encoding with bit 31 set.
+        The related support macros will be easier to write if these algorithm identifier encodings also respect the bitwise structure used by standard encodings.
+
+    For algorithms that can be applied to multiple key types, this identifier does not encode the key type. For example, for symmetric ciphers based on a block cipher, `psa_algorithm_t` encodes the block cipher mode and the padding mode while the block cipher itself is encoded via `psa_key_type_t`.
+
+    See :title:`algorithms` for a full list of algorithm identifiers.
+
+Managing attributes
+-------------------
+
+.. typedef:: /* implementation-defined type */ psa_key_attributes_t
+
+    .. summary::
+        The type of an object containing key attributes.
+
+    This is the object that represents the metadata of a key object. Metadata that can be stored in attributes includes:
+
+    * The location of the key in storage, indicated by its key identifier and its lifetime.
+    * The key's policy, comprising usage flags and a specification of the permitted algorithm(s).
+    * Information about the key itself: the key type and its size.
+    * Implementations can define additional attributes.
+
+    The actual key material is not considered an attribute of a key. Key attributes do not contain information that is generally considered highly confidential.
+
+    .. note::
+        Implementations are recommended to define the attribute object as a simple data structure, with fields corresponding to the individual key attributes. In such an implementation, each function ``psa_set_key_xxx()`` sets a field and the corresponding function ``psa_get_key_xxx()`` retrieves the value of the field.
+
+        An implementations can report attribute values that are equivalent to the original one, but have a different encoding. For example, an implementation can use a more compact representation for types where many bit-patterns are invalid or not supported, and store all values that it does not support as a special marker value. In such an implementation, after setting an invalid value, the corresponding get function returns an invalid value which might not be the one that was originally stored.
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+    An attribute object can contain references to auxiliary resources, for example pointers to allocated memory or indirect references to pre-calculated values. In order to free such resources, the application must call `psa_reset_key_attributes()`. As an exception, calling `psa_reset_key_attributes()` on an attribute object is optional if the object has only been modified by the following functions since it was initialized or last reset with `psa_reset_key_attributes()`:
+
+    * `psa_set_key_id()`
+    * `psa_set_key_lifetime()`
+    * `psa_set_key_type()`
+    * `psa_set_key_bits()`
+    * `psa_set_key_usage_flags()`
+    * `psa_set_key_algorithm()`
+
+    Before calling any function on a key attribute object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_key_attributes_t attributes;
+          memset(&attributes, 0, sizeof(attributes));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_key_attributes_t attributes;
+
+    * Initialize the object to the initializer `PSA_KEY_ATTRIBUTES_INIT`, for example:
+
+      .. autocode::
+          psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
+
+    * Assign the result of the function `psa_key_attributes_init()` to the object, for example:
+
+      .. autocode::
+          psa_key_attributes_t attributes;
+          attributes = psa_key_attributes_init();
+
+    A freshly initialized attribute object contains the following values:
+
+    .. tabularcolumns:: LL
+
+    ==============  =======
+    Attribute       Value
+    ==============  =======
+    lifetime        `PSA_KEY_LIFETIME_VOLATILE`.
+    key identifier  `PSA_KEY_ID_NULL` - which is not a valid key identifier.
+    type            `PSA_KEY_TYPE_NONE` - meaning that the type is unspecified.
+    key size        ``0`` - meaning that the size is unspecified.
+    usage flags     ``0`` - which allows no usage except exporting a public key.
+    algorithm       `PSA_ALG_NONE` - which does not allow cryptographic usage, but allows exporting.
+    ==============  =======
+
+    .. rubric:: Usage
+
+    A typical sequence to create a key is as follows:
+
+    #. Create and initialize an attribute object.
+    #. If the key is persistent, call `psa_set_key_id()`. Also call `psa_set_key_lifetime()` to place the key in a non-default location.
+    #. Set the key policy with `psa_set_key_usage_flags()` and `psa_set_key_algorithm()`.
+    #. Set the key type with `psa_set_key_type()`. Skip this step if copying an existing key with `psa_copy_key()`.
+    #. When generating a random key with `psa_generate_key()` or deriving a key with `psa_key_derivation_output_key()`, set the desired key size with `psa_set_key_bits()`.
+    #. Call a key creation function: `psa_import_key()`, `psa_generate_key()`, `psa_key_derivation_output_key()` or `psa_copy_key()`. This function reads the attribute object, creates a key with these attributes, and outputs an identifier for the newly created key.
+    #. Optionally call `psa_reset_key_attributes()`, now that the attribute object is no longer needed. Currently this call is not required as the attributes defined in this specification do not require additional resources beyond the object itself.
+
+    A typical sequence to query a key's attributes is as follows:
+
+    #. Call `psa_get_key_attributes()`.
+    #. Call ``psa_get_key_xxx()`` functions to retrieve the required attribute(s).
+    #. Call `psa_reset_key_attributes()` to free any resources that can be used by the attribute object.
+
+    Once a key has been created, it is impossible to change its attributes.
+
+.. macro:: PSA_KEY_ATTRIBUTES_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for a key attribute object of type `psa_key_attributes_t`.
+
+.. function:: psa_key_attributes_init
+
+    .. summary::
+        Return an initial value for a key attribute object.
+
+    .. return:: psa_key_attributes_t
+
+.. function:: psa_get_key_attributes
+
+    .. summary::
+        Retrieve the attributes of a key.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to query.
+    .. param:: psa_key_attributes_t * attributes
+        On entry, ``*attributes`` must be in a valid state. On successful return, it contains the attributes of the key. On failure, it is equivalent to a freshly-initialized attribute object.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function first resets the attribute object as with `psa_reset_key_attributes()`. It then copies the attributes of the given key into the given attribute object.
+
+    .. note::
+        This function clears any previous content from the attribute object and therefore expects it to be in a valid state. In particular, if this function is called on a newly allocated attribute object, the attribute object  must be initialized before calling this function.
+
+    .. note::
+        This function might allocate memory or other resources. Once this function has been called on an attribute object, `psa_reset_key_attributes()` must be called to free these resources.
+
+.. function:: psa_reset_key_attributes
+
+    .. summary::
+        Reset a key attribute object to a freshly initialized state.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to reset.
+
+    .. return:: void
+
+    The attribute object must be initialized as described in the documentation of the type `psa_key_attributes_t` before calling this function. Once the object has been initialized, this function can be called at any time.
+
+    This function frees any auxiliary resources that the object might contain.
diff --git a/docs/html/_sources/api/keys/index.rst.txt b/docs/html/_sources/api/keys/index.rst.txt
new file mode 100644
index 0000000..934dac9
--- /dev/null
+++ b/docs/html/_sources/api/keys/index.rst.txt
@@ -0,0 +1,14 @@
+..  _key-management:
+
+~~~~~~~~~~~~~~~~~~~~~~~~
+Key management reference
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. toctree::
+
+    attributes
+    locations
+    types
+    usage
+    algorithms
+    management
diff --git a/docs/html/_sources/api/keys/locations.rst.txt b/docs/html/_sources/api/keys/locations.rst.txt
new file mode 100644
index 0000000..9f71fef
--- /dev/null
+++ b/docs/html/_sources/api/keys/locations.rst.txt
@@ -0,0 +1,149 @@
+.. _key-locations:
+
+Key locations
+=============
+
+Key lifetimes
+-------------
+
+.. macro:: PSA_KEY_LIFETIME_VOLATILE
+    :definition: ((psa_key_lifetime_t)0x00000000)
+
+    .. summary::
+        A lifetime value that indicates a volatile key.
+
+    A volatile key only exists as long as the identifier to it is not destroyed.
+
+    The key material is guaranteed to be erased on a power reset.
+
+.. macro:: PSA_KEY_LIFETIME_PERSISTENT
+    :definition: ((psa_key_lifetime_t)0x00000001)
+
+    .. summary::
+        The default storage area for persistent keys.
+
+    A persistent key remains in storage until it is explicitly destroyed or until the corresponding storage area is wiped. This specification does not define any mechanism to wipe a storage area. Implementations are permitted to provide their own mechanism, for example, to perform a factory reset, to prepare for device refurbishment, or to uninstall an application.
+
+    This lifetime value is the default storage area for the calling application. Implementations can offer other storage areas designated by other lifetime values as implementation-specific extensions.
+
+.. _key_identifiers:
+
+Key identifiers
+---------------
+
+.. macro:: PSA_KEY_ID_NULL
+    :definition: ((psa_key_id_t)0)
+
+    .. summary::
+        The null key identifier.
+
+    The null key identifier is always invalid, except when used without in a call to `psa_destroy_key()` which will return `PSA_SUCCESS`.
+
+.. macro:: PSA_KEY_ID_USER_MIN
+    :definition: ((psa_key_id_t)0x00000001)
+
+    .. summary::
+        The minimum value for a key identifier chosen by the application.
+
+.. macro:: PSA_KEY_ID_USER_MAX
+    :definition: ((psa_key_id_t)0x3fffffff)
+
+    .. summary::
+        The maximum value for a key identifier chosen by the application.
+
+.. macro:: PSA_KEY_ID_VENDOR_MIN
+    :definition: ((psa_key_id_t)0x40000000)
+
+    .. summary::
+        The minimum value for a key identifier chosen by the implementation.
+
+.. macro:: PSA_KEY_ID_VENDOR_MAX
+    :definition: ((psa_key_id_t)0x7fffffff)
+
+    .. summary::
+        The maximum value for a key identifier chosen by the implementation.
+
+Attribute accessors
+-------------------
+
+.. function:: psa_set_key_lifetime
+
+    .. summary::
+        Set the location of a persistent key.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: psa_key_lifetime_t lifetime
+        The lifetime for the key. If this is `PSA_KEY_LIFETIME_VOLATILE`, the key will be volatile, and the key identifier attribute is reset to `PSA_KEY_ID_NULL`.
+
+    .. return:: void
+
+    To make a key persistent, give it a persistent key identifier by using `psa_set_key_id()`. By default, a key that has a persistent identifier is stored in the default storage area identifier by `PSA_KEY_LIFETIME_PERSISTENT`. Call this function to choose a storage area, or to explicitly declare the key as volatile.
+
+    This function does not access storage, it merely stores the given value in the attribute object. The persistent key will be written to storage when the attribute object is passed to a key creation function such as `psa_import_key()`, `psa_generate_key()`, `psa_key_derivation_output_key()` or `psa_copy_key()`.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_lifetime
+
+    .. summary::
+        Retrieve the lifetime from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: psa_key_lifetime_t
+        The lifetime value stored in the attribute object.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_set_key_id
+
+    .. summary::
+        Declare a key as persistent and set its key identifier.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: psa_key_id_t id
+        The persistent identifier for the key.
+
+    .. return:: void
+
+    If the attribute object currently declares the key as volatile, which is the default lifetime of an attribute object, this function sets the lifetime attribute to `PSA_KEY_LIFETIME_PERSISTENT`.
+
+    This function does not access storage, it merely stores the given value in the attribute object. The persistent key will be written to storage when the attribute object is passed to a key creation function such as `psa_import_key()`, `psa_generate_key()`, `psa_key_derivation_output_key()` or `psa_copy_key()`.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_id
+
+    .. summary::
+        Retrieve the key identifier from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: psa_key_id_t
+        The persistent identifier stored in the attribute object. This value is unspecified if the attribute object declares the key as volatile.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
diff --git a/docs/html/_sources/api/keys/management.rst.txt b/docs/html/_sources/api/keys/management.rst.txt
new file mode 100644
index 0000000..e03e570
--- /dev/null
+++ b/docs/html/_sources/api/keys/management.rst.txt
@@ -0,0 +1,496 @@
+Key management functions
+========================
+
+.. _key-creation:
+
+Key creation
+------------
+
+.. function:: psa_import_key
+
+    .. summary::
+        Import a key in binary format.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The attributes for the new key. The key size is always determined from the ``data`` buffer. If the key size in ``attributes`` is nonzero, it must be equal to the size from ``data``.
+    .. param:: const uint8_t * data
+        Buffer containing the key data.
+        The content of this buffer is interpreted according to the type declared in ``attributes``.
+        All implementations must support at least the format described in the documentation of `psa_export_key()` or `psa_export_public_key()` for the chosen type.
+        Implementations can support other formats, but be conservative in interpreting the key data: it is recommended that implementations reject content if it might be erroneous, for example, if it is the wrong type or is truncated.
+    .. param:: size_t data_length
+        Size of the ``data`` buffer in bytes.
+    .. param:: psa_key_id_t * key
+        On success, an identifier for the newly created key. `PSA_KEY_ID_NULL` on failure.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success. If the key is persistent, the key material and the key's metadata have been saved to persistent storage.
+    .. retval:: PSA_ERROR_ALREADY_EXISTS
+        This is an attempt to create a persistent key, and there is already a persistent key with the given identifier.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        The key type or key size is not supported, either by the implementation in general or in this particular persistent location.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The key attributes, as a whole, are invalid.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The key data is not correctly formatted.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The size in ``attributes`` is nonzero and does not match the size of the key data.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_INSUFFICIENT_STORAGE
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function supports any output from `psa_export_key()`. Refer to the documentation of `psa_export_public_key()` for the format of public keys and to the documentation of `psa_export_key()` for the format for other key types.
+
+    The key data determines the key size. The attributes can optionally specify a key size; in this case it must match the size determined from the key data. A key size of ``0`` in ``attributes`` indicates that the key size is solely determined by the key data.
+
+    Implementations must reject an attempt to import a key of size ``0``.
+
+    This specification defines a single format for each key type. Implementations can optionally support other formats in addition to the standard format. It is recommended that implementations that support other formats ensure that the formats are clearly unambiguous, to minimize the risk that an invalid input is accidentally interpreted according to a different format.
+
+.. function:: psa_generate_key
+
+    .. summary::
+        Generate a key or key pair.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The attributes for the new key.
+    .. param:: psa_key_id_t * key
+        On success, an identifier for the newly created key. `PSA_KEY_ID_NULL` on failure.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success. If the key is persistent, the key material and the key's metadata have been saved to persistent storage.
+    .. retval:: PSA_ERROR_ALREADY_EXISTS
+        This is an attempt to create a persistent key, and there is already a persistent key with the given identifier.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_STORAGE
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The key is generated randomly. Its location, usage policy, type and size are taken from ``attributes``.
+
+    Implementations must reject an attempt to generate a key of size ``0``.
+
+    The following type-specific considerations apply:
+
+    * For RSA keys (`PSA_KEY_TYPE_RSA_KEY_PAIR`), the public exponent is 65537. The modulus is a product of two probabilistic primes between 2^{n-1} and 2^n where n is the bit size specified in the attributes.
+
+.. function:: psa_copy_key
+
+    .. summary::
+        Make a copy of a key.
+
+    .. param:: psa_key_id_t source_key
+        The key to copy.
+        It must allow the usage `PSA_KEY_USAGE_COPY`.
+        If a private or secret key is being copied outside of a secure element it must also allow `PSA_KEY_USAGE_EXPORT`.
+    .. param:: const psa_key_attributes_t * attributes
+        The attributes for the new key. They are used as follows:
+
+        * The key type and size can be ``0``. If either is nonzero, it must match the corresponding attribute of the source key.
+        * The key location (the lifetime and, for persistent keys, the key identifier) is used directly.
+        * The policy constraints (usage flags and algorithm policy) are combined from the source key and ``attributes`` so that both sets of restrictions apply, as described in the documentation of this function.
+
+    .. param:: psa_key_id_t * target_key
+        On success, an identifier for the newly created key. `PSA_KEY_ID_NULL` on failure.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+        ``source_key`` is invalid.
+    .. retval:: PSA_ERROR_ALREADY_EXISTS
+        This is an attempt to create a persistent key, and there is already a persistent key with the given identifier.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The lifetime or identifier in ``attributes`` are invalid.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The policy constraints on ``source_key`` and specified in ``attributes`` are incompatible.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``attributes`` specifies a key type or key size which does not match the attributes of ``source key``.
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        ``source_key`` does not have the `PSA_KEY_USAGE_COPY` usage flag.
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        ``source_key`` does not have the `PSA_KEY_USAGE_EXPORT` usage flag and its lifetime does not allow copying it to the target's lifetime.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_INSUFFICIENT_STORAGE
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Copy key material from one location to another.
+
+    This function is primarily useful to copy a key from one location to another, as it populates a key using the material from another key which can have a different lifetime.
+
+    This function can be used to share a key with a different party, subject to implementation-defined restrictions on key sharing.
+
+    The policy on the source key must have the usage flag `PSA_KEY_USAGE_COPY` set. This flag is sufficient to permit the copy if the key has the lifetime `PSA_KEY_LIFETIME_VOLATILE` or `PSA_KEY_LIFETIME_PERSISTENT`. Some secure elements do not provide a way to copy a key without making it extractable from the secure element. If a key is located in such a secure element, then the key must have both usage flags `PSA_KEY_USAGE_COPY` and `PSA_KEY_USAGE_EXPORT` in order to make a copy of the key outside the secure element.
+
+    The resulting key can only be used in a way that conforms to both the policy of the original key and the policy specified in the ``attributes`` parameter:
+
+    * The usage flags on the resulting key are the bitwise-and of the usage flags on the source policy and the usage flags in ``attributes``.
+    * If both allow the same algorithm or wildcard-based algorithm policy, the resulting key has the same algorithm policy.
+    * If either of the policies allows an algorithm and the other policy allows a wildcard-based algorithm policy that includes this algorithm, the resulting key allows the same algorithm.
+    * If the policies do not allow any algorithm in common, this function fails with the status `PSA_ERROR_INVALID_ARGUMENT`.
+
+    The effect of this function on implementation-defined attributes is implementation-defined.
+
+
+.. _key-destruction:
+
+Key destruction
+---------------
+
+.. function:: psa_destroy_key
+
+    .. summary::
+        Destroy a key.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to erase.
+        If this is `PSA_KEY_ID_NULL`, do nothing and return `PSA_SUCCESS`.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        ``key`` was a valid key identifier and the key material that it referred to has been erased.
+        Alternatively, ``key`` is `PSA_KEY_ID_NULL`.
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key cannot be erased because it is read-only, either due to a policy or due to physical restrictions.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+        ``key`` is not a valid handle nor `PSA_KEY_ID_NULL`.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+        There was an failure in communication with the cryptoprocessor. The key material might still be present in the cryptoprocessor.
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+        The storage operation failed. Implementations must make a best effort to erase key material even in this situation, however, it might be impossible to guarantee that the key material is not recoverable in such cases.
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+        The storage is corrupted. Implementations must make a best effort to erase key material even in this situation, however, it might be impossible to guarantee that the key material is not recoverable in such cases.
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+        An unexpected condition which is not a storage corruption or a communication failure occurred. The cryptoprocessor might have been compromised.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function destroys a key from both volatile memory and, if applicable, non-volatile storage. Implementations must make a best effort to ensure that that the key material cannot be recovered.
+
+    This function also erases any metadata such as policies and frees resources associated with the key.
+
+    Destroying the key makes the key identifier invalid, and the key identifier must not be used again by the application.
+
+    If a key is currently in use in a multi-part operation, then destroying the key will cause the multi-part operation to fail.
+
+.. function:: psa_purge_key
+
+    .. summary::
+        Remove non-essential copies of key material from memory.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to purge.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The key material will have been removed from memory if it is not currently required.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    An implementation is permitted to make additional copies of key material
+    For keys that have been created with the `PSA_KEY_USAGE_CACHE` policy, an implementation is permitted to make additional copies of the key material that are not in storage and not for the purpose of ongoing operations.
+
+    This function will remove these extra copies of the key material from memory.
+
+    This function is not required to remove key material from memory in any of the following situations:
+
+    - The key is currently in use in a cryptographic operation.
+    - The key is volatile.
+
+    See also :title:`key-material`.
+
+
+.. _key-export:
+
+Key export
+----------
+
+.. function:: psa_export_key
+
+    .. summary::
+        Export a key in binary format.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to export.
+        It must allow the usage `PSA_KEY_USAGE_EXPORT`, unless it is a public key.
+    .. param:: uint8_t * data
+        Buffer where the key data is to be written.
+    .. param:: size_t data_size
+        Size of the ``data`` buffer in bytes.
+        This must be appropriate for the key:
+
+        * The required output size is :code:`PSA_EXPORT_KEY_OUTPUT_SIZE(type, bits)` where ``type`` is the key type and ``bits`` is the key size in bits.
+        * For asymmetric keys, `PSA_EXPORT_KEY_PAIR_MAX_SIZE` evaluates to the maximum output size of any supported public key or key pair.
+
+    .. param:: size_t * data_length
+        On success, the number of bytes that make up the key data.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_EXPORT` flag.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``data`` buffer is too small.
+        `PSA_EXPORT_KEY_OUTPUT_SIZE()` or `PSA_EXPORT_KEY_PAIR_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The output of this function can be passed to `psa_import_key()` to create an equivalent object.
+
+    If the implementation of `psa_import_key()` supports other formats beyond the format specified here, the output from `psa_export_key()` must use the representation specified here, not the original representation.
+
+    For standard key types, the output format is as follows:
+
+    * For symmetric keys, including MAC keys, the format is the raw bytes of the key.
+
+    * For DES, the key data consists of 8 bytes. The parity bits must be correct.
+
+    * For Triple-DES, the format is the concatenation of the two or three DES keys.
+
+    * For RSA key pairs, with key type `PSA_KEY_TYPE_RSA_KEY_PAIR`, the format is the non-encrypted DER encoding of the representation defined by PKCS#1 in :RFC:`8017` as ``RSAPrivateKey``, version ``0``.
+
+      .. code:: none
+
+          RSAPrivateKey ::= SEQUENCE {
+              version             INTEGER,  -- must be 0
+              modulus             INTEGER,  -- n
+              publicExponent      INTEGER,  -- e
+              privateExponent     INTEGER,  -- d
+              prime1              INTEGER,  -- p
+              prime2              INTEGER,  -- q
+              exponent1           INTEGER,  -- d mod (p-1)
+              exponent2           INTEGER,  -- d mod (q-1)
+              coefficient         INTEGER,  -- (inverse of q) mod p
+          }
+
+    * For elliptic curve key pairs, with key types for which `PSA_KEY_TYPE_IS_ECC_KEY_PAIR()` is true, the format is a representation of the private value.
+
+      - For Weierstrass curve families ``PSA_ECC_FAMILY_SECT_XX``, ``PSA_ECC_FAMILY_SECP_XX``, `PSA_ECC_FAMILY_FRP` and `PSA_ECC_FAMILY_BRAINPOOL_P_R1`, the content of the ``privateKey`` field of the ``ECPrivateKey`` format defined by :RFC:`5915`. This is a ``ceiling(m/8)``-byte string in big-endian order where ``m`` is the key size in bits.
+
+      - For curve family `PSA_ECC_FAMILY_MONTGOMERY`, the scalar value of the 'private key' in little-endian order as defined by :RFC:`7748#6`. This is a ``ceiling(m/8)``-byte string where ``m`` is the key size in bits. This is 32 bytes for Curve25519, and 56 bytes for Curve448.
+
+    * For Diffie-Hellman key exchange key pairs, with key types for which `PSA_KEY_TYPE_IS_DH_KEY_PAIR()` is true, the format is the representation of the private key ``x`` as a big-endian byte string. The length of the byte string is the private key size in bytes, and leading zeroes are not stripped.
+
+    * For public keys, with key types for which `PSA_KEY_TYPE_IS_PUBLIC_KEY()` is true, the format is the same as for `psa_export_public_key()`.
+
+    The policy on the key must have the usage flag `PSA_KEY_USAGE_EXPORT` set.
+
+.. function:: psa_export_public_key
+
+    .. summary::
+        Export a public key or the public part of a key pair in binary format.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to export.
+    .. param:: uint8_t * data
+        Buffer where the key data is to be written.
+    .. param:: size_t data_size
+        Size of the ``data`` buffer in bytes.
+        This must be appropriate for the key:
+
+        * The required output size is :code:`PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE(type, bits)` where ``type`` is the key type and ``bits`` is the key size in bits.
+        * `PSA_EXPORT_PUBLIC_KEY_MAX_SIZE` evaluates to the maximum output size of any supported public key or public part of a key pair.
+
+    .. param:: size_t * data_length
+        On success, the number of bytes that make up the key data.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The key is neither a public key nor a key pair.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``data`` buffer is too small.
+        `PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE()` or `PSA_EXPORT_PUBLIC_KEY_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The output of this function can be passed to `psa_import_key()` to create an object that is equivalent to the public key.
+
+    If the implementation of `psa_import_key()` supports other formats beyond the format specified here, the output from `psa_export_public_key()` must use the representation specified here, not the original representation.
+
+    For standard key types, the output format is as follows:
+
+    * For RSA public keys, with key type `PSA_KEY_TYPE_RSA_PUBLIC_KEY`, the DER encoding of the representation defined by :RFC:`3279#2.3.1` as ``RSAPublicKey``.
+
+      .. code:: none
+
+          RSAPublicKey ::= SEQUENCE {
+             modulus            INTEGER,    -- n
+             publicExponent     INTEGER  }  -- e
+
+    * For elliptic curve key pairs, with key types for which `PSA_KEY_TYPE_IS_ECC_PUBLIC_KEY()` is true, the format depends on the key family:
+
+      - For Weierstrass curve families ``PSA_ECC_FAMILY_SECT_XX``, ``PSA_ECC_FAMILY_SECP_XX``, `PSA_ECC_FAMILY_FRP` and `PSA_ECC_FAMILY_BRAINPOOL_P_R1`, the uncompressed representation defined by *Standards for Efficient Cryptography*, |SEC1|_ §2.3.3 as the content of an ``ECPoint``. If ``m`` is the bit size associated with the curve, i.e. the bit size of ``q`` for a curve over ``F_q``. The representation consists of:
+
+        * The byte ``0x04``;
+        * ``x_P`` as a ``ceiling(m/8)``-byte string, big-endian;
+        * ``y_P`` as a ``ceiling(m/8)``-byte string, big-endian.
+
+        .. |SEC1| replace:: *SEC 1: Elliptic Curve Cryptography*
+        .. _SEC1: https://www.secg.org/sec1-v2.pdf
+
+      - For curve family `PSA_ECC_FAMILY_MONTGOMERY`, the scalar value of the 'public key' in little-endian order as defined by :RFC:`7748#6`. This is a ``ceiling(m/8)``-byte string where ``m`` is the key size in bits.
+
+        * This is 32 bytes for Curve25519, computed as ``X25519(private_key, 9)``.
+        * This is 56 bytes for Curve448, computed as ``X448(private_key, 5)``.
+
+    * For Diffie-Hellman key exchange public keys, with key types for which `PSA_KEY_TYPE_IS_DH_PUBLIC_KEY` is true, the format is the representation of the public key ``y = g^x mod p`` as a big-endian byte string. The length of the byte string is the length of the base prime ``p`` in bytes.
+
+    Exporting a public key object or the public part of a key pair is always permitted, regardless of the key's usage flags.
+
+.. macro:: PSA_EXPORT_KEY_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient output buffer size for `psa_export_key()`.
+
+    .. param:: key_type
+        A supported key type.
+    .. param:: key_bits
+        The size of the key in bits.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_export_key()` or `psa_export_public_key()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+    This macro returns a compile-time constant if its arguments are compile-time constants.
+
+    .. warning::
+        This function can evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    The following code illustrates how to allocate enough memory to export a key by querying the key type and size at runtime.
+
+    .. autocode::
+
+        psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
+        psa_status_t status;
+        status = psa_get_key_attributes(key, &attributes);
+        if (status != PSA_SUCCESS)
+            handle_error(...);
+        psa_key_type_t key_type = psa_get_key_type(&attributes);
+        size_t key_bits = psa_get_key_bits(&attributes);
+        size_t buffer_size = PSA_EXPORT_KEY_OUTPUT_SIZE(key_type, key_bits);
+        psa_reset_key_attributes(&attributes);
+        uint8_t *buffer = malloc(buffer_size);
+        if (buffer == NULL)
+            handle_error(...);
+        size_t buffer_length;
+        status = psa_export_key(key, buffer, buffer_size, &buffer_length);
+        if (status != PSA_SUCCESS)
+            handle_error(...);
+
+    See also `PSA_EXPORT_KEY_PAIR_MAX_SIZE` and `PSA_EXPORT_PUBLIC_KEY_MAX_SIZE`.
+
+.. macro:: PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient output buffer size for `psa_export_public_key()`.
+
+    .. param:: key_type
+        A public key or key pair key type.
+    .. param:: key_bits
+        The size of the key in bits.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_export_public_key()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+        If the parameters are valid and supported, it is recommended that this macro returns the same result as :code:`PSA_EXPORT_KEY_OUTPUT_SIZE(PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR(key_type), key_bits)`.
+
+    This macro returns a compile-time constant if its arguments are compile-time constants.
+
+    .. warning::
+        This function can evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    The following code illustrates how to allocate enough memory to export a public key by querying the key type and size at runtime.
+
+    .. autocode::
+
+        psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
+        psa_status_t status;
+        status = psa_get_key_attributes(key, &attributes);
+        if (status != PSA_SUCCESS)
+            handle_error(...);
+        psa_key_type_t key_type = psa_get_key_type(&attributes);
+        size_t key_bits = psa_get_key_bits(&attributes);
+        size_t buffer_size = PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE(key_type, key_bits);
+        psa_reset_key_attributes(&attributes);
+        uint8_t *buffer = malloc(buffer_size);
+        if (buffer == NULL)
+            handle_error(...);
+        size_t buffer_length;
+        status = psa_export_public_key(key, buffer, buffer_size, &buffer_length);
+        if (status != PSA_SUCCESS)
+            handle_error(...);
+
+    See also `PSA_EXPORT_PUBLIC_KEY_MAX_SIZE`.
+
+.. macro:: PSA_EXPORT_KEY_PAIR_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient buffer size for exporting any asymmetric key pair.
+
+    This macro must expand to a compile-time constant integer.
+    This value must be a sufficient buffer size when calling `psa_export_key()` to export any asymmetric key pair that is supported by the implementation, regardless of the exact key type and key size.
+
+    See also `PSA_EXPORT_KEY_OUTPUT_SIZE()`.
+
+.. macro:: PSA_EXPORT_PUBLIC_KEY_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient buffer size for exporting any asymmetric public key.
+
+    This macro must expand to a compile-time constant integer.
+    This value must be a sufficient buffer size when calling `psa_export_key()` or `psa_export_public_key()` to export any asymmetric public key that is supported by the implementation, regardless of the exact key type and key size.
+
+    See also `PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE()`.
diff --git a/docs/html/_sources/api/keys/types.rst.txt b/docs/html/_sources/api/keys/types.rst.txt
new file mode 100644
index 0000000..d33b32f
--- /dev/null
+++ b/docs/html/_sources/api/keys/types.rst.txt
@@ -0,0 +1,610 @@
+.. _key-types:
+
+Key types
+=========
+
+Key categories
+--------------
+
+.. macro:: PSA_KEY_TYPE_NONE
+    :definition: ((psa_key_type_t)0x0000)
+
+    .. summary::
+        An invalid key type value.
+
+    Zero is not the encoding of any key type.
+
+.. macro:: PSA_KEY_TYPE_IS_UNSTRUCTURED
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is an unstructured array of bytes.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+    This encompasses both symmetric keys and non-key data.
+
+    See :title:`symmetric-keys` for a list of symmetric key types.
+
+.. macro:: PSA_KEY_TYPE_IS_ASYMMETRIC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is asymmetric: either a key pair or a public key.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+    See :title:`asymmetric-keys` for a list of asymmetric key types.
+
+.. macro:: PSA_KEY_TYPE_IS_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is the public part of a key pair.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_IS_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is a key pair containing a private part and a public part.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+
+.. _symmetric-keys:
+
+Symmetric keys
+--------------
+
+.. macro:: PSA_KEY_TYPE_RAW_DATA
+    :definition: ((psa_key_type_t)0x1001)
+
+    .. summary::
+        Raw data.
+
+    A "key" of this type cannot be used for any cryptographic operation. Applications can use this type to store arbitrary data in the keystore.
+
+.. macro:: PSA_KEY_TYPE_HMAC
+    :definition: ((psa_key_type_t)0x1100)
+
+    .. summary::
+        HMAC key.
+
+    The key policy determines which underlying hash algorithm the key can be used for.
+
+    HMAC keys typically have the same size as the underlying hash. This size can be calculated with :code:`PSA_HASH_LENGTH(alg)` where ``alg`` is the HMAC algorithm or the underlying hash algorithm.
+
+.. macro:: PSA_KEY_TYPE_DERIVE
+    :definition: ((psa_key_type_t)0x1200)
+
+    .. summary::
+        A secret for key derivation.
+
+    The key policy determines which key derivation algorithm the key can be used for.
+
+.. macro:: PSA_KEY_TYPE_AES
+    :definition: ((psa_key_type_t)0x2400)
+
+    .. summary::
+        Key for a cipher, AEAD or MAC algorithm based on the AES block cipher.
+
+    The size of the key can be 16 bytes (AES-128), 24 bytes (AES-192) or 32 bytes (AES-256).
+
+.. macro:: PSA_KEY_TYPE_DES
+    :definition: ((psa_key_type_t)0x2301)
+
+    .. summary::
+        Key for a cipher or MAC algorithm based on DES or 3DES (Triple-DES).
+
+    The size of the key can be 8 bytes (single DES), 16 bytes (2-key 3DES) or 24 bytes (3-key 3DES).
+
+    .. warning::
+        Single DES and 2-key 3DES are weak and strongly deprecated and are only recommended for decrypting legacy data.
+
+        3-key 3DES is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_KEY_TYPE_CAMELLIA
+    :definition: ((psa_key_type_t)0x2403)
+
+    .. summary::
+        Key for a cipher, AEAD or MAC algorithm based on the Camellia block cipher.
+
+.. macro:: PSA_KEY_TYPE_ARC4
+    :definition: ((psa_key_type_t)0x2002)
+
+    .. summary::
+        Key for the RC4 stream cipher.
+
+    Use algorithm `PSA_ALG_STREAM_CIPHER` to use this key with the ARC4 cipher.
+
+    .. warning::
+        The RC4 cipher is weak and deprecated and is only recommended for use in legacy protocols.
+
+    The ARC4 cipher does not use an initialization vector (IV). When using a multi-part cipher operation with the `PSA_ALG_STREAM_CIPHER` algorithm and an ARC4 key, `psa_cipher_generate_iv()` and `psa_cipher_set_iv()` must not be called.
+
+.. macro:: PSA_KEY_TYPE_CHACHA20
+    :definition: ((psa_key_type_t)0x2004)
+
+    .. summary::
+        Key for the ChaCha20 stream cipher or the Chacha20-Poly1305 AEAD algorithm.
+
+    ChaCha20 and the ChaCha20_Poly1305 construction are defined in :RFC:`7539`.
+
+    Variants of these algorithms are defined by the length of the nonce:
+
+    - Implementations must support a 12-byte nonce, as defined in :RFC:`7539`.
+    - Implementations can optionally support an 8-byte nonce, the original variant.
+    - It is recommended that implementations do not support other sizes of nonce.
+
+    Use algorithm `PSA_ALG_STREAM_CIPHER` to use this key with the ChaCha20 cipher for unauthenticated encryption.
+
+
+.. _asymmetric-keys:
+
+RSA keys
+--------
+
+.. macro:: PSA_KEY_TYPE_RSA_PUBLIC_KEY
+    :definition: ((psa_key_type_t)0x4001)
+
+    .. summary::
+        RSA public key.
+
+.. macro:: PSA_KEY_TYPE_RSA_KEY_PAIR
+    :definition: ((psa_key_type_t)0x7001)
+
+    .. summary::
+        RSA key pair: both the private and public key.
+
+.. macro:: PSA_KEY_TYPE_IS_RSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is an RSA key. This includes both key pairs and public keys.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+Elliptic Curve keys
+-------------------
+
+.. typedef:: uint8_t psa_ecc_family_t
+
+    .. summary::
+        The type of PSA elliptic curve family identifiers.
+
+    The curve identifier is required to create an ECC key using the `PSA_KEY_TYPE_ECC_KEY_PAIR()` or `PSA_KEY_TYPE_ECC_PUBLIC_KEY()` macros.
+
+    The specific ECC curve within a family is identified by the ``key_bits`` attribute of the key.
+
+    The range of Elliptic curve family identifier values is divided as follows:
+
+    :code:`0x00 - 0x7f`
+        ECC family identifiers defined by this standard.
+        Unallocated values in this range are reserved for future use.
+    :code:`0x80 - 0xff`
+        Implementations that define additional families must use an encoding in this range.
+
+.. macro:: PSA_KEY_TYPE_ECC_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Elliptic curve key pair: both the private and public key.
+
+    .. param:: curve
+        A value of type `psa_ecc_family_t` that identifies the ECC curve family to be used.
+
+.. macro:: PSA_KEY_TYPE_ECC_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Elliptic curve public key.
+
+    .. param:: curve
+        A value of type `psa_ecc_family_t` that identifies the ECC curve family to be used.
+
+
+.. macro:: PSA_ECC_FAMILY_SECP_K1
+    :definition: ((psa_ecc_family_t) 0x17)
+
+    .. summary::
+        SEC Koblitz curves over prime fields.
+
+    This family comprises the following curves:
+
+    - secp192k1 : ``key_bits = 192``
+    - secp224k1 : ``key_bits = 225``
+    - secp256k1 : ``key_bits = 256``
+
+    They are defined in *Standards for Efficient Cryptography*, |SEC2|_.
+
+    .. |SEC2| replace:: *SEC 2: Recommended Elliptic Curve Domain Parameters*
+    .. _SEC2: https://www.secg.org/sec2-v2.pdf
+
+.. macro:: PSA_ECC_FAMILY_SECP_R1
+    :definition: ((psa_ecc_family_t) 0x12)
+
+    .. summary::
+        SEC random curves over prime fields.
+
+    This family comprises the following curves:
+
+    - secp192r1 : ``key_bits = 192``
+    - secp224r1 : ``key_bits = 224``
+    - secp256r1 : ``key_bits = 256``
+    - secp384r1 : ``key_bits = 384``
+    - secp521r1 : ``key_bits = 512``
+
+    They are defined in *Standards for Efficient Cryptography*, |SEC2|_
+
+.. macro:: PSA_ECC_FAMILY_SECP_R2
+    :definition: ((psa_ecc_family_t) 0x1b)
+
+    .. summary::
+        .. warning::
+            This family of curves is weak and deprecated.
+
+    This family comprises the following curves:
+
+    - secp160r2 : ``key_bits = 160`` *(Deprecated)*
+
+    It is defined in the superseded |SEC2v1|_.
+
+    .. |SEC2v1| replace:: *SEC 2: Recommended Elliptic Curve Domain Parameters, Version 1.0*
+    .. _SEC2v1: https://www.secg.org/SEC2-Ver-1.0.pdf
+
+.. macro:: PSA_ECC_FAMILY_SECT_K1
+    :definition: ((psa_ecc_family_t) 0x27)
+
+    .. summary::
+        SEC Koblitz curves over binary fields.
+
+    This family comprises the following curves:
+
+    - sect163k1 : ``key_bits = 163`` *(Deprecated)*
+    - sect233k1 : ``key_bits = 233``
+    - sect239k1 : ``key_bits = 239``
+    - sect283k1 : ``key_bits = 283``
+    - sect409k1 : ``key_bits = 409``
+    - sect571k1 : ``key_bits = 571``
+
+    They are defined in *Standards for Efficient Cryptography*, |SEC2|_
+
+    .. warning::
+        The 163-bit curve sect163k1 is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ECC_FAMILY_SECT_R1
+    :definition: ((psa_ecc_family_t) 0x22)
+
+    .. summary::
+        SEC random curves over binary fields.
+
+    This family comprises the following curves:
+
+    - sect163r1 : ``key_bits = 163`` *(Deprecated)*
+    - sect233r1 : ``key_bits = 233``
+    - sect283r1 : ``key_bits = 283``
+    - sect409r1 : ``key_bits = 409``
+    - sect571r1 : ``key_bits = 571``
+
+    They are defined in *Standards for Efficient Cryptography*, |SEC2|_
+
+    .. warning::
+        The 163-bit curve sect163r1 is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ECC_FAMILY_SECT_R2
+    :definition: ((psa_ecc_family_t) 0x2b)
+
+    .. summary::
+        SEC additional random curves over binary fields.
+
+    This family comprises the following curves:
+
+    - sect163r2 : ``key_bits = 163`` *(Deprecated)*
+
+    It is defined in *Standards for Efficient Cryptography*, |SEC2|_
+
+    .. warning::
+        The 163-bit curve sect163r2 is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ECC_FAMILY_BRAINPOOL_P_R1
+    :definition: ((psa_ecc_family_t) 0x30)
+
+    .. summary::
+        Brainpool P random curves.
+
+    This family comprises the following curves:
+
+    - brainpoolP160r1 : ``key_bits = 160`` *(Deprecated)*
+    - brainpoolP192r1 : ``key_bits = 192``
+    - brainpoolP224r1 : ``key_bits = 224``
+    - brainpoolP256r1 : ``key_bits = 256``
+    - brainpoolP320r1 : ``key_bits = 320``
+    - brainpoolP384r1 : ``key_bits = 384``
+    - brainpoolP512r1 : ``key_bits = 512``
+
+    They are defined in :rfc:`5639`.
+
+    .. warning::
+        The 160-bit curve brainpoolP160r1 is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ECC_FAMILY_FRP
+    :definition: ((psa_ecc_family_t) 0x33)
+
+    .. summary::
+        Curve used primarily in France and elsewhere in Europe.
+
+    This family comprises one 256-bit curve:
+
+    - FRP256v1 : ``key_bits = 256``
+
+    This is defined by *Agence nationale de la sécurité des systèmes d'information* in |FRP|_, 21 November 2011.
+
+    .. |FRP| replace:: *Publication d'un paramétrage de courbe elliptique visant des applications de passeport électronique et de l'administration électronique française*
+    .. _FRP: https://www.ssi.gouv.fr/agence/publication/publication-dun-parametrage-de-courbe-elliptique-visant-des-applications-de-passeport-electronique-et-de-ladministration-electronique-francaise/
+
+.. macro:: PSA_ECC_FAMILY_MONTGOMERY
+    :definition: ((psa_ecc_family_t) 0x41)
+
+    .. summary::
+        Montgomery curves.
+
+    This family comprises the following Montgomery curves:
+
+    - Curve25519 : ``key_bits = 255``
+
+      This curve is defined in Bernstein et al., |Curve25519|_, LNCS 3958, 2006.
+
+      .. |Curve25519| replace:: *Curve25519: new Diffie-Hellman speed records*
+      .. _Curve25519: https://www.iacr.org/archive/pkc2006/39580209/39580209.pdf
+
+      The algorithm `PSA_ALG_ECDH` performs X25519 when used with this curve.
+
+    - Curve448 : ``key_bits = 448``
+
+      This curve is defined in Hamburg, |Ed448|_, NIST ECC Workshop, 2015.
+
+      .. |Ed448| replace:: *Ed448-Goldilocks, a new elliptic curve*
+      .. _Ed448: https://eprint.iacr.org/2015/625.pdf
+
+      The algorithm `PSA_ALG_ECDH` performs X448 when used with this curve.
+
+.. macro:: PSA_KEY_TYPE_IS_ECC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is an elliptic curve key, either a key pair or a public key.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_IS_ECC_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is an elliptic curve key pair.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_IS_ECC_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is an elliptic curve public key.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_ECC_GET_FAMILY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Extract the curve family from an elliptic curve key type.
+
+    .. param:: type
+        An elliptic curve key type (value of type `psa_key_type_t` such that :code:`PSA_KEY_TYPE_IS_ECC(type)` is true).
+
+    .. return:: psa_ecc_family_t
+        The elliptic curve family id, if ``type`` is a supported elliptic curve key. Unspecified if ``type`` is not a supported elliptic curve key.
+
+Diffie Hellman keys
+-------------------
+
+.. typedef:: uint8_t psa_dh_family_t
+
+    .. summary::
+        The type of PSA Diffie-Hellman group family identifiers.
+
+    The group family identifier is required to create an Diffie-Hellman key using the `PSA_KEY_TYPE_DH_KEY_PAIR()` or `PSA_KEY_TYPE_DH_PUBLIC_KEY()` macros.
+
+    The specific Diffie-Hellman group within a family is identified by the ``key_bits`` attribute of the key.
+
+    The range of Diffie-Hellman group family identifier values is divided as follows:
+
+    :code:`0x00 - 0x7f`
+        DH group family identifiers defined by this standard.
+        Unallocated values in this range are reserved for future use.
+    :code:`0x80 - 0xff`
+        Implementations that define additional families must use an encoding in this range.
+
+.. macro:: PSA_KEY_TYPE_DH_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Diffie-Hellman key pair: both the private key and public key.
+
+    .. param:: group
+        A value of type `psa_dh_family_t` that identifies the Diffie-Hellman group family to be used.
+
+.. macro:: PSA_KEY_TYPE_DH_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Diffie-Hellman public key.
+
+    .. param:: group
+        A value of type `psa_dh_family_t` that identifies the Diffie-Hellman group family to be used.
+
+.. macro:: PSA_DH_FAMILY_RFC7919
+    :definition: ((psa_dh_family_t) 0x03)
+
+    .. summary::
+        Diffie-Hellman groups defined in :rfc:`7919#A`.
+
+    This family includes groups with the following key sizes (in bits): 2048, 3072, 4096, 6144, 8192.
+    An implementation can support all of these sizes or only a subset.
+
+.. macro:: PSA_KEY_TYPE_KEY_PAIR_OF_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        The key pair type corresponding to a public key type.
+
+    .. param:: type
+        A public key type or key pair type.
+
+    .. return::
+        The corresponding key pair type. If ``type`` is not a public key or a key pair, the return value is undefined.
+
+    If ``type`` is a key pair type, it will be left unchanged.
+
+.. macro:: PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        The public key type corresponding to a key pair type.
+
+    .. param:: type
+        A public key type or key pair type.
+
+    .. return::
+        The corresponding public key type. If ``type`` is not a public key or a key pair, the return value is undefined.
+
+    If ``type`` is a public key type, it will be left unchanged.
+
+.. macro:: PSA_KEY_TYPE_IS_DH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is a Diffie-Hellman key, either a key pair or a public key.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_IS_DH_KEY_PAIR
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is a Diffie-Hellman key pair.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_IS_DH_PUBLIC_KEY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether a key type is a Diffie-Hellman public key.
+
+    .. param:: type
+        A key type (value of type `psa_key_type_t`).
+
+.. macro:: PSA_KEY_TYPE_DH_GET_FAMILY
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Extract the group family from a Diffie-Hellman key type.
+
+    .. param:: type
+        A Diffie-Hellman key type (value of type `psa_key_type_t` such that :code:`PSA_KEY_TYPE_IS_DH(type)` is true).
+
+    .. return:: psa_dh_family_t
+        The Diffie-Hellman group family id, if ``type`` is a supported Diffie-Hellman key. Unspecified if ``type`` is not a supported Diffie-Hellman key.
+
+Attribute accessors
+-------------------
+
+.. function:: psa_set_key_type
+
+    .. summary::
+        Declare the type of a key.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: psa_key_type_t type
+        The key type to write. If this is `PSA_KEY_TYPE_NONE`, the key type in ``attributes`` becomes unspecified.
+
+    .. return:: void
+
+    This function overwrites any key type previously set in ``attributes``.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_type
+
+    .. summary::
+        Retrieve the key type from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: psa_key_type_t
+        The key type stored in the attribute object.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_bits
+
+    .. summary::
+        Retrieve the key size from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: size_t
+        The key size stored in the attribute object, in bits.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_set_key_bits
+
+    .. summary::
+        Declare the size of a key.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: size_t bits
+        The key size in bits. If this is ``0``, the key size in ``attributes`` becomes unspecified. Keys of size ``0`` are not supported.
+
+    .. return:: void
+
+    This function overwrites any key size previously set in ``attributes``.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
diff --git a/docs/html/_sources/api/keys/usage.rst.txt b/docs/html/_sources/api/keys/usage.rst.txt
new file mode 100644
index 0000000..e41d6ab
--- /dev/null
+++ b/docs/html/_sources/api/keys/usage.rst.txt
@@ -0,0 +1,190 @@
+.. _key-usage:
+
+Key policies
+============
+
+Key usage flags
+---------------
+
+.. macro:: PSA_KEY_USAGE_EXPORT
+    :definition: ((psa_key_usage_t)0x00000001)
+
+    .. summary::
+        Permission to export the key.
+
+    This flag allows the use of `psa_export_key()` to export a key from the cryptoprocessor. A public key or the public part of a key pair can always be exported regardless of the value of this permission flag.
+
+    This flag can also be required to copy a key using `psa_copy_key()` outside of a secure element. See also `PSA_KEY_USAGE_COPY`.
+
+    If a key does not have export permission, implementations must not allow the key to be exported in plain form from the cryptoprocessor, whether through `psa_export_key()` or through a proprietary interface. The key might still be exportable in a wrapped form, i.e. in a form where it is encrypted by another key.
+
+.. macro:: PSA_KEY_USAGE_COPY
+    :definition: ((psa_key_usage_t)0x00000002)
+
+    .. summary::
+        Permission to copy the key.
+
+    This flag allows the use of `psa_copy_key()` to make a copy of the key with the same policy or a more restrictive policy.
+
+    For lifetimes for which the key is located in a secure element which enforce the non-exportability of keys, copying a key outside the secure element also requires the usage flag `PSA_KEY_USAGE_EXPORT`. Copying the key inside the secure element is permitted with just `PSA_KEY_USAGE_COPY` if the secure element supports it. For keys with the lifetime `PSA_KEY_LIFETIME_VOLATILE` or `PSA_KEY_LIFETIME_PERSISTENT`, the usage flag `PSA_KEY_USAGE_COPY` is sufficient to permit the copy.
+
+.. macro:: PSA_KEY_USAGE_CACHE
+    :definition: ((psa_key_usage_t)0x00000004)
+
+    .. summary::
+        Permission for the implementation to cache the key.
+
+    This flag allows the implementation to make additional copies of the key material that are not in storage and not for the purpose of an ongoing operation. Applications can use it as a hint to keep the key around for repeated access.
+
+    An application can request that cached key material is removed from memory by calling `psa_purge_key()`.
+
+    The presence of this key policy when creating a key is a hint:
+
+    - An implementation is not required to cache keys that have this policy.
+    - An implementation must not report an error if it does not cache keys.
+
+    If this key policy is not present, the implementation must ensure key material is removed from memory as soon as it is not required for an operation or for maintenance of a volatile key.
+
+    This flag must be preserved when reading back the attributes for all keys, regardless of key type or implementation behavior.
+
+    See also :title:`key-material`.
+
+.. macro:: PSA_KEY_USAGE_ENCRYPT
+    :definition: ((psa_key_usage_t)0x00000100)
+
+    .. summary::
+        Permission to encrypt a message with the key.
+
+    This flag allows the key to be used for a symmetric encryption operation, for an AEAD encryption-and-authentication operation, or for an asymmetric encryption operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used with the following APIs:
+
+    * `psa_cipher_encrypt()`
+    * `psa_cipher_encrypt_setup()`
+    * `psa_aead_encrypt()`
+    * `psa_aead_encrypt_setup()`
+    * `psa_asymmetric_encrypt()`
+
+    For a key pair, this concerns the public key.
+
+.. macro:: PSA_KEY_USAGE_DECRYPT
+    :definition: ((psa_key_usage_t)0x00000200)
+
+    .. summary::
+        Permission to decrypt a message with the key.
+
+    This flag allows the key to be used for a symmetric decryption operation, for an AEAD decryption-and-verification operation, or for an asymmetric decryption operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used with the following APIs:
+
+    * `psa_cipher_decrypt()`
+    * `psa_cipher_decrypt_setup()`
+    * `psa_aead_decrypt()`
+    * `psa_aead_decrypt_setup()`
+    * `psa_asymmetric_decrypt()`
+
+    For a key pair, this concerns the private key.
+
+.. macro:: PSA_KEY_USAGE_SIGN_MESSAGE
+    :definition: ((psa_key_usage_t)0x00000400)
+
+    .. summary::
+        Permission to sign a message with the key.
+
+    This flag allows the key to be used for a MAC calculation operation or for an asymmetric message signature operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used with the following APIs:
+
+    * `psa_mac_compute()`
+    * `psa_mac_sign_setup()`
+    * `psa_sign_message()`
+
+    For a key pair, this concerns the private key.
+
+.. macro:: PSA_KEY_USAGE_VERIFY_MESSAGE
+    :definition: ((psa_key_usage_t)0x00000800)
+
+    .. summary::
+        Permission to verify a message signature with the key.
+
+    This flag allows the key to be used for a MAC verification operation or for an asymmetric message signature verification operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used with the following APIs:
+
+    * `psa_mac_verify()`
+    * `psa_mac_verify_setup()`
+    * `psa_verify_message()`
+
+    For a key pair, this concerns the public key.
+
+.. macro:: PSA_KEY_USAGE_SIGN_HASH
+    :definition: ((psa_key_usage_t)0x00001000)
+
+    .. summary::
+        Permission to sign a message hash with the key.
+
+    This flag allows the key to be used to sign a message hash as part of an asymmetric signature operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used when calling `psa_sign_hash()`.
+
+    This flag automatically sets `PSA_KEY_USAGE_SIGN_MESSAGE`: if an application sets the flag `PSA_KEY_USAGE_SIGN_HASH` when creating a key, then the key always has the permissions conveyed by `PSA_KEY_USAGE_SIGN_MESSAGE`, and the flag `PSA_KEY_USAGE_SIGN_MESSAGE` will also be present when the application queries the usage policy of the key.
+
+    For a key pair, this concerns the private key.
+
+.. macro:: PSA_KEY_USAGE_VERIFY_HASH
+    :definition: ((psa_key_usage_t)0x00002000)
+
+    .. summary::
+        Permission to verify a message hash with the key.
+
+    This flag allows the key to be used to verify a message hash as part of an asymmetric signature verification operation, if otherwise permitted by the key's type and policy. The flag must be present on keys used when calling `psa_verify_hash()`.
+
+    This flag automatically sets `PSA_KEY_USAGE_VERIFY_MESSAGE`: if an application sets the flag `PSA_KEY_USAGE_VERIFY_HASH` when creating a key, then the key always has the permissions conveyed by `PSA_KEY_USAGE_VERIFY_MESSAGE`, and the flag `PSA_KEY_USAGE_VERIFY_MESSAGE` will also be present when the application queries the usage policy of the key.
+
+    For a key pair, this concerns the public key.
+
+.. macro:: PSA_KEY_USAGE_DERIVE
+    :definition: ((psa_key_usage_t)0x00004000)
+
+    .. summary::
+        Permission to derive other keys from this key.
+
+    This flag allows the key to be used for a key derivation operation or for a key agreement operation, if otherwise permitted by by the key's type and policy. The flag must be present on keys used with the following APIs:
+
+    * `psa_key_derivation_input_key()`
+    * `psa_key_derivation_key_agreement()`
+    * `psa_raw_key_agreement()`
+
+Attribute accessors
+-------------------
+
+.. function:: psa_set_key_usage_flags
+
+    .. summary::
+        Declare usage flags for a key.
+
+    .. param:: psa_key_attributes_t * attributes
+        The attribute object to write to.
+    .. param:: psa_key_usage_t usage_flags
+        The usage flags to write.
+
+    .. return:: void
+
+    Usage flags are part of a key's usage policy. They encode what kind of operations are permitted on the key. For more details, refer to the documentation of the type `psa_key_usage_t`.
+
+    This function overwrites any usage flags previously set in ``attributes``.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
+
+.. function:: psa_get_key_usage_flags
+
+    .. summary::
+        Retrieve the usage flags from key attributes.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The key attribute object to query.
+
+    .. return:: psa_key_usage_t
+        The usage flags stored in the attribute object.
+
+    .. admonition:: Implementation note
+
+        This is a simple accessor function that is not required to validate its inputs. The following approaches can be used to provide an efficient implementation:
+
+        - This function can be declared as ``static`` or ``inline``, instead of using the default external linkage.
+        - This function can be provided as a function-like macro. In this form, the macro must evaluate each of its arguments exactly once, as if it was a function call.
diff --git a/docs/html/_sources/api/library/index.rst.txt b/docs/html/_sources/api/library/index.rst.txt
new file mode 100644
index 0000000..be63207
--- /dev/null
+++ b/docs/html/_sources/api/library/index.rst.txt
@@ -0,0 +1,11 @@
+..  _api-reference:
+..  _library-management:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Library management reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. toctree::
+
+    status
+    library
diff --git a/docs/html/_sources/api/library/library.rst.txt b/docs/html/_sources/api/library/library.rst.txt
new file mode 100644
index 0000000..8956282
--- /dev/null
+++ b/docs/html/_sources/api/library/library.rst.txt
@@ -0,0 +1,46 @@
+PSA Crypto library
+==================
+
+.. _api-version:
+
+API version
+-----------
+
+.. macro:: PSA_CRYPTO_API_VERSION_MAJOR
+    :definition: 1
+
+    .. summary::
+        The major version of this implementation of the PSA Crypto API.
+
+.. macro:: PSA_CRYPTO_API_VERSION_MINOR
+    :definition: 0
+
+    .. summary::
+        The minor version of this implementation of the PSA Crypto API.
+
+.. _library-init:
+
+Library initialization
+----------------------
+
+.. function:: psa_crypto_init
+
+    .. summary::
+        Library initialization.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+
+    Applications must call this function before calling any other function in this module.
+
+    Applications are permitted to call this function more than once. Once a call succeeds, subsequent calls are guaranteed to succeed.
+
+    If the application calls other functions before calling `psa_crypto_init()`, the behavior is undefined. In this situation:
+
+    * Implementations are encouraged to either perform the operation as if the library had been initialized or to return `PSA_ERROR_BAD_STATE` or some other applicable error.
+    * Implementations must not return a success status if the lack of initialization might have security implications, for example due to improper seeding of the random number generator.
diff --git a/docs/html/_sources/api/library/status.rst.txt b/docs/html/_sources/api/library/status.rst.txt
new file mode 100644
index 0000000..4d0c6a1
--- /dev/null
+++ b/docs/html/_sources/api/library/status.rst.txt
@@ -0,0 +1,250 @@
+.. _status-codes:
+
+PSA status codes
+================
+
+Status type
+-----------
+
+.. typedef:: int32_t psa_status_t
+
+    .. summary::
+        Function return status.
+
+    This is either `PSA_SUCCESS`, which is zero, indicating success; or a small negative value indicating that an error occurred. Errors are encoded as one of the ``PSA_ERROR_xxx`` values defined here.
+
+Success codes
+-------------
+
+.. macro:: PSA_SUCCESS
+    :definition: ((psa_status_t)0)
+
+    .. summary::
+        The action was completed successfully.
+
+Error codes
+-----------
+
+.. macro:: PSA_ERROR_GENERIC_ERROR
+    :definition: ((psa_status_t)-132)
+
+    .. summary::
+        An error occurred that does not correspond to any defined failure cause.
+
+    Implementations can use this error code if none of the other standard error codes are applicable.
+
+.. macro:: PSA_ERROR_NOT_SUPPORTED
+    :definition: ((psa_status_t)-134)
+
+    .. summary::
+        The requested operation or a parameter is not supported by this implementation.
+
+    It is recommended that implementations return this error code when an enumeration parameter such as a key type, algorithm, etc. is not recognized. If a combination of parameters is recognized and identified as not valid, return `PSA_ERROR_INVALID_ARGUMENT` instead.
+
+.. macro:: PSA_ERROR_NOT_PERMITTED
+    :definition: ((psa_status_t)-133)
+
+    .. summary::
+        The requested action is denied by a policy.
+
+    It is recommended that implementations return this error code when the parameters are recognized as valid and supported, and a policy explicitly denies the requested operation.
+
+    If a subset of the parameters of a function call identify a forbidden operation, and another subset of the parameters are not valid or not supported, it is unspecified whether the function returns `PSA_ERROR_NOT_PERMITTED`, `PSA_ERROR_NOT_SUPPORTED` or `PSA_ERROR_INVALID_ARGUMENT`.
+
+.. macro:: PSA_ERROR_BUFFER_TOO_SMALL
+    :definition: ((psa_status_t)-138)
+
+    .. summary::
+        An output buffer is too small.
+
+    Applications can call the ``PSA_xxx_SIZE`` macro listed in the function description to determine a sufficient buffer size.
+
+    It is recommended that implementations only return this error code in cases when performing the operation with a larger output buffer would succeed. However, implementations can also return this error if a function has invalid or unsupported parameters in addition to an insufficient output buffer size.
+
+.. macro:: PSA_ERROR_ALREADY_EXISTS
+    :definition: ((psa_status_t)-139)
+
+    .. summary::
+        Asking for an item that already exists.
+
+    It is recommended that implementations return this error code when attempting to write to a location where a key is already present.
+
+.. macro:: PSA_ERROR_DOES_NOT_EXIST
+    :definition: ((psa_status_t)-140)
+
+    .. summary::
+        Asking for an item that doesn't exist.
+
+    It is recommended that implementations return this error code if a requested key does not exist.
+
+.. macro:: PSA_ERROR_BAD_STATE
+    :definition: ((psa_status_t)-137)
+
+    .. summary::
+        The requested action cannot be performed in the current state.
+
+    Multi-part operations return this error when one of the functions is called out of sequence. Refer to the function descriptions for permitted sequencing of functions.
+
+    Implementations must not return this error code to indicate that a key either exists or not, but must instead return `PSA_ERROR_ALREADY_EXISTS` or `PSA_ERROR_DOES_NOT_EXIST` as applicable.
+
+    Implementations must not return this error code to indicate that a key identifier is invalid, but must return `PSA_ERROR_INVALID_HANDLE` instead.
+
+.. macro:: PSA_ERROR_INVALID_ARGUMENT
+    :definition: ((psa_status_t)-135)
+
+    .. summary::
+        The parameters passed to the function are invalid.
+
+    Implementations can return this error any time a parameter or combination of parameters are recognized as invalid.
+
+    Implementations must not return this error code to indicate that a key identifier is invalid, but must return `PSA_ERROR_INVALID_HANDLE` instead.
+
+.. macro:: PSA_ERROR_INSUFFICIENT_MEMORY
+    :definition: ((psa_status_t)-141)
+
+    .. summary::
+        There is not enough runtime memory.
+
+    If the action is carried out across multiple security realms, this error can refer to available memory in any of the security realms.
+
+.. macro:: PSA_ERROR_INSUFFICIENT_STORAGE
+    :definition: ((psa_status_t)-142)
+
+    .. summary::
+        There is not enough persistent storage.
+
+    Functions that modify the key storage return this error code if there is insufficient storage space on the host media. In addition, many functions that do not otherwise access storage might return this error code if the implementation requires a mandatory log entry for the requested action and the log storage space is full.
+
+.. macro:: PSA_ERROR_COMMUNICATION_FAILURE
+    :definition: ((psa_status_t)-145)
+
+    .. summary::
+        There was a communication failure inside the implementation.
+
+    This can indicate a communication failure between the application and an external cryptoprocessor or between the cryptoprocessor and an external volatile or persistent memory. A communication failure can be transient or permanent depending on the cause.
+
+    .. warning::
+        If a function returns this error, it is undetermined whether the requested action has completed. Returning `PSA_SUCCESS` is recommended on successful completion whenever possible, however functions can return `PSA_ERROR_COMMUNICATION_FAILURE` if the requested action was completed successfully in an external cryptoprocessor but there was a breakdown of communication before the cryptoprocessor could report the status to the application.
+
+.. macro:: PSA_ERROR_STORAGE_FAILURE
+    :definition: ((psa_status_t)-146)
+
+    .. summary::
+        There was a storage failure that might have led to data loss.
+
+    This error indicates that some persistent storage could not be read or written by the implementation. It does not indicate the following situations, which have specific error codes:
+
+    * A corruption of volatile memory - use `PSA_ERROR_CORRUPTION_DETECTED`.
+    * A communication error between the cryptoprocessor and its external storage - use `PSA_ERROR_COMMUNICATION_FAILURE`.
+    * When the storage is in a valid state but is full - use `PSA_ERROR_INSUFFICIENT_STORAGE`.
+    * When the storage or stored data is corrupted - use `PSA_ERROR_DATA_CORRUPT`.
+    * When the stored data is not valid - use `PSA_ERROR_DATA_INVALID`.
+
+    A storage failure does not indicate that any data that was previously read is invalid. However this previously read data might no longer be readable from storage.
+
+    When a storage failure occurs, it is no longer possible to ensure the global integrity of the keystore. Depending on the global integrity guarantees offered by the implementation, access to other data might fail even if the data is still readable but its integrity cannot be guaranteed.
+
+    It is recommended to only use this error code to report a permanent storage corruption. However application writers must keep in mind that transient errors while reading the storage might be reported using this error code.
+
+.. macro:: PSA_ERROR_DATA_CORRUPT
+    :definition: ((psa_status_t)-152)
+
+    .. summary::
+        Stored data has been corrupted.
+
+    This error indicates that some persistent storage has suffered corruption.  It does not indicate the following situations, which have specific error codes:
+
+    * A corruption of volatile memory - use `PSA_ERROR_CORRUPTION_DETECTED`.
+    * A communication error between the cryptoprocessor and its external storage - use `PSA_ERROR_COMMUNICATION_FAILURE`.
+    * When the storage is in a valid state but is full - use `PSA_ERROR_INSUFFICIENT_STORAGE`.
+    * When the storage fails for other reasons - use `PSA_ERROR_STORAGE_FAILURE`.
+    * When the stored data is not valid - use `PSA_ERROR_DATA_INVALID`.
+
+    Note that a storage corruption does not indicate that any data that was previously read is invalid. However this previously read data might no longer be readable from storage.
+
+    When a storage failure occurs, it is no longer possible to ensure the global integrity of the keystore. Depending on the global integrity guarantees offered by the implementation, access to other data might fail even if the data is still readable but its integrity cannot be guaranteed.
+
+    It is recommended to only use this error code to report when a storage component indicates that the stored data is corrupt, or fails an integrity check. For example, in situations that the PSA Internal Trusted Storage API reports `PSA_ERROR_DATA_CORRUPT` or `PSA_ERROR_INVALID_SIGNATURE`.
+
+.. macro:: PSA_ERROR_DATA_INVALID
+    :definition: ((psa_status_t)-153)
+
+    .. summary::
+        Data read from storage is not valid for the implementation.
+
+    This error indicates that some data read from storage does not have a valid format. It does not indicate the following situations, which have specific error codes:
+
+    * When the storage or stored data is corrupted - use `PSA_ERROR_DATA_CORRUPT`.
+    * When the storage fails for other reasons - use `PSA_ERROR_STORAGE_FAILURE`.
+    * An invalid argument to the API - use `PSA_ERROR_INVALID_ARGUMENT`.
+
+    This error is typically a result of an integration failure, where the implementation reading the data is not compatible with the implementation that stored the data.
+
+    It is recommended to only use this error code to report when data that is successfully read from storage is invalid.
+
+.. macro:: PSA_ERROR_HARDWARE_FAILURE
+    :definition: ((psa_status_t)-147)
+
+    .. summary::
+        A hardware failure was detected.
+
+    A hardware failure can be transient or permanent depending on the cause.
+
+.. macro:: PSA_ERROR_CORRUPTION_DETECTED
+    :definition: ((psa_status_t)-151)
+
+    .. summary::
+        A tampering attempt was detected.
+
+    If an application receives this error code, there is no guarantee that previously accessed or computed data was correct and remains confidential. In this situation, it is recommended that applications perform no further security functions and enter a safe failure state.
+
+    Implementations can return this error code if they detect an invalid state that cannot happen during normal operation and that indicates that the implementation's security guarantees no longer hold. Depending on the implementation architecture and on its security and safety goals, the implementation might forcibly terminate the application.
+
+    This error code is intended as a last resort when a security breach is detected and it is unsure whether the keystore data is still protected. Implementations must only return this error code to report an alarm from a tampering detector, to indicate that the confidentiality of stored data can no longer be guaranteed, or to indicate that the integrity of previously returned data is now considered compromised. Implementations must not use this error code to indicate a hardware failure that merely makes it impossible to perform the requested operation, instead use `PSA_ERROR_COMMUNICATION_FAILURE`, `PSA_ERROR_STORAGE_FAILURE`, `PSA_ERROR_HARDWARE_FAILURE`, `PSA_ERROR_INSUFFICIENT_ENTROPY` or other applicable error code.
+
+    This error indicates an attack against the application. Implementations must not return this error code as a consequence of the behavior of the application itself.
+
+.. macro:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    :definition: ((psa_status_t)-148)
+
+    .. summary::
+        There is not enough entropy to generate random data needed for the requested action.
+
+    This error indicates a failure of a hardware random generator. Application writers must note that this error can be returned not only by functions whose purpose is to generate random data, such as key, IV or nonce generation, but also by functions that execute an algorithm with a randomized result, as well as functions that use randomization of intermediate computations as a countermeasure to certain attacks.
+
+    It is recommended that implementations do not return this error after `psa_crypto_init()` has succeeded. This can be achieved if the implementation generates sufficient entropy during initialization and subsequently a cryptographically secure pseudorandom generator (PRNG) is used. However, implementations might return this error at any time, for example, if a policy requires the PRNG to be reseeded during normal operation.
+
+.. macro:: PSA_ERROR_INVALID_SIGNATURE
+    :definition: ((psa_status_t)-149)
+
+    .. summary::
+        The signature, MAC or hash is incorrect.
+
+    Verification functions return this error if the verification calculations completed successfully, and the value to be verified was determined to be incorrect.
+
+    If the value to verify has an invalid size, implementations can return either `PSA_ERROR_INVALID_ARGUMENT` or `PSA_ERROR_INVALID_SIGNATURE`.
+
+.. macro:: PSA_ERROR_INVALID_PADDING
+    :definition: ((psa_status_t)-150)
+
+    .. summary::
+        The decrypted padding is incorrect.
+
+    .. warning::
+        In some protocols, when decrypting data, it is essential that the behavior of the application does not depend on whether the padding is correct, down to precise timing. Protocols that use authenticated encryption are recommended for use by applications, rather than plain encryption. If the application must perform a decryption of unauthenticated data, the application writer must take care not to reveal whether the padding is invalid.
+
+    Implementations must handle padding carefully, aiming to make it impossible for an external observer to distinguish between valid and invalid padding. In particular, it is recommended that the timing of a decryption operation does not depend on the validity of the padding.
+
+.. macro:: PSA_ERROR_INSUFFICIENT_DATA
+    :definition: ((psa_status_t)-143)
+
+    .. summary::
+        Return this error when there's insufficient data when attempting to read from a resource.
+
+.. macro:: PSA_ERROR_INVALID_HANDLE
+    :definition: ((psa_status_t)-136)
+
+    .. summary::
+        The key identifier is not valid.
+
+    See also :title:`key-ids`.
diff --git a/docs/html/_sources/api/ops/aead.rst.txt b/docs/html/_sources/api/ops/aead.rst.txt
new file mode 100644
index 0000000..162af7c
--- /dev/null
+++ b/docs/html/_sources/api/ops/aead.rst.txt
@@ -0,0 +1,945 @@
+.. _aead:
+
+Authenticated encryption with associated data (AEAD)
+====================================================
+
+.. _aead-algorithms:
+
+AEAD algorithms
+---------------
+
+.. macro:: PSA_ALG_CCM
+    :definition: ((psa_algorithm_t)0x05500100)
+
+    .. summary::
+        The CCM authenticated encryption algorithm.
+
+    The underlying block cipher is determined by the key type.
+
+.. macro:: PSA_ALG_GCM
+    :definition: ((psa_algorithm_t)0x05500200)
+
+    .. summary::
+        The GCM authenticated encryption algorithm.
+
+    The underlying block cipher is determined by the key type.
+
+.. macro:: PSA_ALG_CHACHA20_POLY1305
+    :definition: ((psa_algorithm_t)0x05100500)
+
+    .. summary::
+        The Chacha20-Poly1305 AEAD algorithm.
+
+    The ChaCha20_Poly1305 construction is defined in :RFC:`7539`.
+
+    Variants of this algorithm are defined by the length of the nonce:
+
+    - Implementations must support a 12-byte nonce, as defined in :RFC:`7539`.
+    - Implementations can optionally support an 8-byte nonce, the original variant.
+    - It is recommended that implementations do not support other sizes of nonce.
+
+    Implementations must support 16-byte tags. It is recommended that truncated tag sizes are rejected.
+
+.. macro:: PSA_ALG_AEAD_WITH_SHORTENED_TAG
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build a AEAD algorithm with a shortened tag.
+
+    .. param:: aead_alg
+        An AEAD algorithm identifier (value of type `psa_algorithm_t` such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: tag_length
+        Desired length of the authentication tag in bytes.
+
+    .. return::
+        The corresponding AEAD algorithm with the specified tag length.
+
+        Unspecified if ``alg`` is not a supported AEAD algorithm or if ``tag_length`` is not valid for the specified AEAD algorithm.
+
+    An AEAD algorithm with a shortened tag is similar to the corresponding AEAD algorithm, but has an authentication tag that consists of fewer bytes. Depending on the algorithm, the tag length might affect the calculation of the ciphertext.
+
+    The AEAD algorithm with a default length tag can be recovered using `PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG()`.
+
+Single-part AEAD functions
+--------------------------
+
+.. function:: psa_aead_encrypt
+
+    .. summary::
+        Process an authenticated encryption operation.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation.
+        It must allow the usage `PSA_KEY_USAGE_ENCRYPT`.
+    .. param:: psa_algorithm_t alg
+        The AEAD algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: const uint8_t * nonce
+        Nonce or IV to use.
+    .. param:: size_t nonce_length
+        Size of the ``nonce`` buffer in bytes. This must be appropriate for the selected algorithm. The default nonce size is :code:`PSA_AEAD_NONCE_LENGTH(key_type, alg)` where ``key_type`` is the type of ``key``.
+    .. param:: const uint8_t * additional_data
+        Additional data that will be authenticated but not encrypted.
+    .. param:: size_t additional_data_length
+        Size of ``additional_data`` in bytes.
+    .. param:: const uint8_t * plaintext
+        Data that will be authenticated and encrypted.
+    .. param:: size_t plaintext_length
+        Size of ``plaintext`` in bytes.
+    .. param:: uint8_t * ciphertext
+        Output buffer for the authenticated and encrypted data. The additional data is not part of this output. For algorithms where the encrypted data and the authentication tag are defined as separate outputs, the authentication tag is appended to the encrypted data.
+    .. param:: size_t ciphertext_size
+        Size of the ``ciphertext`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_AEAD_ENCRYPT_OUTPUT_SIZE(key_type, alg, plaintext_length)`  where ``key_type`` is the type of ``key``.
+        * :code:`PSA_AEAD_ENCRYPT_OUTPUT_MAX_SIZE(plaintext_length)` evaluates to the maximum ciphertext size of any supported AEAD encryption.
+
+    .. param:: size_t * ciphertext_length
+        On success, the size of the output in the ``ciphertext`` buffer.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_ENCRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not an AEAD algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        ``ciphertext_size`` is too small. `PSA_AEAD_ENCRYPT_OUTPUT_SIZE()` or `PSA_AEAD_ENCRYPT_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+.. function:: psa_aead_decrypt
+
+    .. summary::
+        Process an authenticated decryption operation.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation.
+        It must allow the usage `PSA_KEY_USAGE_DECRYPT`.
+    .. param:: psa_algorithm_t alg
+        The AEAD algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: const uint8_t * nonce
+        Nonce or IV to use.
+    .. param:: size_t nonce_length
+        Size of the ``nonce`` buffer in bytes. This must be appropriate for the selected algorithm. The default nonce size is :code:`PSA_AEAD_NONCE_LENGTH(key_type, alg)` where ``key_type`` is the type of ``key``.
+    .. param:: const uint8_t * additional_data
+        Additional data that has been authenticated but not encrypted.
+    .. param:: size_t additional_data_length
+        Size of ``additional_data`` in bytes.
+    .. param:: const uint8_t * ciphertext
+        Data that has been authenticated and encrypted. For algorithms where the encrypted data and the authentication tag are defined as separate inputs, the buffer must contain the encrypted data followed by the authentication tag.
+    .. param:: size_t ciphertext_length
+        Size of ``ciphertext`` in bytes.
+    .. param:: uint8_t * plaintext
+        Output buffer for the decrypted data.
+    .. param:: size_t plaintext_size
+        Size of the ``plaintext`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_AEAD_DECRYPT_OUTPUT_SIZE(key_type, alg, ciphertext_length)`  where ``key_type`` is the type of ``key``.
+        * :code:`PSA_AEAD_DECRYPT_OUTPUT_MAX_SIZE(ciphertext_length)` evaluates to the maximum plaintext size of any supported AEAD decryption.
+
+    .. param:: size_t * plaintext_length
+        On success, the size of the output in the ``plaintext`` buffer.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The ciphertext is not authentic.
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DECRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not an AEAD algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        ``plaintext_size`` is too small. `PSA_AEAD_DECRYPT_OUTPUT_SIZE()` or `PSA_AEAD_DECRYPT_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+Multi-part AEAD operations
+--------------------------
+
+.. _aead-multi-part-warning:
+
+.. warning::
+    When decrypting using a multi-part AEAD operation, there is no guarantee that the input or output is valid until `psa_aead_verify()` has returned `PSA_SUCCESS`.
+
+    A call to `psa_aead_update()` or `psa_aead_update_ad()` returning `PSA_SUCCESS` **does not** indicate that the input and output is valid.
+
+    Until an application calls `psa_aead_verify()` and it has returned `PSA_SUCCESS`, the following rules apply to input and output data from a multi-part AEAD operation:
+
+    * Do not trust the input. If the application takes any action that depends on the input data, this action will need to be undone if the input turns out to be invalid.
+
+    * Store the output in a confidential location. In particular, the application must not copy the output to a memory or storage space which is shared.
+
+    * Do not trust the output. If the application takes any action that depends on the tentative decrypted data, this action will need to be undone if the input turns out to be invalid. Furthermore, if an adversary can observe that this action took place, for example, through timing, they might be able to use this fact as an oracle to decrypt any message encrypted with the same key.
+
+    An application that does not follow these rules might be vulnerable to maliciously constructed AEAD input data.
+
+
+.. typedef:: /* implementation-defined type */ psa_aead_operation_t
+
+    .. summary::
+        The type of the state object for multi-part AEAD operations.
+
+    Before calling any function on an AEAD operation object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_aead_operation_t operation;
+          memset(&operation, 0, sizeof(operation));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_aead_operation_t operation;
+
+    * Initialize the object to the initializer `PSA_AEAD_OPERATION_INIT`, for example:
+
+      .. autocode::
+          psa_aead_operation_t operation = PSA_AEAD_OPERATION_INIT;
+
+    * Assign the result of the function `psa_aead_operation_init()` to the object, for example:
+
+      .. autocode::
+          psa_aead_operation_t operation;
+          operation = psa_aead_operation_init();
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+.. macro:: PSA_AEAD_OPERATION_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for an AEAD operation object of type `psa_aead_operation_t`.
+
+.. function:: psa_aead_operation_init
+
+    .. summary::
+        Return an initial value for an AEAD operation object.
+
+    .. return:: psa_aead_operation_t
+
+.. function:: psa_aead_encrypt_setup
+
+    .. summary::
+        Set the key for a multi-part authenticated encryption operation.
+
+    .. param:: psa_aead_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_aead_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_ENCRYPT`.
+    .. param:: psa_algorithm_t alg
+        The AEAD algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_ENCRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not an AEAD algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The sequence of operations to encrypt a message with authentication is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_aead_operation_t`, e.g. `PSA_AEAD_OPERATION_INIT`.
+    #. Call `psa_aead_encrypt_setup()` to specify the algorithm and key.
+    #. If needed, call `psa_aead_set_lengths()` to specify the length of the inputs to the subsequent calls to `psa_aead_update_ad()` and `psa_aead_update()`. See the documentation of `psa_aead_set_lengths()` for details.
+    #. Call either `psa_aead_generate_nonce()` or `psa_aead_set_nonce()` to generate or set the nonce. It is recommended to use `psa_aead_generate_nonce()` unless the protocol being implemented requires a specific nonce value.
+    #. Call `psa_aead_update_ad()` zero, one or more times, passing a fragment of the non-encrypted additional authenticated data each time.
+    #. Call `psa_aead_update()` zero, one or more times, passing a fragment of the message to encrypt each time.
+    #. Call `psa_aead_finish()`.
+
+    If an error occurs at any step after a call to `psa_aead_encrypt_setup()`, the operation will need to be reset by a call to `psa_aead_abort()`. The application can call `psa_aead_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_aead_encrypt_setup()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_aead_finish()`.
+    * A call to `psa_aead_abort()`.
+
+.. function:: psa_aead_decrypt_setup
+
+    .. summary::
+        Set the key for a multi-part authenticated decryption operation.
+
+    .. param:: psa_aead_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_aead_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_DECRYPT`.
+    .. param:: psa_algorithm_t alg
+        The AEAD algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DECRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not an AEAD algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The sequence of operations to decrypt a message with authentication is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_aead_operation_t`, e.g. `PSA_AEAD_OPERATION_INIT`.
+    #. Call `psa_aead_decrypt_setup()` to specify the algorithm and key.
+    #. If needed, call `psa_aead_set_lengths()` to specify the length of the inputs to the subsequent calls to `psa_aead_update_ad()` and `psa_aead_update()`. See the documentation of `psa_aead_set_lengths()` for details.
+    #. Call `psa_aead_set_nonce()` with the nonce for the decryption.
+    #. Call `psa_aead_update_ad()` zero, one or more times, passing a fragment of the non-encrypted additional authenticated data each time.
+    #. Call `psa_aead_update()` zero, one or more times, passing a fragment of the ciphertext to decrypt each time.
+    #. Call `psa_aead_verify()`.
+
+    If an error occurs at any step after a call to `psa_aead_decrypt_setup()`, the operation will need to be reset by a call to `psa_aead_abort()`. The application can call `psa_aead_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_aead_decrypt_setup()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_aead_verify()`.
+    * A call to `psa_aead_abort()`.
+
+.. function:: psa_aead_generate_nonce
+
+    .. summary::
+        Generate a random nonce for an authenticated encryption operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: uint8_t * nonce
+        Buffer where the generated nonce is to be written.
+    .. param:: size_t nonce_size
+        Size of the ``nonce`` buffer in bytes. This must be at least :code:`PSA_AEAD_NONCE_LENGTH(key_type, alg)` where ``key_type`` and ``alg`` are type of key and the algorithm respectively that were used to set up the AEAD operation.
+    .. param:: size_t * nonce_length
+        On success, the number of bytes of the generated nonce.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be an active AEAD encryption operation, with no nonce set.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``nonce`` buffer is too small. `PSA_AEAD_NONCE_LENGTH()` or `PSA_AEAD_NONCE_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function generates a random nonce for the authenticated encryption operation with an appropriate size for the chosen algorithm, key type and key size.
+
+    The application must call `psa_aead_encrypt_setup()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+.. function:: psa_aead_set_nonce
+
+    .. summary::
+        Set the nonce for an authenticated encryption or decryption operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: const uint8_t * nonce
+        Buffer containing the nonce to use.
+    .. param:: size_t nonce_length
+        Size of the nonce in bytes. This must be a valid nonce size for the chosen algorithm. The default nonce size is :code:`PSA_AEAD_NONCE_LENGTH(key_type, alg)` where ``key_type`` and ``alg`` are type of key and the algorithm respectively that were used to set up the AEAD operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, with no nonce set.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The size of ``nonce`` is not acceptable for the chosen algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function sets the nonce for the authenticated encryption or decryption operation.
+
+    The application must call `psa_aead_encrypt_setup()` or `psa_aead_decrypt_setup()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+    .. note::
+        When encrypting, `psa_aead_generate_nonce()` is recommended instead of using this function, unless implementing a protocol that requires a non-random IV.
+
+.. function:: psa_aead_set_lengths
+
+    .. summary::
+        Declare the lengths of the message and additional data for AEAD.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: size_t ad_length
+        Size of the non-encrypted additional authenticated data in bytes.
+    .. param:: size_t plaintext_length
+        Size of the plaintext to encrypt in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, and `psa_aead_update_ad()` and `psa_aead_update()` must not have been called yet.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        At least one of the lengths is not acceptable for the chosen algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call this function before calling `psa_aead_update_ad()` or `psa_aead_update()` if the algorithm for the operation requires it. If the algorithm does not require it, calling this function is optional, but if this function is called then the implementation must enforce the lengths.
+
+    This function can be called before or after setting the nonce with `psa_aead_set_nonce()` or `psa_aead_generate_nonce()`.
+
+    * For `PSA_ALG_CCM`, calling this function is required.
+    * For the other AEAD algorithms defined in this specification, calling this function is not required.
+    * For vendor-defined algorithm, refer to the vendor documentation.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+.. function:: psa_aead_update_ad
+
+    .. summary::
+        Pass additional data to an active AEAD operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: const uint8_t * input
+        Buffer containing the fragment of additional data.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+
+        .. warning::
+            When decrypting, do not trust the input until `psa_aead_verify()` succeeds.
+
+            See the :ref:`detailed warning <aead-multi-part-warning>`.
+
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, have a nonce set, have lengths set if required by the algorithm, and `psa_aead_update()` must not have been called yet.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total input length overflows the additional data length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Additional data is authenticated, but not encrypted.
+
+    This function can be called multiple times to pass successive fragments of the additional data. This function must not be called after passing data to encrypt or decrypt with `psa_aead_update()`.
+
+    The following must occur before calling this function:
+
+    #. Call either `psa_aead_encrypt_setup()` or `psa_aead_decrypt_setup()`.
+    #. Set the nonce with `psa_aead_generate_nonce()` or `psa_aead_set_nonce()`.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+.. function:: psa_aead_update
+
+    .. summary::
+        Encrypt or decrypt a message fragment in an active AEAD operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: const uint8_t * input
+        Buffer containing the message fragment to encrypt or decrypt.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * output
+        Buffer where the output is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_AEAD_UPDATE_OUTPUT_SIZE(key_type, alg, input_length)` where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation.
+        * :code:`PSA_AEAD_UPDATE_OUTPUT_MAX_SIZE(input_length)` evaluates to the maximum output size of any supported AEAD algorithm.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+
+        .. warning::
+            When decrypting, do not use the output until `psa_aead_verify()` succeeds.
+
+            See the :ref:`detailed warning <aead-multi-part-warning>`.
+
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, have a nonce set, and have lengths set if required by the algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small. `PSA_AEAD_UPDATE_OUTPUT_SIZE()` or `PSA_AEAD_UPDATE_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total length of input to `psa_aead_update_ad()` so far is less than the additional data length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total input length overflows the plaintext length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The following must occur before calling this function:
+
+    #. Call either `psa_aead_encrypt_setup()` or `psa_aead_decrypt_setup()`. The choice of setup function determines whether this function encrypts or decrypts its input.
+    #. Set the nonce with `psa_aead_generate_nonce()` or `psa_aead_set_nonce()`.
+    #. Call `psa_aead_update_ad()` to pass all the additional data.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+    This function does not require the input to be aligned to any particular block boundary. If the implementation can only process a whole block at a time, it must consume all the input provided, but it might delay the end of the corresponding output until a subsequent call to `psa_aead_update()`, `psa_aead_finish()` or `psa_aead_verify()` provides sufficient input. The amount of data that can be delayed in this way is bounded by `PSA_AEAD_UPDATE_OUTPUT_SIZE()`.
+
+.. function:: psa_aead_finish
+
+    .. summary::
+        Finish encrypting a message in an AEAD operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: uint8_t * ciphertext
+        Buffer where the last part of the ciphertext is to be written.
+    .. param:: size_t ciphertext_size
+        Size of the ``ciphertext`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_AEAD_FINISH_OUTPUT_SIZE(key_type, alg)` where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation.
+        * `PSA_AEAD_FINISH_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported AEAD algorithm.
+
+    .. param:: size_t * ciphertext_length
+        On success, the number of bytes of returned ciphertext.
+    .. param:: uint8_t * tag
+        Buffer where the authentication tag is to be written.
+    .. param:: size_t tag_size
+        Size of the ``tag`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The exact tag size is :code:`PSA_AEAD_TAG_LENGTH(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size of the key, and ``alg`` is the algorithm that were used in the call to `psa_aead_encrypt_setup()`.
+        * `PSA_AEAD_TAG_MAX_SIZE` evaluates to the maximum tag size of any supported AEAD algorithm.
+
+    .. param:: size_t * tag_length
+        On success, the number of bytes that make up the returned tag.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be an active encryption operation with a nonce set.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``ciphertext`` or ``tag`` buffer is too small.
+        `PSA_AEAD_FINISH_OUTPUT_SIZE()` or `PSA_AEAD_FINISH_OUTPUT_MAX_SIZE` can be used to determine the required ``ciphertext`` buffer size.
+        `PSA_AEAD_TAG_LENGTH()` or `PSA_AEAD_TAG_MAX_SIZE` can be used to determine the required ``tag`` buffer size.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total length of input to `psa_aead_update_ad()` so far is less than the additional data length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total length of input to `psa_aead_update()` so far is less than the plaintext length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The operation must have been set up with `psa_aead_encrypt_setup()`.
+
+    This function finishes the authentication of the additional data formed by concatenating the inputs passed to preceding calls to `psa_aead_update_ad()` with the plaintext formed by concatenating the inputs passed to preceding calls to `psa_aead_update()`.
+
+    This function has two output buffers:
+
+    * ``ciphertext`` contains trailing ciphertext that was buffered from preceding calls to `psa_aead_update()`.
+    * ``tag`` contains the authentication tag.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+.. function:: psa_aead_verify
+
+    .. summary::
+        Finish authenticating and decrypting a message in an AEAD operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Active AEAD operation.
+    .. param:: uint8_t * plaintext
+        Buffer where the last part of the plaintext is to be written. This is the remaining data from previous calls to `psa_aead_update()` that could not be processed until the end of the input.
+    .. param:: size_t plaintext_size
+        Size of the ``plaintext`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_AEAD_VERIFY_OUTPUT_SIZE(key_type, alg)` where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation.
+        * `PSA_AEAD_VERIFY_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported AEAD algorithm.
+
+    .. param:: size_t * plaintext_length
+        On success, the number of bytes of returned plaintext.
+    .. param:: const uint8_t * tag
+        Buffer containing the authentication tag.
+    .. param:: size_t tag_length
+        Size of the ``tag`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The calculations were successful, but the authentication tag is not correct.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be an active decryption operation with a nonce set.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``plaintext`` buffer is too small. `PSA_AEAD_VERIFY_OUTPUT_SIZE()` or `PSA_AEAD_VERIFY_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total length of input to `psa_aead_update_ad()` so far is less than the additional data length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total length of input to `psa_aead_update()` so far is less than the plaintext length that was previously specified with `psa_aead_set_lengths()`.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The operation must have been set up with `psa_aead_decrypt_setup()`.
+
+    This function finishes the authenticated decryption of the message components:
+
+    * The additional data consisting of the concatenation of the inputs passed to preceding calls to `psa_aead_update_ad()`.
+    * The ciphertext consisting of the concatenation of the inputs passed to preceding calls to `psa_aead_update()`.
+    * The tag passed to this function call.
+
+    If the authentication tag is correct, this function outputs any remaining plaintext and reports success. If the authentication tag is not correct, this function returns `PSA_ERROR_INVALID_SIGNATURE`.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_aead_abort()`.
+
+    .. note::
+        Implementations must make the best effort to ensure that the comparison between the actual tag and the expected tag is performed in constant time.
+
+.. function:: psa_aead_abort
+
+    .. summary::
+        Abort an AEAD operation.
+
+    .. param:: psa_aead_operation_t * operation
+        Initialized AEAD operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Aborting an operation frees all associated resources except for the ``operation`` object itself. Once aborted, the operation object can be reused for another operation by calling `psa_aead_encrypt_setup()` or `psa_aead_decrypt_setup()` again.
+
+    This function can be called any time after the operation object has been initialized as described in `psa_aead_operation_t`.
+
+    In particular, calling `psa_aead_abort()` after the operation has been terminated by a call to `psa_aead_abort()`, `psa_aead_finish()` or `psa_aead_verify()` is safe and has no effect.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_AEAD_ON_BLOCK_CIPHER
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an AEAD mode on a block cipher.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an AEAD algorithm which is an AEAD mode based on a block cipher, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG
+    :definition: /* specification-defined value */
+
+    .. summary::
+        An AEAD algorithm with the default tag length.
+
+    .. param:: aead_alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return::
+        The corresponding AEAD algorithm with the default tag length for that algorithm.
+
+    This macro can be used to construct the AEAD algorithm with default tag length from an AEAD algorithm with a shortened tag. See also `PSA_ALG_AEAD_WITH_SHORTENED_TAG()`.
+
+.. macro:: PSA_AEAD_ENCRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum size of the output of `psa_aead_encrypt()`, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: plaintext_length
+        Size of the plaintext in bytes.
+
+    .. return::
+        The AEAD ciphertext size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    If the size of the ciphertext buffer is at least this large, it is guaranteed that `psa_aead_encrypt()` will not fail due to an insufficient buffer size. Depending on the algorithm, the actual size of the ciphertext might be smaller.
+
+    See also `PSA_AEAD_ENCRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_ENCRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_aead_encrypt()`, for any of the supported key types and AEAD algorithms.
+
+    .. param:: plaintext_length
+        Size of the plaintext in bytes.
+
+    If the size of the ciphertext buffer is at least this large, it is guaranteed that `psa_aead_encrypt()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_AEAD_ENCRYPT_OUTPUT_SIZE()`.
+
+.. macro:: PSA_AEAD_DECRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum size of the output of `psa_aead_decrypt()`, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: ciphertext_length
+        Size of the ciphertext in bytes.
+
+    .. return::
+        The AEAD plaintext size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    If the size of the plaintext buffer is at least this large, it is guaranteed that `psa_aead_decrypt()` will not fail due to an insufficient buffer size. Depending on the algorithm, the actual size of the plaintext might be smaller.
+
+    See also `PSA_AEAD_DECRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_DECRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_aead_decrypt()`, for any of the supported key types and AEAD algorithms.
+
+    .. param:: ciphertext_length
+        Size of the ciphertext in bytes.
+
+    If the size of the plaintext buffer is at least this large, it is guaranteed that `psa_aead_decrypt()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_AEAD_DECRYPT_OUTPUT_SIZE()`.
+
+.. macro:: PSA_AEAD_NONCE_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The default nonce size for an AEAD algorithm, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return::
+        The default nonce size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    This macro can be used to allocate a buffer of sufficient size to store the nonce output from `psa_aead_generate_nonce()`.
+
+    See also `PSA_AEAD_NONCE_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_NONCE_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum nonce size for all supported AEAD algorithms, in bytes.
+
+    See also `PSA_AEAD_NONCE_LENGTH()`.
+
+.. macro:: PSA_AEAD_UPDATE_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_aead_update()`.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+    .. param:: input_length
+        Size of the input in bytes.
+
+    .. return::
+        A sufficient output buffer size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_aead_update()` will not fail due to an insufficient buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_AEAD_UPDATE_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_UPDATE_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_aead_update()`, for any of the supported key types and AEAD algorithms.
+
+    .. param:: input_length
+        Size of the input in bytes.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_aead_update()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_AEAD_UPDATE_OUTPUT_SIZE()`.
+
+.. macro:: PSA_AEAD_FINISH_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient ciphertext buffer size for `psa_aead_finish()`.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return::
+        A sufficient ciphertext buffer size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    If the size of the ciphertext buffer is at least this large, it is guaranteed that `psa_aead_finish()` will not fail due to an insufficient ciphertext buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_AEAD_FINISH_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_FINISH_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient ciphertext buffer size for `psa_aead_finish()`, for any of the supported key types and AEAD algorithms.
+
+    See also `PSA_AEAD_FINISH_OUTPUT_SIZE()`.
+
+.. macro:: PSA_AEAD_TAG_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The length of a tag for an AEAD algorithm, in bytes.
+
+    .. param:: key_type
+        The type of the AEAD key.
+    .. param:: key_bits
+        The size of the AEAD key in bits.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return::
+        The tag length for the specified algorithm and key.
+        If the AEAD algorithm does not have an identified tag that can be distinguished from the rest of the ciphertext, return ``0``. If the AEAD algorithm is not recognized, return ``0``. An implementation can return either ``0`` or a correct size for an AEAD algorithm that it recognizes, but does not support.
+
+    This macro can be used to allocate a buffer of sufficient size to store the tag output from `psa_aead_finish()`.
+
+    See also `PSA_AEAD_TAG_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_TAG_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum tag size for all supported AEAD algorithms, in bytes.
+
+    See also `PSA_AEAD_TAG_LENGTH()`.
+
+.. macro:: PSA_AEAD_VERIFY_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient plaintext buffer size for `psa_aead_verify()`.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        An AEAD algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_AEAD(alg)` is true).
+
+    .. return::
+        A sufficient plaintext buffer size for the specified key type and algorithm. If the key type or AEAD algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and AEAD algorithm that it recognizes, but does not support.
+
+    If the size of the plaintext buffer is at least this large, it is guaranteed that `psa_aead_verify()` will not fail due to an insufficient plaintext buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_AEAD_VERIFY_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_AEAD_VERIFY_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient plaintext buffer size for `psa_aead_verify()`, for any of the supported key types and AEAD algorithms.
+
+    See also `PSA_AEAD_VERIFY_OUTPUT_SIZE()`.
diff --git a/docs/html/_sources/api/ops/ciphers.rst.txt b/docs/html/_sources/api/ops/ciphers.rst.txt
new file mode 100644
index 0000000..2e0883e
--- /dev/null
+++ b/docs/html/_sources/api/ops/ciphers.rst.txt
@@ -0,0 +1,757 @@
+.. _ciphers:
+
+Unauthenticated ciphers
+=======================
+
+.. warning::
+
+    The unauthenticated cipher API is provided to implement legacy protocols and
+    for use cases where the data integrity and authenticity is guaranteed by
+    non-cryptographic means.
+
+    It is recommended that newer protocols use :title:`aead`.
+
+.. _cipher-algorithms:
+
+Cipher algorithms
+-----------------
+
+.. macro:: PSA_ALG_STREAM_CIPHER
+    :definition: ((psa_algorithm_t)0x04800100)
+
+    .. summary::
+        The stream cipher mode of a stream cipher algorithm.
+
+    The underlying stream cipher is determined by the key type:
+
+    * To use ChaCha20, use a key type of `PSA_KEY_TYPE_CHACHA20` and algorithm id `PSA_ALG_STREAM_CIPHER`.
+    * To use ARC4, use a key type of `PSA_KEY_TYPE_ARC4` and algorithm id `PSA_ALG_STREAM_CIPHER`.
+
+.. macro:: PSA_ALG_CTR
+    :definition: ((psa_algorithm_t)0x04c01000)
+
+    .. summary::
+        A stream cipher built using the Counter (CTR) mode of a block cipher.
+
+    CTR is a stream cipher which is built from a block cipher. The underlying block cipher is determined by the key type. For example, to use AES-128-CTR, use this algorithm with a key of type `PSA_KEY_TYPE_AES` and a length of 128 bits (16 bytes).
+
+.. macro:: PSA_ALG_CFB
+    :definition: ((psa_algorithm_t)0x04c01100)
+
+    .. summary::
+        A stream cipher built using the Cipher Feedback (CFB) mode of a block cipher.
+
+    The underlying block cipher is determined by the key type.
+
+.. macro:: PSA_ALG_OFB
+    :definition: ((psa_algorithm_t)0x04c01200)
+
+    .. summary::
+        A stream cipher built using the Output Feedback (OFB) mode of a block cipher.
+
+    The underlying block cipher is determined by the key type.
+
+.. macro:: PSA_ALG_XTS
+    :definition: ((psa_algorithm_t)0x0440ff00)
+
+    .. summary::
+        The XTS cipher mode of a block cipher.
+
+    XTS is a cipher mode which is built from a block cipher. It requires at least one full block of input, but beyond this minimum the input does not need to be a whole number of blocks.
+
+.. macro:: PSA_ALG_ECB_NO_PADDING
+    :definition: ((psa_algorithm_t)0x04404400)
+
+    .. summary::
+        The Electronic Code Book (ECB) mode of a block cipher, with no padding.
+
+    .. warning::
+        ECB mode does not protect the confidentiality of the encrypted data except in extremely narrow circumstances. It is recommended that applications only use ECB if they need to construct an operating mode that the implementation does not provide. Implementations are encouraged to provide the modes that applications need in preference to supporting direct access to ECB.
+
+    The underlying block cipher is determined by the key type.
+
+    This symmetric cipher mode can only be used with messages whose lengths are whole number of blocks for the chosen block cipher.
+
+    ECB mode does not accept an initialization vector (IV). When using a multi-part cipher operation with this algorithm, `psa_cipher_generate_iv()` and `psa_cipher_set_iv()` must not be called.
+
+.. macro:: PSA_ALG_CBC_NO_PADDING
+    :definition: ((psa_algorithm_t)0x04404000)
+
+    .. summary::
+        The Cipher Block Chaining (CBC) mode of a block cipher, with no padding.
+
+    The underlying block cipher is determined by the key type.
+
+    This symmetric cipher mode can only be used with messages whose lengths are whole number of blocks for the chosen block cipher.
+
+.. macro:: PSA_ALG_CBC_PKCS7
+    :definition: ((psa_algorithm_t)0x04404100)
+
+    .. summary::
+        The Cipher Block Chaining (CBC) mode of a block cipher, with PKCS#7 padding.
+
+    The underlying block cipher is determined by the key type.
+
+    This is the padding method defined by PKCS#7 :RFC:`2315#10.3`.
+
+Single-part cipher functions
+----------------------------
+
+.. function:: psa_cipher_encrypt
+
+    .. summary::
+        Encrypt a message using a symmetric cipher.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation.
+        It must allow the usage `PSA_KEY_USAGE_ENCRYPT`.
+    .. param:: psa_algorithm_t alg
+        The cipher algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the message to encrypt.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * output
+        Buffer where the output is to be written. The output contains the IV followed by the ciphertext proper.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_CIPHER_ENCRYPT_OUTPUT_SIZE(key_type, alg, input_length)`  where ``key_type`` is the type of ``key``.
+        * :code:`PSA_CIPHER_ENCRYPT_OUTPUT_MAX_SIZE(input_length)` evaluates to the maximum output size of any supported cipher encryption.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_ENCRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a cipher algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        ``output_size`` is too small. `PSA_CIPHER_ENCRYPT_OUTPUT_SIZE()` or `PSA_CIPHER_ENCRYPT_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function encrypts a message with a random initialization vector (IV).
+    The length of the IV is :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)` where ``key_type`` is the type of ``key``.
+    The output of `psa_cipher_encrypt()` is the IV followed by the ciphertext.
+
+    Use the multi-part operation interface with a `psa_cipher_operation_t` object to provide other forms of IV or to manage the IV and ciphertext independently.
+
+.. function:: psa_cipher_decrypt
+
+    .. summary::
+        Decrypt a message using a symmetric cipher.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_DECRYPT`.
+    .. param:: psa_algorithm_t alg
+        The cipher algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the message to decrypt. This consists of the IV followed by the ciphertext proper.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * output
+        Buffer where the plaintext is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_CIPHER_DECRYPT_OUTPUT_SIZE(key_type, alg, input_length)`  where ``key_type`` is the type of ``key``.
+        * :code:`PSA_CIPHER_DECRYPT_OUTPUT_MAX_SIZE(input_length)` evaluates to the maximum output size of any supported cipher decryption.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DECRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a cipher algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        ``output_size`` is too small. `PSA_CIPHER_DECRYPT_OUTPUT_SIZE()` or `PSA_CIPHER_DECRYPT_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function decrypts a message encrypted with a symmetric cipher.
+
+    The input to this function must contain the IV followed by the ciphertext, as output by `psa_cipher_encrypt()`. The IV must be :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)` bytes in length, where ``key_type`` is the type of ``key``.
+
+    Use the multi-part operation interface with a `psa_cipher_operation_t` object to decrypt data which is not in the expected input format.
+
+Multi-part cipher operations
+----------------------------
+
+.. typedef:: /* implementation-defined type */ psa_cipher_operation_t
+
+    .. summary::
+        The type of the state object for multi-part cipher operations.
+
+    Before calling any function on a cipher operation object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_cipher_operation_t operation;
+          memset(&operation, 0, sizeof(operation));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_cipher_operation_t operation;
+
+    * Initialize the object to the initializer `PSA_CIPHER_OPERATION_INIT`, for example:
+
+      .. autocode::
+          psa_cipher_operation_t operation = PSA_CIPHER_OPERATION_INIT;
+
+    * Assign the result of the function `psa_cipher_operation_init()` to the object, for example:
+
+      .. autocode::
+          psa_cipher_operation_t operation;
+          operation = psa_cipher_operation_init();
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+.. macro:: PSA_CIPHER_OPERATION_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for a cipher operation object of type `psa_cipher_operation_t`.
+
+.. function:: psa_cipher_operation_init
+
+    .. summary::
+        Return an initial value for a cipher operation object.
+
+    .. return:: psa_cipher_operation_t
+
+.. function:: psa_cipher_encrypt_setup
+
+    .. summary::
+        Set the key for a multi-part symmetric encryption operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_cipher_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_ENCRYPT`.
+    .. param:: psa_algorithm_t alg
+        The cipher algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_ENCRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a cipher algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The sequence of operations to encrypt a message with a symmetric cipher is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_cipher_operation_t`, e.g. `PSA_CIPHER_OPERATION_INIT`.
+    #. Call `psa_cipher_encrypt_setup()` to specify the algorithm and key.
+    #. Call either `psa_cipher_generate_iv()` or `psa_cipher_set_iv()` to generate or set the initialization vector (IV), if the algorithm requires one. It is recommended to use `psa_cipher_generate_iv()` unless the protocol being implemented requires a specific IV value.
+    #. Call `psa_cipher_update()` zero, one or more times, passing a fragment of the message each time.
+    #. Call `psa_cipher_finish()`.
+
+    If an error occurs at any step after a call to `psa_cipher_encrypt_setup()`, the operation will need to be reset by a call to `psa_cipher_abort()`. The application can call `psa_cipher_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_cipher_encrypt_setup()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_cipher_finish()`.
+    * A call to `psa_cipher_abort()`.
+
+.. function:: psa_cipher_decrypt_setup
+
+    .. summary::
+        Set the key for a multi-part symmetric decryption operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_cipher_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_DECRYPT`.
+    .. param:: psa_algorithm_t alg
+        The cipher algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DECRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a cipher algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The sequence of operations to decrypt a message with a symmetric cipher is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_cipher_operation_t`, e.g. `PSA_CIPHER_OPERATION_INIT`.
+    #. Call `psa_cipher_decrypt_setup()` to specify the algorithm and key.
+    #. Call `psa_cipher_set_iv()` with the initialization vector (IV) for the decryption, if the algorithm requires one. This must match the IV used for the encryption.
+    #. Call `psa_cipher_update()` zero, one or more times, passing a fragment of the message each time.
+    #. Call `psa_cipher_finish()`.
+
+    If an error occurs at any step after a call to `psa_cipher_decrypt_setup()`, the operation will need to be reset by a call to `psa_cipher_abort()`. The application can call `psa_cipher_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_cipher_decrypt_setup()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_cipher_finish()`.
+    * A call to `psa_cipher_abort()`.
+
+.. function:: psa_cipher_generate_iv
+
+    .. summary::
+        Generate an initialization vector (IV) for a symmetric encryption operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        Active cipher operation.
+    .. param:: uint8_t * iv
+        Buffer where the generated IV is to be written.
+    .. param:: size_t iv_size
+        Size of the ``iv`` buffer in bytes. This must be at least :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)` where ``key_type`` and ``alg`` are type of key and the algorithm respectively that were used to set up the cipher operation.
+    .. param:: size_t * iv_length
+        On success, the number of bytes of the generated IV.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        Either:
+
+        *  The cipher algorithm does not use an IV.
+        *  The operation state is not valid: it must be active, with no IV set.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``iv`` buffer is too small. `PSA_CIPHER_IV_LENGTH()` or `PSA_CIPHER_IV_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function generates a random IV, nonce or initial counter value for the encryption operation as appropriate for the chosen algorithm, key type and key size.
+
+    The generated IV is always the default length for the key and algorithm: :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)`, where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation. To generate different lengths of IV, use `psa_generate_random()` and `psa_cipher_set_iv()`.
+
+    If the cipher algorithm does not use an IV, calling this function returns a `PSA_ERROR_BAD_STATE` error. For these algorithms, :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)` will be zero.
+
+    The application must call `psa_cipher_encrypt_setup()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_cipher_abort()`.
+
+.. function:: psa_cipher_set_iv
+
+    .. summary::
+        Set the initialization vector (IV) for a symmetric encryption or decryption operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        Active cipher operation.
+    .. param:: const uint8_t * iv
+        Buffer containing the IV to use.
+    .. param:: size_t iv_length
+        Size of the IV in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        Either:
+        
+        *  The cipher algorithm does not use an IV.
+        *  The operation state is not valid: it must be an active cipher encrypt operation, with no IV set.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The size of ``iv`` is not acceptable for the chosen algorithm, or the chosen algorithm does not use an IV.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function sets the IV, nonce or initial counter value for the encryption or decryption operation.
+
+    If the cipher algorithm does not use an IV, calling this function returns a `PSA_ERROR_BAD_STATE` error. For these algorithms, :code:`PSA_CIPHER_IV_LENGTH(key_type, alg)` will be zero.
+
+    The application must call `psa_cipher_encrypt_setup()` or `psa_cipher_decrypt_setup()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_cipher_abort()`.
+
+    .. note::
+        When encrypting, `psa_cipher_generate_iv()` is recommended instead of using this function, unless implementing a protocol that requires a non-random IV.
+
+.. function:: psa_cipher_update
+
+    .. summary::
+        Encrypt or decrypt a message fragment in an active cipher operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        Active cipher operation.
+    .. param:: const uint8_t * input
+        Buffer containing the message fragment to encrypt or decrypt.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * output
+        Buffer where the output is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_CIPHER_UPDATE_OUTPUT_SIZE(key_type, alg, input_length)`  where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation.
+        * :code:`PSA_CIPHER_UPDATE_OUTPUT_MAX_SIZE(input_length)` evaluates to the maximum output size of any supported cipher algorithm.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, with an IV set if required for the algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small. `PSA_CIPHER_UPDATE_OUTPUT_SIZE()` or `PSA_CIPHER_UPDATE_OUTPUT_MAX_SIZE()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The following must occur before calling this function:
+
+    #. Call either `psa_cipher_encrypt_setup()` or `psa_cipher_decrypt_setup()`. The choice of setup function determines whether this function encrypts or decrypts its input.
+    #. If the algorithm requires an IV, call `psa_cipher_generate_iv()` or `psa_cipher_set_iv()`. `psa_cipher_generate_iv()` is recommended when encrypting.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_cipher_abort()`.
+
+.. function:: psa_cipher_finish
+
+    .. summary::
+        Finish encrypting or decrypting a message in a cipher operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        Active cipher operation.
+    .. param:: uint8_t * output
+        Buffer where the output is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes. This must be appropriate for the selected algorithm and key:
+
+        * A sufficient output size is :code:`PSA_CIPHER_FINISH_OUTPUT_SIZE(key_type, alg)`  where ``key_type`` is the type of key and ``alg`` is the algorithm that were used to set up the operation.
+        * `PSA_CIPHER_FINISH_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported cipher algorithm.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The total input size passed to this operation is not valid for this particular algorithm. For example, the algorithm is a based on block cipher and requires a whole number of blocks, but the total input size is not a multiple of the block size.
+    .. retval:: PSA_ERROR_INVALID_PADDING
+        This is a decryption operation for an algorithm that includes padding, and the ciphertext does not contain valid padding.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active, with an IV set if required for the algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small. `PSA_CIPHER_FINISH_OUTPUT_SIZE()` or `PSA_CIPHER_FINISH_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_cipher_encrypt_setup()` or `psa_cipher_decrypt_setup()` before calling this function. The choice of setup function determines whether this function encrypts or decrypts its input.
+
+    This function finishes the encryption or decryption of the message formed by concatenating the inputs passed to preceding calls to `psa_cipher_update()`.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_cipher_abort()`.
+
+.. function:: psa_cipher_abort
+
+    .. summary::
+        Abort a cipher operation.
+
+    .. param:: psa_cipher_operation_t * operation
+        Initialized cipher operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Aborting an operation frees all associated resources except for the ``operation`` object itself. Once aborted, the operation object can be reused for another operation by calling `psa_cipher_encrypt_setup()` or `psa_cipher_decrypt_setup()` again.
+
+    This function can be called any time after the operation object has been initialized as described in `psa_cipher_operation_t`.
+
+    In particular, calling `psa_cipher_abort()` after the operation has been terminated by a call to `psa_cipher_abort()` or `psa_cipher_finish()` is safe and has no effect.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_STREAM_CIPHER
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a stream cipher.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a stream cipher algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier or if it is not a symmetric cipher algorithm.
+
+    A stream cipher is a symmetric cipher that encrypts or decrypts messages by applying a bitwise-xor with a stream of bytes that is generated from a key.
+
+.. macro:: PSA_CIPHER_ENCRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum size of the output of `psa_cipher_encrypt()`, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        A cipher algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+    .. param:: input_length
+        Size of the input in bytes.
+
+    .. return::
+        A sufficient output size for the specified key type and algorithm. If the key type or cipher algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and cipher algorithm that it recognizes, but does not support.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_encrypt()` will not fail due to an insufficient buffer size. Depending on the algorithm, the actual size of the output might be smaller.
+
+    See also `PSA_CIPHER_ENCRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_CIPHER_ENCRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_cipher_encrypt()`, for any of the supported key types and cipher algorithms.
+
+    .. param:: input_length
+        Size of the input in bytes.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_encrypt()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_CIPHER_ENCRYPT_OUTPUT_SIZE()`.
+
+.. macro:: PSA_CIPHER_DECRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum size of the output of `psa_cipher_decrypt()`, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        A cipher algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+    .. param:: input_length
+        Size of the input in bytes.
+
+    .. return::
+        A sufficient output size for the specified key type and algorithm. If the key type or cipher algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and cipher algorithm that it recognizes, but does not support.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_decrypt()` will not fail due to an insufficient buffer size. Depending on the algorithm, the actual size of the output might be smaller.
+
+    See also `PSA_CIPHER_DECRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_CIPHER_DECRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_cipher_decrypt()`, for any of the supported key types and cipher algorithms.
+
+    .. param:: input_length
+        Size of the input in bytes.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_decrypt()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_CIPHER_DECRYPT_OUTPUT_SIZE()`.
+
+.. macro:: PSA_CIPHER_IV_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The default IV size for a cipher algorithm, in bytes.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        A cipher algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+
+    .. return::
+        The default IV size for the specified key type and algorithm.
+        If the algorithm does not use an IV, return ``0``.
+        If the key type or cipher algorithm is not recognized, or the parameters are incompatible, return ``0``.
+        An implementation can return either ``0`` or a correct size for a key type and cipher algorithm that it recognizes, but does not support.
+
+    The IV that is generated as part of a call to `psa_cipher_encrypt()` is always the default IV length for the algorithm.
+
+    This macro can be used to allocate a buffer of sufficient size to store the IV output from `psa_cipher_generate_iv()` when using a multi-part cipher operation.
+
+    See also `PSA_CIPHER_IV_MAX_SIZE`.
+
+.. macro:: PSA_CIPHER_IV_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum IV size for all supported cipher algorithms, in bytes.
+
+    See also `PSA_CIPHER_IV_LENGTH()`.
+
+.. macro:: PSA_CIPHER_UPDATE_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_cipher_update()`.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        A cipher algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+    .. param:: input_length
+        Size of the input in bytes.
+
+    .. return::
+        A sufficient output size for the specified key type and algorithm. If the key type or cipher algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and cipher algorithm that it recognizes, but does not support.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_update()` will not fail due to an insufficient buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_CIPHER_UPDATE_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_CIPHER_UPDATE_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_cipher_update()`, for any of the supported key types and cipher algorithms.
+
+    .. param:: input_length
+        Size of the input in bytes.
+
+    If the size of the output buffer is at least this large, it is guaranteed that `psa_cipher_update()` will not fail due to an insufficient buffer size.
+
+    See also `PSA_CIPHER_UPDATE_OUTPUT_SIZE()`.
+
+.. macro:: PSA_CIPHER_FINISH_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient ciphertext buffer size for `psa_cipher_finish()`.
+
+    .. param:: key_type
+        A symmetric key type that is compatible with algorithm ``alg``.
+    .. param:: alg
+        A cipher algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_CIPHER(alg)` is true).
+
+    .. return::
+        A sufficient output size for the specified key type and algorithm. If the key type or cipher algorithm is not recognized, or the parameters are incompatible, return ``0``. An implementation can return either ``0`` or a correct size for a key type and cipher algorithm that it recognizes, but does not support.
+
+    If the size of the ciphertext buffer is at least this large, it is guaranteed that `psa_cipher_finish()` will not fail due to an insufficient ciphertext buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_CIPHER_FINISH_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_CIPHER_FINISH_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient ciphertext buffer size for `psa_cipher_finish()`, for any of the supported key types and cipher algorithms.
+
+    See also `PSA_CIPHER_FINISH_OUTPUT_SIZE()`.
+
+.. macro:: PSA_BLOCK_CIPHER_BLOCK_LENGTH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        The block size of a block cipher.
+
+    .. param:: type
+        A cipher key type (value of type `psa_key_type_t`).
+
+    .. return::
+        The block size for a block cipher, or ``1`` for a stream cipher. The return value is undefined if ``type`` is not a supported cipher key type.
+
+    .. note::
+        It is possible to build stream cipher algorithms on top of a block cipher, for example CTR mode (`PSA_ALG_CTR`). This macro only takes the key type into account, so it cannot be used to determine the size of the data that `psa_cipher_update()` might buffer for future processing in general.
+
+    .. note::
+        This macro expression is a compile-time constant if ``type`` is a compile-time constant.
+
+    .. warning::
+        This macro is permitted to evaluate its argument multiple times.
+
+    See also `PSA_BLOCK_CIPHER_BLOCK_MAX_SIZE`.
+
+.. macro:: PSA_BLOCK_CIPHER_BLOCK_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The maximum size of a block cipher supported by the implementation.
+
+    See also `PSA_BLOCK_CIPHER_BLOCK_LENGTH()`.
diff --git a/docs/html/_sources/api/ops/hashes.rst.txt b/docs/html/_sources/api/ops/hashes.rst.txt
new file mode 100644
index 0000000..dceaf22
--- /dev/null
+++ b/docs/html/_sources/api/ops/hashes.rst.txt
@@ -0,0 +1,755 @@
+.. _hashes:
+
+Message digests
+===============
+
+.. _hash-algorithms:
+
+Hash algorithms
+---------------
+
+.. macro:: PSA_ALG_MD2
+    :definition: ((psa_algorithm_t)0x02000001)
+
+    .. summary::
+        MD2.
+
+    .. warning::
+        The MD2 hash is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ALG_MD4
+    :definition: ((psa_algorithm_t)0x02000002)
+
+    .. summary::
+        MD4.
+
+    .. warning::
+        The MD4 hash is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ALG_MD5
+    :definition: ((psa_algorithm_t)0x02000003)
+
+    .. summary::
+        MD5.
+
+    .. warning::
+        The MD5 hash is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ALG_RIPEMD160
+    :definition: ((psa_algorithm_t)0x02000004)
+
+    .. summary::
+        RIPEMD-160.
+
+.. macro:: PSA_ALG_SHA_1
+    :definition: ((psa_algorithm_t)0x02000005)
+
+    .. summary::
+        SHA-1.
+
+    .. warning::
+        The SHA-1 hash is weak and deprecated and is only recommended for use in legacy protocols.
+
+.. macro:: PSA_ALG_SHA_224
+    :definition: ((psa_algorithm_t)0x02000008)
+
+    .. summary::
+        SHA-224.
+
+.. macro:: PSA_ALG_SHA_256
+    :definition: ((psa_algorithm_t)0x02000009)
+
+    .. summary::
+        SHA-256.
+
+.. macro:: PSA_ALG_SHA_384
+    :definition: ((psa_algorithm_t)0x0200000a)
+
+    .. summary::
+        SHA-384.
+
+.. macro:: PSA_ALG_SHA_512
+    :definition: ((psa_algorithm_t)0x0200000b)
+
+    .. summary::
+        SHA-512.
+
+.. macro:: PSA_ALG_SHA_512_224
+    :definition: ((psa_algorithm_t)0x0200000c)
+
+    .. summary::
+        SHA-512/224.
+
+.. macro:: PSA_ALG_SHA_512_256
+    :definition: ((psa_algorithm_t)0x0200000d)
+
+    .. summary::
+        SHA-512/256.
+
+.. macro:: PSA_ALG_SHA3_224
+    :definition: ((psa_algorithm_t)0x02000010)
+
+    .. summary::
+        SHA3-224.
+
+.. macro:: PSA_ALG_SHA3_256
+    :definition: ((psa_algorithm_t)0x02000011)
+
+    .. summary::
+        SHA3-256.
+
+.. macro:: PSA_ALG_SHA3_384
+    :definition: ((psa_algorithm_t)0x02000012)
+
+    .. summary::
+        SHA3-384.
+
+.. macro:: PSA_ALG_SHA3_512
+    :definition: ((psa_algorithm_t)0x02000013)
+
+    .. summary::
+        SHA3-512.
+
+Single-part hashing functions
+-----------------------------
+
+.. function:: psa_hash_compute
+
+    .. summary::
+        Calculate the hash (digest) of a message.
+
+    .. param:: psa_algorithm_t alg
+        The hash algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the message to hash.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * hash
+        Buffer where the hash is to be written.
+    .. param:: size_t hash_size
+        Size of the ``hash`` buffer in bytes.
+        This must be at least :code:`PSA_HASH_LENGTH(alg)`.
+    .. param:: size_t * hash_length
+        On success, the number of bytes that make up the hash value. This is always :code:`PSA_HASH_LENGTH(alg)`.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a hash algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        ``hash_size`` is too small.
+        `PSA_HASH_LENGTH()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    .. note::
+        To verify the hash of a message against an expected value, use `psa_hash_compare()` instead.
+
+.. function:: psa_hash_compare
+
+    .. summary::
+        Calculate the hash (digest) of a message and compare it with a reference value.
+
+    .. param:: psa_algorithm_t alg
+        The hash algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the message to hash.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: const uint8_t * hash
+        Buffer containing the expected hash value.
+    .. param:: size_t hash_length
+        Size of the ``hash`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The expected hash is identical to the actual hash of the input.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The hash of the message was calculated successfully, but it differs from the expected hash.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a hash algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``input_length`` or ``hash_length`` do not match the hash size for ``alg``
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+.. _hash-mp:
+
+Multi-part hashing operations
+-----------------------------
+
+.. typedef:: /* implementation-defined type */ psa_hash_operation_t
+
+    .. summary::
+        The type of the state object for multi-part hash operations.
+
+    Before calling any function on a hash operation object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_hash_operation_t operation;
+          memset(&operation, 0, sizeof(operation));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_hash_operation_t operation;
+
+    * Initialize the object to the initializer `PSA_HASH_OPERATION_INIT`, for example:
+
+      .. autocode::
+          psa_hash_operation_t operation = PSA_HASH_OPERATION_INIT;
+
+    * Assign the result of the function `psa_hash_operation_init()` to the object, for example:
+
+      .. autocode::
+          psa_hash_operation_t operation;
+          operation = psa_hash_operation_init();
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+.. macro:: PSA_HASH_OPERATION_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for a hash operation object of type `psa_hash_operation_t`.
+
+.. function:: psa_hash_operation_init
+
+    .. summary::
+        Return an initial value for a hash operation object.
+
+    .. return:: psa_hash_operation_t
+
+.. function:: psa_hash_setup
+
+    .. summary::
+        Set up a multi-part hash operation.
+
+    .. param:: psa_hash_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_hash_operation_t` and not yet in use.
+    .. param:: psa_algorithm_t alg
+        The hash algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not a supported hash algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``alg`` is not a hash algorithm.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The sequence of operations to calculate a hash (message digest) is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_hash_operation_t`, e.g. `PSA_HASH_OPERATION_INIT`.
+    #. Call `psa_hash_setup()` to specify the algorithm.
+    #. Call `psa_hash_update()` zero, one or more times, passing a fragment of the message each time. The hash that is calculated is the hash of the concatenation of these messages in order.
+    #. To calculate the hash, call `psa_hash_finish()`. To compare the hash with an expected value, call `psa_hash_verify()`. To suspend the hash operation and extract the current state, call `psa_hash_suspend()`.
+
+    If an error occurs at any step after a call to `psa_hash_setup()`, the operation will need to be reset by a call to `psa_hash_abort()`. The application can call `psa_hash_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_hash_setup()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_hash_finish()` or `psa_hash_verify()` or `psa_hash_suspend()`.
+    * A call to `psa_hash_abort()`.
+
+.. function:: psa_hash_update
+
+    .. summary::
+        Add a message fragment to a multi-part hash operation.
+
+    .. param:: psa_hash_operation_t * operation
+        Active hash operation.
+    .. param:: const uint8_t * input
+        Buffer containing the message fragment to hash.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_hash_setup()` or `psa_hash_resume()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_hash_abort()`.
+
+.. function:: psa_hash_finish
+
+    .. summary::
+        Finish the calculation of the hash of a message.
+
+    .. param:: psa_hash_operation_t * operation
+        Active hash operation.
+    .. param:: uint8_t * hash
+        Buffer where the hash is to be written.
+    .. param:: size_t hash_size
+        Size of the ``hash`` buffer in bytes. This must be at least :code:`PSA_HASH_LENGTH(alg)` where ``alg`` is the algorithm that the operation performs.
+    .. param:: size_t * hash_length
+        On success, the number of bytes that make up the hash value. This is always :code:`PSA_HASH_LENGTH(alg)` where ``alg`` is the hash algorithm that the operation performs.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``hash`` buffer is too small.
+        `PSA_HASH_LENGTH()` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_hash_setup()` or `psa_hash_resume()` before calling this function. This function calculates the hash of the message formed by concatenating the inputs passed to preceding calls to `psa_hash_update()`.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_hash_abort()`.
+
+    .. warning::
+        It is not recommended to use this function when a specific value is expected for the hash. Call `psa_hash_verify()` instead with the expected hash value.
+
+        Comparing integrity or authenticity data such as hash values with a function such as ``memcmp()`` is risky because the time taken by the comparison might leak information about the hashed data which could allow an attacker to guess a valid hash and thereby bypass security controls.
+
+.. function:: psa_hash_verify
+
+    .. summary::
+        Finish the calculation of the hash of a message and compare it with an expected value.
+
+    .. param:: psa_hash_operation_t * operation
+        Active hash operation.
+    .. param:: const uint8_t * hash
+        Buffer containing the expected hash value.
+    .. param:: size_t hash_length
+        Size of the ``hash`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The expected hash is identical to the actual hash of the message.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The hash of the message was calculated successfully, but it differs from the expected hash.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_hash_setup()` before calling this function. This function calculates the hash of the message formed by concatenating the inputs passed to preceding calls to `psa_hash_update()`. It then compares the calculated hash with the expected hash passed as a parameter to this function.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_hash_abort()`.
+
+    .. note::
+        Implementations must make the best effort to ensure that the comparison between the actual hash and the expected hash is performed in constant time.
+
+.. function:: psa_hash_abort
+
+    .. summary::
+        Abort a hash operation.
+
+    .. param:: psa_hash_operation_t * operation
+        Initialized hash operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Aborting an operation frees all associated resources except for the ``operation`` object itself. Once aborted, the operation object can be reused for another operation by calling `psa_hash_setup()` again.
+
+    This function can be called any time after the operation object has been initialized by one of the methods described in `psa_hash_operation_t`.
+
+    In particular, calling `psa_hash_abort()` after the operation has been terminated by a call to `psa_hash_abort()`, `psa_hash_finish()` or `psa_hash_verify()` is safe and has no effect.
+
+.. function:: psa_hash_suspend
+
+    .. summary::
+        Halt the hash operation and extract the intermediate state of the hash computation.
+
+    .. param:: psa_hash_operation_t * operation
+        Active hash operation.
+    .. param:: uint8_t * hash_state
+        Buffer where the hash suspend state is to be written.
+    .. param:: size_t hash_state_size
+        Size of the ``hash_state`` buffer in bytes.
+        This must be appropriate for the selected algorithm:
+
+        * A sufficient output size is :code:`PSA_HASH_SUSPEND_OUTPUT_SIZE(alg)`  where ``alg`` is the algorithm that was used to set up the operation.
+        * `PSA_HASH_SUSPEND_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported hash algorithm.
+
+    .. param:: size_t * hash_state_length
+        On success, the number of bytes that make up the hash suspend state.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``hash_state`` buffer is too small.
+        `PSA_HASH_SUSPEND_OUTPUT_SIZE()` or `PSA_HASH_SUSPEND_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        The hash algorithm being computed does not support suspend and resume.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_hash_setup()` or `psa_hash_resume()` before calling this function. This function extracts an intermediate state of the hash computation of the message formed by concatenating the inputs passed to preceding calls to `psa_hash_update()`.
+
+    This function can be used to halt a hash operation, and then resume the hash operation at a later time, or in another application, by transferring the extracted hash suspend state to a call to `psa_hash_resume()`.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_hash_abort()`.
+
+    Hash suspend and resume is not defined for the SHA3 family of hash algorithms. :title:`hash-suspend-state` defines the format of the output from `psa_hash_suspend()`.
+
+    .. warning::
+        Applications must not use any of the hash suspend state as if it was a hash output. Instead, the suspend state must only be used to resume a hash operation, and `psa_hash_finish()` or `psa_hash_verify()` can then calculate or verify the final hash value.
+
+    .. rubric:: Usage
+
+    The sequence of operations to suspend and resume a hash operation is as follows:
+
+    #. Compute the first part of the hash.
+
+        #. Allocate an operation object and initialize it as described in the documentation for `psa_hash_operation_t`.
+        #. Call `psa_hash_setup()` to specify the algorithm.
+        #. Call `psa_hash_update()` zero, one or more times, passing a fragment of the message each time.
+        #. Call `psa_hash_suspend()` to extract the hash suspend state into a buffer.
+
+    #. Pass the hash state buffer to the application which will resume the operation.
+
+    #. Compute the rest of the hash.
+
+        #. Allocate an operation object and initialize it as described in the documentation for `psa_hash_operation_t`.
+        #. Call `psa_hash_resume()` with the extracted hash state.
+        #. Call `psa_hash_update()` zero, one or more times, passing a fragment of the message each time.
+        #. To calculate the hash, call `psa_hash_finish()`. To compare the hash with an expected value, call `psa_hash_verify()`.
+
+    If an error occurs at any step after a call to `psa_hash_setup()` or `psa_hash_resume()`, the operation will need to be reset by a call to `psa_hash_abort()`. The application can call `psa_hash_abort()` at any time after the operation has been initialized.
+
+.. function:: psa_hash_resume
+
+    .. summary::
+        Set up a multi-part hash operation using the hash suspend state from a previously suspended hash operation.
+
+    .. param:: psa_hash_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_hash_operation_t` and not yet in use.
+    .. param:: const uint8_t * hash_state
+        A buffer containing the suspended hash state which is to be resumed. This must be in the format output by `psa_hash_suspend()`, which is described in :title:`hash-suspend-state-format`.
+    .. param:: size_t hash_state_length
+        Length of ``hash_state`` in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        The provided hash suspend state is for an algorithm that is not supported.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``hash_state`` does not correspond to a valid hash suspend state. See :title:`hash-suspend-state-format` for the definition.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    See `psa_hash_suspend()` for an example of how to use this function to suspend and resume a hash operation.
+
+    After a successful call to `psa_hash_resume()`, the application must eventually terminate the operation. The following events terminate an operation:
+
+    * A successful call to `psa_hash_finish()`, `psa_hash_verify()` or `psa_hash_suspend()`.
+    * A call to `psa_hash_abort()`.
+
+.. function:: psa_hash_clone
+
+    .. summary::
+        Clone a hash operation.
+
+    .. param:: const psa_hash_operation_t * source_operation
+        The active hash operation to clone.
+    .. param:: psa_hash_operation_t * target_operation
+        The operation object to set up. It must be initialized but not active.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_BAD_STATE
+        The ``source_operation`` state is not valid: it must be active.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The ``target_operation`` state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function copies the state of an ongoing hash operation to a new operation object. In other words, this function is equivalent to calling `psa_hash_setup()` on ``target_operation`` with the same algorithm that ``source_operation`` was set up for, then `psa_hash_update()` on ``target_operation`` with the same input that that was passed to ``source_operation``. After this function returns, the two objects are independent, i.e. subsequent calls involving one of the objects do not affect the other object.
+
+Support macros
+--------------
+
+.. macro:: PSA_HASH_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The size of the output of `psa_hash_compute()` and `psa_hash_finish()`, in bytes.
+
+    .. param:: alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true), or an HMAC algorithm (:code:`PSA_ALG_HMAC(hash_alg)` where ``hash_alg`` is a hash algorithm).
+
+    .. return::
+        The hash length for the specified hash algorithm. If the hash algorithm is not recognized, return ``0``. An implementation can return either ``0`` or the correct size for a hash algorithm that it recognizes, but does not support.
+
+    This is also the hash length that `psa_hash_compare()` and `psa_hash_verify()` expect.
+
+    See also `PSA_HASH_MAX_SIZE`.
+
+.. macro:: PSA_HASH_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Maximum size of a hash.
+
+    This macro must expand to a compile-time constant integer.
+    It is recommended that this value is the maximum size of a hash supported by the implementation, in bytes. The value must not be smaller than this maximum.
+
+    See also `PSA_HASH_LENGTH()`.
+
+.. macro:: PSA_HASH_SUSPEND_OUTPUT_SIZE
+    :definition: /* specification-defined value */
+
+    .. summary::
+        A sufficient hash suspend state buffer size for `psa_hash_suspend()`.
+
+    .. param:: alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+
+    .. return::
+        A sufficient output size for the algorithm. If the hash algorithm is not recognized, or is not supported by `psa_hash_suspend()`, return ``0``. An implementation can return either ``0`` or a correct size for a hash algorithm that it recognizes, but does not support.
+
+        For a supported hash algorithm ``alg``, the following expression is true:
+
+        .. autocode::
+            PSA_HASH_SUSPEND_OUTPUT_SIZE(alg) == PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH +
+                                                 PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH(alg) +
+                                                 PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH(alg) +
+                                                 PSA_HASH_BLOCK_LENGTH(alg) - 1
+
+    If the size of the hash state buffer is at least this large, it is guaranteed that `psa_hash_suspend()` will not fail due to an insufficient buffer size. The actual size of the output might be smaller in any given call.
+
+    See also `PSA_HASH_SUSPEND_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_HASH_SUSPEND_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient hash suspend state buffer size for `psa_hash_suspend()`, for any supported hash algorithms.
+
+    See also `PSA_HASH_SUSPEND_OUTPUT_SIZE()`.
+
+.. macro:: PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH
+    :definition: ((size_t)4)
+
+    .. summary::
+        The size of the *algorithm* field that is part of the output of `psa_hash_suspend()`, in bytes.
+
+    Applications can use this value to unpack the hash suspend state that is output by `psa_hash_suspend()`.
+
+.. macro:: PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        The size of the *input-length* field that is part of the output of `psa_hash_suspend()`, in bytes.
+
+    .. param:: alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+
+    .. return::
+        The size, in bytes, of the *input-length* field of the hash suspend state for the specified hash algorithm. If the hash algorithm is not recognized, return ``0``. An implementation can return either ``0`` or the correct size for a hash algorithm that it recognizes, but does not support.
+
+        The algorithm-specific values are defined in :title:`hash-suspend-state-constants`.
+
+    Applications can use this value to unpack the hash suspend state that is output by `psa_hash_suspend()`.
+
+.. macro:: PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        The size of the *hash-state* field that is part of the output of `psa_hash_suspend()`, in bytes.
+
+    .. param:: alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+
+    .. return::
+        The size, in bytes, of the *hash-state* field of the hash suspend state for the specified hash algorithm. If the hash algorithm is not recognized, return ``0``. An implementation can return either ``0`` or the correct size for a hash algorithm that it recognizes, but does not support.
+
+        The algorithm-specific values are defined in :title:`hash-suspend-state-constants`.
+
+    Applications can use this value to unpack the hash suspend state that is output by `psa_hash_suspend()`.
+
+.. macro:: PSA_HASH_BLOCK_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The input block size of a hash algorithm.
+
+    .. param:: alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(alg)` is true).
+
+    .. return::
+        The block size for the specified hash algorithm. If the hash algorithm is not recognized, return ``0``. An implementation can return either ``0`` or the correct size for a hash algorithm that it recognizes, but does not support.
+
+    Hash algorithms process their input data in blocks. Hash operations will retain any partial blocks until they have enough input to fill the block or until the operation is finished.
+
+    This affects the output from `psa_hash_suspend()`.
+
+
+.. _hash-suspend-state:
+
+Hash suspend state
+------------------
+
+The hash suspend state is output by `psa_hash_suspend()` and input to `psa_hash_resume()`.
+
+.. note::
+    Hash suspend and resume is not defined for the SHA3 family of hash algorithms.
+
+.. _hash-suspend-state-format:
+
+.. rubric:: Hash suspend state format
+
+The hash suspend state has the following format:
+
+*hash-suspend-state* = *algorithm* || *input-length* || *hash-state* || *unprocessed-input*
+
+The fields in the hash suspend state are defined as follows:
+
+.. tabularcolumns:: \Y{.25}\Y{.75}
+
+.. list-table::
+    :header-rows: 0
+    :widths: 1,3
+
+    *   -   *algorithm*
+
+            big-endian 32-bit unsigned integer
+
+        -   The PSA Crypto API algorithm identifier. Encoded as a big-endian 32-bit unsigned integer.
+
+            The byte length of the *algorithm* field can be evaluated using `PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH`.
+
+    *   -   *input-length*
+
+            big-endian unsigned integer
+
+        -   The content of this field is algorithm-specific:
+
+            - For MD2, this is the number of bytes in the *unprocessed-input*.
+            - For all other hash algorithms, this is the total number of bytes of input to the hash computation. This includes the *unprocessed-input* bytes.
+
+            The size of this field is algorithm-specific:
+
+            - For MD2: *input-length* is an 8-bit unsigned integer.
+            - For MD4, MD5, RIPEMD-160, SHA-1, SHA-224 and SHA-256: *input-length* is a 64-bit unsigned integer.
+            - For SHA-512, SHA-384 and SHA-512/256: *input-length* is a 128-bit unsigned integer.
+
+            The length, in bytes, of the *input-length* field can be calculated using :code:`PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH(alg)` where ``alg`` is a hash algorithm.
+            See :title:`hash-suspend-state-constants`.
+
+    *   -   *hash-state*
+
+            array of bytes
+
+        -   Algorithm-specific intermediate hash state:
+
+            - For MD2: 16 bytes of internal checksum, then 48 bytes of intermediate digest.
+            - For MD4 and MD5: 4x 32-bit integers, in little-endian encoding.
+            - For RIPEMD-160: 5x 32-bit integers, in little-endian encoding.
+            - For SHA-1: 5x 32-bit integers, in big-endian encoding.
+            - For SHA-224 and SHA-256: 8x 32-bit integers, in big-endian encoding.
+            - For SHA-512, SHA-384 and SHA-512/256: 8x 64-bit integers, in big-endian encoding.
+
+            The length of this field is specific to the algorithm.
+            The length, in bytes, of the *hash-state* field can be calculated using :code:`PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH(alg)` where ``alg`` is a hash algorithm.
+            See :title:`hash-suspend-state-constants`.
+
+    *   -   *unprocessed-input*
+
+            0 to (*hash-block-size*-1) bytes
+
+        -   A partial block of unprocessed input data. This is between zero and *hash-block-size*-1 bytes of data, the length can be calculated by:
+
+            ``length(``\ *unprocessed-input*\ ``)`` ``=`` *input-length* ``%`` *hash-block-size*.
+
+            The *hash-block-size* is specific to the algorithm.
+            The size of a hash block can be calculated using :code:`PSA_HASH_BLOCK_LENGTH(alg)` where ``alg`` is a hash algorithm.
+            See :title:`hash-suspend-state-constants`.
+
+.. _hash-suspend-state-constants:
+
+..  rubric:: Hash suspend state field sizes
+
+The following table defines the algorithm-specific field lengths for the hash suspend state returned by `psa_hash_suspend()`. All of the field lengths are in bytes. To compute the field lengths for algorithm ``alg``, use the following expressions:
+
+- :code:`PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH` returns the length of the *algorithm* field.
+- :code:`PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH(alg)` returns the length of the *input-length* field.
+- :code:`PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH(alg)` returns the length of the *hash-state* field.
+- :code:`PSA_HASH_BLOCK_LENGTH(alg)-1` is the maximum length of the *unprocessed-bytes* field.
+- :code:`PSA_HASH_SUSPEND_OUTPUT_SIZE(slg)` returns the maximum size of the hash suspend state.
+
+.. tabularcolumns:: LLLL
+
+.. csv-table::
+    :header-rows: 1
+
+    Hash algorithm, *input-length* size (bytes), *hash-state* length (bytes), *unprocessed-bytes* length (bytes)
+    `PSA_ALG_MD2`, 1, 64, 0 - 15
+    `PSA_ALG_MD4`, 8, 16, 0 - 63
+    `PSA_ALG_MD5`, 8, 16, 0 - 63
+    `PSA_ALG_RIPEMD160`, 8, 20, 0 - 63
+    `PSA_ALG_SHA_1`, 8, 20, 0 - 63
+    `PSA_ALG_SHA_224`, 8, 32, 0 - 63
+    `PSA_ALG_SHA_256`, 8, 32, 0 - 63
+    `PSA_ALG_SHA_512_256`, 16, 64, 0 - 127
+    `PSA_ALG_SHA_384`, 16, 64, 0 - 127
+    `PSA_ALG_SHA_512`, 16, 64, 0 - 127
diff --git a/docs/html/_sources/api/ops/index.rst.txt b/docs/html/_sources/api/ops/index.rst.txt
new file mode 100644
index 0000000..1e66853
--- /dev/null
+++ b/docs/html/_sources/api/ops/index.rst.txt
@@ -0,0 +1,17 @@
+.. _crypto-operations:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Cryptographic operation reference
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. toctree::
+
+    hashes
+    macs
+    ciphers
+    aead
+    kdf
+    sign
+    pke
+    ka
+    rng
diff --git a/docs/html/_sources/api/ops/ka.rst.txt b/docs/html/_sources/api/ops/ka.rst.txt
new file mode 100644
index 0000000..a85b7a4
--- /dev/null
+++ b/docs/html/_sources/api/ops/ka.rst.txt
@@ -0,0 +1,263 @@
+.. _key-agreement:
+
+Key agreement
+=============
+
+.. _key-agreement-algorithms:
+
+Key agreement algorithms
+------------------------
+
+.. macro:: PSA_ALG_KEY_AGREEMENT
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build a combined algorithm that chains a key agreement with a key derivation.
+
+    .. param:: ka_alg
+        A key agreement algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_KEY_AGREEMENT(ka_alg)` is true).
+    .. param:: kdf_alg
+        A key derivation algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_KEY_DERIVATION(kdf_alg)` is true).
+
+    .. return::
+        The corresponding key agreement and derivation algorithm.
+
+        Unspecified if ``ka_alg`` is not a supported key agreement algorithm or ``kdf_alg`` is not a supported key derivation algorithm.
+
+    The component parts of a key agreement algorithm can be extracted using `PSA_ALG_KEY_AGREEMENT_GET_BASE()` and `PSA_ALG_KEY_AGREEMENT_GET_KDF()`.
+
+.. macro:: PSA_ALG_FFDH
+    :definition: ((psa_algorithm_t)0x09010000)
+
+    .. summary::
+        The finite-field Diffie-Hellman (DH) key agreement algorithm.
+
+    The shared secret produced by key agreement is ``g^{ab}`` in big-endian format. It is ``ceiling(m / 8)`` bytes long where ``m`` is the size of the prime ``p`` in bits.
+
+.. macro:: PSA_ALG_ECDH
+    :definition: ((psa_algorithm_t)0x09020000)
+
+    .. summary::
+        The elliptic curve Diffie-Hellman (ECDH) key agreement algorithm.
+
+    The shared secret produced by key agreement is the x-coordinate of the shared secret point. It is always ``ceiling(m / 8)`` bytes long where ``m`` is the bit size associated with the curve, i.e. the bit size of the order of the curve's coordinate field. When ``m`` is not a multiple of 8, the byte containing the most significant bit of the shared secret is padded with zero bits. The byte order is either little-endian or big-endian depending on the curve type.
+
+    * For Montgomery curves (curve family `PSA_ECC_FAMILY_MONTGOMERY`), the shared secret is the x-coordinate of ``d_A Q_B = d_B Q_A`` in little-endian byte order. The bit size is 448 for Curve448 and 255 for Curve25519.
+    * For Weierstrass curves over prime fields (curve families ``PSA_ECC_FAMILY_SECP_XX``, `PSA_ECC_FAMILY_BRAINPOOL_P_R1` and `PSA_ECC_FAMILY_FRP`), the shared secret is the x-coordinate of ``d_A Q_B = d_B Q_A`` in big-endian byte order. The bit size is ``m = ceiling(log_2(p))`` for the field ``F_p``.
+    * For Weierstrass curves over binary fields (curve families ``PSA_ECC_FAMILY_SECT_XX``), the shared secret is the x-coordinate of ``d_A Q_B = d_B Q_A`` in big-endian byte order. The bit size is ``m`` for the field ``F_{2^m}``.
+
+Standalone key agreement
+------------------------
+
+.. function:: psa_raw_key_agreement
+
+    .. summary::
+        Perform a key agreement and return the raw shared secret.
+
+    .. param:: psa_algorithm_t alg
+        The key agreement algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_RAW_KEY_AGREEMENT(alg)` is true).
+    .. param:: psa_key_id_t private_key
+        Identifier of the private key to use.
+        It must allow the usage `PSA_KEY_USAGE_DERIVE`.
+    .. param:: const uint8_t * peer_key
+        Public key of the peer. It must be in the same format that `psa_import_key()` accepts. The standard formats for public keys are documented in the documentation of `psa_export_public_key()`.
+    .. param:: size_t peer_key_length
+        Size of ``peer_key`` in bytes.
+    .. param:: uint8_t * output
+        Buffer where the decrypted message is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes.
+        This must be appropriate for the keys:
+
+        * The required output size is :code:`PSA_RAW_KEY_AGREEMENT_OUTPUT_SIZE(type, bits)` where ``type`` is the type of ``private_key`` and ``bits`` is the bit-size of either ``private_key`` or the ``peer_key``.
+        * `PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported raw key agreement algorithm.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DERIVE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``alg`` is not a key agreement algorithm
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``private_key`` is not compatible with ``alg``, or ``peer_key`` is not valid for ``alg`` or not compatible with ``private_key``.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small.
+        `PSA_RAW_KEY_AGREEMENT_OUTPUT_SIZE()` or `PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not a supported key agreement algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    .. warning::
+        The raw result of a key agreement algorithm such as finite-field Diffie-Hellman or elliptic curve Diffie-Hellman has biases, and is not suitable for use as key material. Instead it is recommended that the result is used as input to a key derivation algorithm. To chain a key agreement with a key derivation, use `psa_key_derivation_key_agreement()` and other functions from the key derivation interface.
+
+Combining key agreement and key derivation
+------------------------------------------
+
+.. function:: psa_key_derivation_key_agreement
+
+    .. summary::
+        Perform a key agreement and use the shared secret as input to a key derivation.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to use. It must have been set up with `psa_key_derivation_setup()` with a key agreement and derivation algorithm ``alg`` (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_KEY_AGREEMENT(alg)` is true and :code:`PSA_ALG_IS_RAW_KEY_AGREEMENT(alg)` is false). The operation must be ready for an input of the type given by ``step``.
+    .. param:: psa_key_derivation_step_t step
+        Which step the input data is for.
+    .. param:: psa_key_id_t private_key
+        Identifier of the private key to use.
+        It must allow the usage `PSA_KEY_USAGE_DERIVE`.
+    .. param:: const uint8_t * peer_key
+        Public key of the peer. The peer key must be in the same format that `psa_import_key()` accepts for the public key type corresponding to the type of private_key. That is, this function performs the equivalent of :code:`psa_import_key(..., peer_key, peer_key_length)` where with key attributes indicating the public key type corresponding to the type of ``private_key``. For example, for EC keys, this means that peer_key is interpreted as a point on the curve that the private key is on. The standard formats for public keys are documented in the documentation of `psa_export_public_key()`.
+    .. param:: size_t peer_key_length
+        Size of ``peer_key`` in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid for this key agreement ``step``.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DERIVE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``private_key`` is not compatible with ``alg``, or ``peer_key`` is not valid for ``alg`` or not compatible with ``private_key``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a key derivation algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``step`` does not allow an input resulting from a key agreement.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    A key agreement algorithm takes two inputs: a private key ``private_key`` a public key ``peer_key``. The result of this function is passed as input to a key derivation. The output of this key derivation can be extracted by reading from the resulting operation to produce keys and other cryptographic material.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_key_derivation_abort()`.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_KEY_AGREEMENT_GET_BASE
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Get the raw key agreement algorithm from a full key agreement algorithm.
+
+    .. param:: alg
+        A key agreement algorithm identifier (value of type `psa_algorithm_t` such that :code:`PSA_ALG_IS_KEY_AGREEMENT(alg)` is true).
+
+    .. return::
+        The underlying raw key agreement algorithm if ``alg`` is a key agreement algorithm.
+
+        Unspecified if ``alg`` is not a key agreement algorithm or if it is not supported by the implementation.
+
+    See also `PSA_ALG_KEY_AGREEMENT()` and `PSA_ALG_KEY_AGREEMENT_GET_KDF()`.
+
+.. macro:: PSA_ALG_KEY_AGREEMENT_GET_KDF
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Get the key derivation algorithm used in a full key agreement algorithm.
+
+    .. param:: alg
+        A key agreement algorithm identifier (value of type `psa_algorithm_t` such that :code:`PSA_ALG_IS_KEY_AGREEMENT(alg)` is true).
+
+    .. return::
+        The underlying key derivation algorithm if ``alg`` is a key agreement algorithm.
+
+        Unspecified if ``alg`` is not a key agreement algorithm or if it is not supported by the implementation.
+
+    See also `PSA_ALG_KEY_AGREEMENT()` and `PSA_ALG_KEY_AGREEMENT_GET_BASE()`.
+
+.. macro:: PSA_ALG_IS_RAW_KEY_AGREEMENT
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a raw key agreement algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a raw key agreement algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    A raw key agreement algorithm is one that does not specify a key derivation function. Usually, raw key agreement algorithms are constructed directly with a ``PSA_ALG_xxx`` macro while non-raw key agreement algorithms are constructed with `PSA_ALG_KEY_AGREEMENT()`.
+
+    The raw key agreement algorithm can be extracted from a full key agreement algorithm identifier using `PSA_ALG_KEY_AGREEMENT_GET_BASE()`.
+
+.. macro:: PSA_ALG_IS_FFDH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a finite field Diffie-Hellman algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a finite field Diffie-Hellman algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported key agreement algorithm identifier.
+
+    This includes the raw finite field Diffie-Hellman algorithm as well as finite-field Diffie-Hellman followed by any supporter key derivation algorithm.
+
+.. macro:: PSA_ALG_IS_ECDH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an elliptic curve Diffie-Hellman algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an elliptic curve Diffie-Hellman algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported key agreement algorithm identifier.
+
+    This includes the raw elliptic curve Diffie-Hellman algorithm as well as elliptic curve Diffie-Hellman followed by any supporter key derivation algorithm.
+
+.. macro:: PSA_RAW_KEY_AGREEMENT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient output buffer size for `psa_raw_key_agreement()`.
+
+    .. param:: key_type
+        A supported key type.
+    .. param:: key_bits
+        The size of the key in bits.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_raw_key_agreement()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+    This macro returns a compile-time constant if its arguments are compile-time constants.
+
+    .. warning::
+        This function might evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    See also `PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Maximum size of the output from `psa_raw_key_agreement()`.
+
+    This macro must expand to a compile-time constant integer.
+    It is recommended that this value is the maximum size of the output any raw key agreement algorithm supported by the implementation, in bytes. The value must not be smaller than this maximum.
+
+    See also `PSA_RAW_KEY_AGREEMENT_OUTPUT_SIZE()`.
diff --git a/docs/html/_sources/api/ops/kdf.rst.txt b/docs/html/_sources/api/ops/kdf.rst.txt
new file mode 100644
index 0000000..62267a3
--- /dev/null
+++ b/docs/html/_sources/api/ops/kdf.rst.txt
@@ -0,0 +1,563 @@
+.. _kdf:
+
+Key derivation
+==============
+
+.. _key-derivation-algorithms:
+
+Key derivation algorithms
+-------------------------
+
+.. macro:: PSA_ALG_HKDF
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build an HKDF algorithm.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true).
+
+    .. return::
+        The corresponding HKDF algorithm. For example, :code:`PSA_ALG_HKDF(PSA_ALG_SHA_256)` is HKDF using HMAC-SHA-256.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This key derivation algorithm uses the following inputs:
+
+    * `PSA_KEY_DERIVATION_INPUT_SALT` is the salt used in the "extract" step. It is optional; if omitted, the derivation uses an empty salt.
+    * `PSA_KEY_DERIVATION_INPUT_SECRET` is the secret key used in the "extract" step.
+    * `PSA_KEY_DERIVATION_INPUT_INFO` is the info string used in the "expand" step.
+
+    If `PSA_KEY_DERIVATION_INPUT_SALT` is provided, it must be before `PSA_KEY_DERIVATION_INPUT_SECRET`. `PSA_KEY_DERIVATION_INPUT_INFO` can be provided at any time after setup and before starting to generate output.
+
+.. macro:: PSA_ALG_TLS12_PRF
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build a TLS-1.2 PRF algorithm.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true).
+
+    .. return::
+        The corresponding TLS-1.2 PRF algorithm. For example, :code:`PSA_ALG_TLS12_PRF(PSA_ALG_SHA_256)` represents the TLS 1.2 PRF using HMAC-SHA-256.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    TLS 1.2 uses a custom pseudorandom function (PRF) for key schedule, specified in :RFC:`5246#5`. It is based on HMAC and can be used with either SHA-256 or SHA-384.
+
+    This key derivation algorithm uses the following inputs, which must be passed in the order given here:
+
+    * `PSA_KEY_DERIVATION_INPUT_SEED` is the seed.
+    * `PSA_KEY_DERIVATION_INPUT_SECRET` is the secret key.
+    * `PSA_KEY_DERIVATION_INPUT_LABEL` is the label.
+
+    For the application to TLS-1.2 key expansion:
+
+    * The seed is the concatenation of ``ServerHello.Random + ClientHello.Random``.
+    * The label is ``"key expansion"``.
+
+.. macro:: PSA_ALG_TLS12_PSK_TO_MS
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build a TLS-1.2 PSK-to-MasterSecret algorithm.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true).
+
+    .. return::
+        The corresponding TLS-1.2 PSK to MS algorithm. For example, :code:`PSA_ALG_TLS12_PSK_TO_MS(PSA_ALG_SHA_256)` represents the TLS-1.2 PSK to MasterSecret derivation PRF using HMAC-SHA-256.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    In a pure-PSK handshake in TLS 1.2, the master secret (MS) is derived from the pre-shared key (PSK) through the application of padding (:RFC:`4279#2`) and the TLS-1.2 PRF (:RFC:`5246#5`). The latter is based on HMAC and can be used with either SHA-256 or SHA-384.
+
+    This key derivation algorithm uses the following inputs, which must be passed in the order given here:
+
+    * `PSA_KEY_DERIVATION_INPUT_SEED` is the seed.
+    * `PSA_KEY_DERIVATION_INPUT_SECRET` is the PSK. The PSK must not be larger than `PSA_TLS12_PSK_TO_MS_PSK_MAX_SIZE`.
+    * `PSA_KEY_DERIVATION_INPUT_LABEL` is the label.
+
+    For the application to TLS-1.2:
+
+    * The seed, which is forwarded to the TLS-1.2 PRF, is the concatenation of the ``ClientHello.Random + ServerHello.Random``.
+    * The label is ``"master secret"`` or ``"extended master secret"``.
+
+Input step types
+----------------
+
+.. typedef:: uint16_t psa_key_derivation_step_t
+
+    .. summary::
+        Encoding of the step of a key derivation.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_SECRET
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A secret input for key derivation.
+
+    This is typically a key of type `PSA_KEY_TYPE_DERIVE` passed to `psa_key_derivation_input_key()`, or the shared secret resulting from a key agreement obtained via `psa_key_derivation_key_agreement()`.
+
+    The secret can also be a direct input passed to `psa_key_derivation_input_bytes()`. In this case, the derivation operation cannot be used to derive keys: the operation will only allow `psa_key_derivation_output_bytes()`, not `psa_key_derivation_output_key()`.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_LABEL
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A label for key derivation.
+
+    This is typically a direct input. It can also be a key of type `PSA_KEY_TYPE_RAW_DATA`.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_CONTEXT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A context for key derivation.
+
+    This is typically a direct input. It can also be a key of type `PSA_KEY_TYPE_RAW_DATA`.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_SALT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A salt for key derivation.
+
+    This is typically a direct input. It can also be a key of type `PSA_KEY_TYPE_RAW_DATA`.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_INFO
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        An information string for key derivation.
+
+    This is typically a direct input. It can also be a key of type `PSA_KEY_TYPE_RAW_DATA`.
+
+.. macro:: PSA_KEY_DERIVATION_INPUT_SEED
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A seed for key derivation.
+
+    This is typically a direct input. It can also be a key of type `PSA_KEY_TYPE_RAW_DATA`.
+
+Key derivation functions
+------------------------
+
+.. typedef:: /* implementation-defined type */ psa_key_derivation_operation_t
+
+    .. summary::
+        The type of the state object for key derivation operations.
+
+    Before calling any function on a key derivation operation object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_key_derivation_operation_t operation;
+          memset(&operation, 0, sizeof(operation));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_key_derivation_operation_t operation;
+
+    * Initialize the object to the initializer `PSA_KEY_DERIVATION_OPERATION_INIT`, for example:
+
+      .. autocode::
+          psa_key_derivation_operation_t operation = PSA_KEY_DERIVATION_OPERATION_INIT;
+
+    * Assign the result of the function `psa_key_derivation_operation_init()` to the object, for example:
+
+      .. autocode::
+          psa_key_derivation_operation_t operation;
+          operation = psa_key_derivation_operation_init();
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+.. macro:: PSA_KEY_DERIVATION_OPERATION_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for a key derivation operation object of type `psa_key_derivation_operation_t`.
+
+.. function:: psa_key_derivation_operation_init
+
+    .. summary::
+        Return an initial value for a key derivation operation object.
+
+    .. return:: psa_key_derivation_operation_t
+
+.. function:: psa_key_derivation_setup
+
+    .. summary::
+        Set up a key derivation operation.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to set up. It must have been initialized but not set up yet.
+    .. param:: psa_algorithm_t alg
+        The key derivation algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_KEY_DERIVATION(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``alg`` is not a key derivation algorithm.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a key derivation algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    A key derivation algorithm takes some inputs and uses them to generate a byte stream in a deterministic way. This byte stream can be used to produce keys and other cryptographic material.
+
+    To derive a key:
+
+    #. Start with an initialized object of type `psa_key_derivation_operation_t`.
+    #. Call `psa_key_derivation_setup()` to select the algorithm.
+    #. Provide the inputs for the key derivation by calling `psa_key_derivation_input_bytes()` or `psa_key_derivation_input_key()` as appropriate. Which inputs are needed, in what order, whether keys are permitted, and what type of keys depends on the algorithm.
+    #. Optionally set the operation's maximum capacity with `psa_key_derivation_set_capacity()`. This can be done before, in the middle of, or after providing inputs. For some algorithms, this step is mandatory because the output depends on the maximum capacity.
+    #. To derive a key, call `psa_key_derivation_output_key()`. To derive a byte string for a different purpose, call `psa_key_derivation_output_bytes()`. Successive calls to these functions use successive output bytes calculated by the key derivation algorithm.
+    #. Clean up the key derivation operation object with `psa_key_derivation_abort()`.
+
+    If this function returns an error, the key derivation operation object is not changed.
+
+    If an error occurs at any step after a call to `psa_key_derivation_setup()`, the operation will need to be reset by a call to `psa_key_derivation_abort()`.
+
+    Implementations must reject an attempt to derive a key of size ``0``.
+
+.. function:: psa_key_derivation_get_capacity
+
+    .. summary::
+        Retrieve the current capacity of a key derivation operation.
+
+    .. param:: const psa_key_derivation_operation_t * operation
+        The operation to query.
+    .. param:: size_t * capacity
+        On success, the capacity of the operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The capacity of a key derivation is the maximum number of bytes that it can return. Reading *N* bytes of output from a key derivation operation reduces its capacity by at least *N*. The capacity can be reduced by more than *N* in the following situations:
+
+    - Calling `psa_key_derivation_output_key()` can reduce the capacity by more than the key size, depending on the type of key being generated. See  `psa_key_derivation_output_key()` for details of the key derivation process.
+    - When the `psa_key_derivation_operation_t` object is operating as a deterministic random bit generator (DBRG), which reduces capacity in whole blocks, even when less than a block is read.
+
+.. function:: psa_key_derivation_set_capacity
+
+    .. summary::
+        Set the maximum capacity of a key derivation operation.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to modify.
+    .. param:: size_t capacity
+        The new capacity of the operation. It must be less or equal to the operation's current capacity.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``capacity`` is larger than the operation's current capacity. In this case, the operation object remains valid and its capacity remains unchanged.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The capacity of a key derivation operation is the maximum number of bytes that the key derivation operation can return from this point onwards.
+
+.. function:: psa_key_derivation_input_bytes
+
+    .. summary::
+        Provide an input for key derivation or key agreement.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to use. It must have been set up with `psa_key_derivation_setup()` and must not have produced any output yet.
+    .. param:: psa_key_derivation_step_t step
+        Which step the input data is for.
+    .. param:: const uint8_t * data
+        Input data to use.
+    .. param:: size_t data_length
+        Size of the ``data`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``step`` is not compatible with the operation's algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``step`` does not allow direct inputs.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid for this input ``step``.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Which inputs are required and in what order depends on the algorithm. Refer to the documentation of each key derivation or key agreement algorithm for information.
+
+    This function passes direct inputs, which is usually correct for non-secret inputs. To pass a secret input, which is normally in a key object, call `psa_key_derivation_input_key()` instead of this function. Refer to the documentation of individual step types (``PSA_KEY_DERIVATION_INPUT_xxx`` values of type `psa_key_derivation_step_t`) for more information.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_key_derivation_abort()`.
+
+.. function:: psa_key_derivation_input_key
+
+    .. summary::
+        Provide an input for key derivation in the form of a key.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to use. It must have been set up with `psa_key_derivation_setup()` and must not have produced any output yet.
+    .. param:: psa_key_derivation_step_t step
+        Which step the input data is for.
+    .. param:: psa_key_id_t key
+        Identifier of the key. It must have an appropriate type for ``step`` and must allow the usage `PSA_KEY_USAGE_DERIVE`.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DERIVE` flag.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``step`` is not compatible with the operation's algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``step`` does not allow key inputs of the given type or does not allow key inputs at all.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid for this input ``step``.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Which inputs are required and in what order depends on the algorithm. Refer to the documentation of each key derivation or key agreement algorithm for information.
+
+    This function obtains input from a key object, which is usually correct for secret inputs or for non-secret personalization strings kept in the key store. To pass a non-secret parameter which is not in the key store, call `psa_key_derivation_input_bytes()` instead of this function. Refer to the documentation of individual step types (``PSA_KEY_DERIVATION_INPUT_xxx`` values of type `psa_key_derivation_step_t`) for more information.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_key_derivation_abort()`.
+
+.. function:: psa_key_derivation_output_bytes
+
+    .. summary::
+        Read some data from a key derivation operation.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to read from.
+    .. param:: uint8_t * output
+        Buffer where the output will be written.
+    .. param:: size_t output_length
+        Number of bytes to output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INSUFFICIENT_DATA
+        The operation's capacity was less than ``output_length`` bytes. Note that in this case, no output is written to the output buffer. The operation's capacity is set to ``0``, thus subsequent calls to this function will not succeed, even with a smaller output buffer.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active and completed all required input steps.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function calculates output bytes from a key derivation algorithm and return those bytes. If the key derivation's output is viewed as a stream of bytes, this function consumes the requested number of bytes from the stream and returns them to the caller. The operation's capacity decreases by the number of bytes read.
+
+    If this function returns an error status other than `PSA_ERROR_INSUFFICIENT_DATA`, the operation enters an error state and must be aborted by calling `psa_key_derivation_abort()`.
+
+.. function:: psa_key_derivation_output_key
+
+    .. summary::
+        Derive a key from an ongoing key derivation operation.
+
+    .. param:: const psa_key_attributes_t * attributes
+        The attributes for the new key.
+    .. param:: psa_key_derivation_operation_t * operation
+        The key derivation operation object to read from.
+    .. param:: psa_key_id_t * key
+        On success, an identifier for the newly created key. `PSA_KEY_ID_NULL` on failure.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success. If the key is persistent, the key material and the key's metadata have been saved to persistent storage.
+    .. retval:: PSA_ERROR_ALREADY_EXISTS
+        This is an attempt to create a persistent key, and there is already a persistent key with the given identifier.
+    .. retval:: PSA_ERROR_INSUFFICIENT_DATA
+        There was not enough data to create the desired key. Note that in this case, no output is written to the output buffer. The operation's capacity is set to ``0``, thus subsequent calls to this function will not succeed, even with a smaller output buffer.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        The key type or key size is not supported, either by the implementation in general or in this particular location.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        The provided key attributes are not valid for the operation.
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The `PSA_KEY_DERIVATION_INPUT_SECRET` input was not provided through a key.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active and completed all required input steps.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_INSUFFICIENT_STORAGE
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function calculates output bytes from a key derivation algorithm and uses those bytes to generate a key deterministically. The key's location, usage policy, type and size are taken from ``attributes``.
+
+    If the key derivation's output is viewed as a stream of bytes, this function consumes the required number of bytes from the stream. The operation's capacity decreases by the number of bytes used to derive the key.
+
+    If this function returns an error status other than `PSA_ERROR_INSUFFICIENT_DATA`, the operation enters an error state and must be aborted by calling `psa_key_derivation_abort()`.
+
+    How much output is produced and consumed from the operation, and how the key is derived, depends on the key type:
+
+    * For key types for which the key is an arbitrary sequence of bytes of a given size, this function is functionally equivalent to calling `psa_key_derivation_output_bytes()` and passing the resulting output to `psa_import_key()`. However, this function has a security benefit: if the implementation provides an isolation boundary then the key material is not exposed outside the isolation boundary. As a consequence, for these key types, this function always consumes exactly ``(bits/8)`` bytes from the operation. The following key types defined in this specification follow this scheme:
+
+      * `PSA_KEY_TYPE_AES`;
+      * `PSA_KEY_TYPE_ARC4`;
+      * `PSA_KEY_TYPE_CAMELLIA`;
+      * `PSA_KEY_TYPE_DERIVE`;
+      * `PSA_KEY_TYPE_HMAC`.
+
+    * For ECC keys on a Montgomery elliptic curve (:code:`PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_MONTGOMERY)`), this function always draws a byte string whose length is determined by the curve, and sets the mandatory bits accordingly. That is:
+
+      * Curve25519 (`PSA_ECC_FAMILY_MONTGOMERY`, 255 bits): draw a 32-byte string and process it as specified in :RFC:`7748#5`.
+      * Curve448 (`PSA_ECC_FAMILY_MONTGOMERY`, 448 bits): draw a 56-byte string and process it as specified in :RFC:`7748#5`.
+
+    * For key types for which the key is represented by a single sequence of ``bits`` bits with constraints as to which bit sequences are acceptable, this function draws a byte string of length ``ceiling(bits/8)`` bytes. If the resulting byte string is acceptable, it becomes the key, otherwise the drawn bytes are discarded. This process is repeated until an acceptable byte string is drawn. The byte string drawn from the operation is interpreted as specified for the output produced by `psa_export_key()`. The following key types defined in this specification follow this scheme:
+
+      * `PSA_KEY_TYPE_DES`. Force-set the parity bits, but discard forbidden weak keys. For 2-key and 3-key triple-DES, the three keys are generated successively. For example, for 3-key triple-DES, if the first 8 bytes specify a weak key and the next 8 bytes do not, discard the first 8 bytes, use the next 8 bytes as the first key, and continue reading output from the operation to derive the other two keys.
+
+      * Finite-field Diffie-Hellman keys (:code:`PSA_KEY_TYPE_DH_KEY_PAIR(dh_family)` where ``dh_family`` designates any Diffie-Hellman family) and ECC keys on a Weierstrass elliptic curve (:code:`PSA_KEY_TYPE_ECC_KEY_PAIR(ecc_family)` where ``ecc_family`` designates a Weierstrass curve family). For these key types, interpret the byte string as integer in big-endian order. Discard it if it is not in the range [0, *N* - 2] where *N* is the boundary of the private key domain: *N* is the prime *p* for Diffie-Hellman, or the order of the curve's base point for ECC. Add ``1`` to the resulting integer and use this as the private key *x*.
+
+        This method allows compliance to NIST standards, specifically the methods titled *Key-Pair Generation by Testing Candidates* in the following publications:
+
+        - |NIST SP 800-56A|_ (NIST SP 800-56A) §5.6.1.1.4 for Diffie-Hellman keys.
+        - `NIST SP 800-56A`_ §5.6.1.2.2 or |FIPS 186-4|_ (FIPS 186-4) §B.4.2 for elliptic curve keys.
+
+        .. |NIST SP 800-56A| replace:: *NIST Special Publication 800-56A: Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography*
+        .. _NIST SP 800-56A: https://doi.org/10.6028/NIST.SP.800-56Ar3
+
+        .. |FIPS 186-4| replace:: *FIPS Publication 186-4: Digital Signature Standard (DSS)*
+        .. _FIPS 186-4: https://doi.org/10.6028/NIST.FIPS.186-4
+
+    * For other key types, including `PSA_KEY_TYPE_RSA_KEY_PAIR`, the way in which the operation output is consumed is implementation-defined.
+
+    In all cases, the data that is read is discarded from the operation. The operation's capacity is decreased by the number of bytes read.
+
+    For algorithms that take an input step `PSA_KEY_DERIVATION_INPUT_SECRET`, the input to that step must be provided with `psa_key_derivation_input_key()`. Future versions of this specification might include additional restrictions on the derived key based on the attributes and strength of the secret key.
+
+.. function:: psa_key_derivation_abort
+
+    .. summary::
+        Abort a key derivation operation.
+
+    .. param:: psa_key_derivation_operation_t * operation
+        The operation to abort.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Aborting an operation frees all associated resources except for the ``operation`` object itself. Once aborted, the operation object can be reused for another operation by calling `psa_key_derivation_setup()` again.
+
+    This function can be called at any time after the operation object has been initialized as described in `psa_key_derivation_operation_t`.
+
+    In particular, it is valid to call `psa_key_derivation_abort()` twice, or to call `psa_key_derivation_abort()` on an operation that has not been set up.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_HKDF
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an HKDF algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an HKDF algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported key derivation algorithm identifier.
+
+    HKDF is a family of key derivation algorithms that are based on a hash function and the HMAC construction.
+
+.. macro:: PSA_ALG_IS_TLS12_PRF
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a TLS-1.2 PRF algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a TLS-1.2 PRF algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported key derivation algorithm identifier.
+
+.. macro:: PSA_ALG_IS_TLS12_PSK_TO_MS
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a TLS-1.2 PSK to MS algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a TLS-1.2 PSK to MS algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported key derivation algorithm identifier.
+
+.. macro:: PSA_KEY_DERIVATION_UNLIMITED_CAPACITY
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Use the maximum possible capacity for a key derivation operation.
+
+    Use this value as the capacity argument when setting up a key derivation to specify that the operation will use the maximum possible capacity. The value of the maximum possible capacity depends on the key derivation algorithm.
+
+.. macro:: PSA_TLS12_PSK_TO_MS_PSK_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns the maximum supported length of the PSK for the TLS-1.2 PSK-to-MS key derivation.
+
+    This implementation-defined value specifies the maximum length for the PSK input used with a `PSA_ALG_TLS12_PSK_TO_MS()` key agreement algorithm.
+
+    Quoting :RFC:`4279#5.3`:
+
+        TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length, and arbitrary PSKs up to 64 octets in length. Supporting longer identities and keys is RECOMMENDED.
+
+    Therefore, it is recommended that implementations define `PSA_TLS12_PSK_TO_MS_PSK_MAX_SIZE` with a value greater than or equal to ``64``.
diff --git a/docs/html/_sources/api/ops/macs.rst.txt b/docs/html/_sources/api/ops/macs.rst.txt
new file mode 100644
index 0000000..3cd1283
--- /dev/null
+++ b/docs/html/_sources/api/ops/macs.rst.txt
@@ -0,0 +1,540 @@
+.. _macs:
+
+Message authentication codes (MAC)
+==================================
+
+.. _mac-algorithms:
+
+MAC algorithms
+--------------
+
+.. macro:: PSA_ALG_HMAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build an HMAC algorithm.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true).
+
+    .. return::
+        The corresponding HMAC algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    For example, :code:`PSA_ALG_HMAC(PSA_ALG_SHA_256)` is HMAC-SHA-256.
+
+.. macro:: PSA_ALG_TRUNCATED_MAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to build a truncated MAC algorithm.
+
+    .. param:: mac_alg
+        A MAC algorithm identifier (value of type `psa_algorithm_t` such that :code:`PSA_ALG_IS_MAC(alg)` is true). This can be a truncated or untruncated MAC algorithm.
+    .. param:: mac_length
+        Desired length of the truncated MAC in bytes. This must be at most the full length of the MAC and must be at least an implementation-specified minimum. The implementation-specified minimum must not be zero.
+
+    .. return::
+        The corresponding MAC algorithm with the specified length.
+
+        Unspecified if ``alg`` is not a supported MAC algorithm or if ``mac_length`` is too small or too large for the specified MAC algorithm.
+
+    A truncated MAC algorithm is identical to the corresponding MAC algorithm except that the MAC value for the truncated algorithm consists of only the first ``mac_length`` bytes of the MAC value for the untruncated algorithm.
+
+    .. note::
+        This macro might allow constructing algorithm identifiers that are not valid, either because the specified length is larger than the untruncated MAC or because the specified length is smaller than permitted by the implementation.
+
+    .. note::
+        It is implementation-defined whether a truncated MAC that is truncated to the same length as the MAC of the untruncated algorithm is considered identical to the untruncated algorithm for policy comparison purposes.
+
+    The full-length MAC algorithm can be recovered using `PSA_ALG_FULL_LENGTH_MAC()`.
+
+.. macro:: PSA_ALG_CBC_MAC
+    :definition: ((psa_algorithm_t)0x03c00100)
+
+    .. summary::
+        The CBC-MAC construction over a block cipher.
+
+    .. warning::
+        CBC-MAC is insecure in many cases. A more secure mode, such as `PSA_ALG_CMAC`, is recommended.
+
+.. macro:: PSA_ALG_CMAC
+    :definition: ((psa_algorithm_t)0x03c00200)
+
+    .. summary::
+        The CMAC construction over a block cipher.
+
+Single-part MAC functions
+-------------------------
+
+.. function:: psa_mac_compute
+
+    .. summary::
+        Calculate the message authentication code (MAC) of a message.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation.
+        It must allow the usage `PSA_KEY_USAGE_SIGN_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        The MAC algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_MAC(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the input message.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * mac
+        Buffer where the MAC value is to be written.
+    .. param:: size_t mac_size
+        Size of the ``mac`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The exact MAC size is :code:`PSA_MAC_LENGTH(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are attributes of the key used to compute the MAC.
+        * `PSA_MAC_MAX_SIZE` evaluates to the maximum MAC size of any supported MAC algorithm.
+
+    .. param:: size_t * mac_length
+        On success, the number of bytes that make up the MAC value.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_SIGN_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a MAC algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``mac`` buffer is too small.
+        `PSA_MAC_LENGTH()` or `PSA_MAC_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_INVALID
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    .. note::
+        To verify the MAC of a message against an expected value, use `psa_mac_verify()` instead. Beware that comparing integrity or authenticity data such as MAC values with a function such as ``memcmp()`` is risky because the time taken by the comparison might leak information about the MAC value which could allow an attacker to guess a valid MAC and thereby bypass security controls.
+
+.. function:: psa_mac_verify
+
+    .. summary::
+        Calculate the MAC of a message and compare it with a reference value.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation.
+        It must allow the usage `PSA_KEY_USAGE_VERIFY_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        The MAC algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_MAC(alg)` is true).
+    .. param:: const uint8_t * input
+        Buffer containing the input message.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: const uint8_t * mac
+        Buffer containing the expected MAC value.
+    .. param:: size_t mac_length
+        Size of the ``mac`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The expected MAC is identical to the actual MAC of the input.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The MAC of the message was calculated successfully, but it differs from the expected value.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_VERIFY_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a MAC algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_INVALID
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+Multi-part MAC operations
+-------------------------
+
+.. typedef:: /* implementation-defined type */ psa_mac_operation_t
+
+    .. summary::
+        The type of the state object for multi-part MAC operations.
+
+    Before calling any function on a MAC operation object, the application must initialize it by any of the following means:
+
+    * Set the object to all-bits-zero, for example:
+
+      .. autocode::
+          psa_mac_operation_t operation;
+          memset(&operation, 0, sizeof(operation));
+
+    * Initialize the object to logical zero values by declaring the object as static or global without an explicit initializer, for example:
+
+      .. autocode::
+          static psa_mac_operation_t operation;
+
+    * Initialize the object to the initializer `PSA_MAC_OPERATION_INIT`, for example:
+
+      .. autocode::
+          psa_mac_operation_t operation = PSA_MAC_OPERATION_INIT;
+
+    * Assign the result of the function `psa_mac_operation_init()` to the object, for example:
+
+      .. autocode::
+          psa_mac_operation_t operation;
+          operation = psa_mac_operation_init();
+
+    This is an implementation-defined type. Applications that make assumptions about the content of this object will result in in implementation-specific behavior, and are non-portable.
+
+.. macro:: PSA_MAC_OPERATION_INIT
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        This macro returns a suitable initializer for a MAC operation object of type `psa_mac_operation_t`.
+
+.. function:: psa_mac_operation_init
+
+    .. summary::
+        Return an initial value for a MAC operation object.
+
+    .. return:: psa_mac_operation_t
+
+.. function:: psa_mac_sign_setup
+
+    .. summary::
+        Set up a multi-part MAC calculation operation.
+
+    .. param:: psa_mac_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_mac_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_SIGN_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        The MAC algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_MAC(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_SIGN_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a MAC algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_INVALID
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function sets up the calculation of the message authentication code (MAC) of a byte string. To verify the MAC of a message against an expected value, use `psa_mac_verify_setup()` instead.
+
+    The sequence of operations to calculate a MAC is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_mac_operation_t`, e.g. `PSA_MAC_OPERATION_INIT`.
+    #. Call `psa_mac_sign_setup()` to specify the algorithm and key.
+    #. Call `psa_mac_update()` zero, one or more times, passing a fragment of the message each time. The MAC that is calculated is the MAC of the concatenation of these messages in order.
+    #. At the end of the message, call `psa_mac_sign_finish()` to finish calculating the MAC value and retrieve it.
+
+    If an error occurs at any step after a call to `psa_mac_sign_setup()`, the operation will need to be reset by a call to `psa_mac_abort()`. The application can call `psa_mac_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_mac_sign_setup()`, the application must eventually terminate the operation through one of the following methods:
+
+    * A successful call to `psa_mac_sign_finish()`.
+    * A call to `psa_mac_abort()`.
+
+.. function:: psa_mac_verify_setup
+
+    .. summary::
+        Set up a multi-part MAC verification operation.
+
+    .. param:: psa_mac_operation_t * operation
+        The operation object to set up. It must have been initialized as per the documentation for `psa_mac_operation_t` and not yet in use.
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must remain valid until the operation terminates.
+        It must allow the usage `PSA_KEY_USAGE_VERIFY_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        The MAC algorithm to compute (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_MAC(alg)` is true).
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_VERIFY_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+        ``key`` is not compatible with ``alg``.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+        ``alg`` is not supported or is not a MAC algorithm.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+        The key could not be retrieved from storage
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_DATA_INVALID
+        The key could not be retrieved from storage.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be inactive.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    This function sets up the verification of the message authentication code (MAC) of a byte string against an expected value.
+
+    The sequence of operations to verify a MAC is as follows:
+
+    #. Allocate an operation object which will be passed to all the functions listed here.
+    #. Initialize the operation object with one of the methods described in the documentation for `psa_mac_operation_t`, e.g. `PSA_MAC_OPERATION_INIT`.
+    #. Call `psa_mac_verify_setup()` to specify the algorithm and key.
+    #. Call `psa_mac_update()` zero, one or more times, passing a fragment of the message each time. The MAC that is calculated is the MAC of the concatenation of these messages in order.
+    #. At the end of the message, call `psa_mac_verify_finish()` to finish calculating the actual MAC of the message and verify it against the expected value.
+
+    If an error occurs at any step after a call to `psa_mac_verify_setup()`, the operation will need to be reset by a call to `psa_mac_abort()`. The application can call `psa_mac_abort()` at any time after the operation has been initialized.
+
+    After a successful call to `psa_mac_verify_setup()`, the application must eventually terminate the operation through one of the following methods:
+
+    * A successful call to `psa_mac_verify_finish()`.
+    * A call to `psa_mac_abort()`.
+
+.. function:: psa_mac_update
+
+    .. summary::
+        Add a message fragment to a multi-part MAC operation.
+
+    .. param:: psa_mac_operation_t * operation
+        Active MAC operation.
+    .. param:: const uint8_t * input
+        Buffer containing the message fragment to add to the MAC calculation.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be active.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_mac_sign_setup()` or `psa_mac_verify_setup()` before calling this function.
+
+    If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_mac_abort()`.
+
+.. function:: psa_mac_sign_finish
+
+    .. summary::
+        Finish the calculation of the MAC of a message.
+
+    .. param:: psa_mac_operation_t * operation
+        Active MAC operation.
+    .. param:: uint8_t * mac
+        Buffer where the MAC value is to be written.
+    .. param:: size_t mac_size
+        Size of the ``mac`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The exact MAC size is :code:`PSA_MAC_LENGTH(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are attributes of the key, and ``alg`` is the algorithm used to compute the MAC.
+        * `PSA_MAC_MAX_SIZE` evaluates to the maximum MAC size of any supported MAC algorithm.
+
+    .. param:: size_t * mac_length
+        On success, the number of bytes that make up the MAC value. This is always :code:`PSA_MAC_FINAL_SIZE(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size respectively of the key and ``alg`` is the MAC algorithm that is calculated.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        Success.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be an active mac sign operation.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``mac`` buffer is too small.
+        `PSA_MAC_LENGTH()` or `PSA_MAC_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_mac_sign_setup()` before calling this function. This function calculates the MAC of the message formed by concatenating the inputs passed to preceding calls to `psa_mac_update()`.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_mac_abort()`.
+
+    .. warning::
+        It is not recommended to use this function when a specific value is expected for the MAC. Call `psa_mac_verify_finish()` instead with the expected MAC value.
+
+        Comparing integrity or authenticity data such as MAC values with a function such as ``memcmp()`` is risky because the time taken by the comparison might leak information about the hashed data which could allow an attacker to guess a valid MAC and thereby bypass security controls.
+
+.. function:: psa_mac_verify_finish
+
+    .. summary::
+        Finish the calculation of the MAC of a message and compare it with an expected value.
+
+    .. param:: psa_mac_operation_t * operation
+        Active MAC operation.
+    .. param:: const uint8_t * mac
+        Buffer containing the expected MAC value.
+    .. param:: size_t mac_length
+        Size of the ``mac`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The expected MAC is identical to the actual MAC of the message.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The MAC of the message was calculated successfully, but it differs from the expected MAC.
+    .. retval:: PSA_ERROR_BAD_STATE
+        The operation state is not valid: it must be an active mac verify operation.
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    The application must call `psa_mac_verify_setup()` before calling this function. This function calculates the MAC of the message formed by concatenating the inputs passed to preceding calls to `psa_mac_update()`. It then compares the calculated MAC with the expected MAC passed as a parameter to this function.
+
+    When this function returns successfully, the operation becomes inactive. If this function returns an error status, the operation enters an error state and must be aborted by calling `psa_mac_abort()`.
+
+    .. note::
+        Implementations must make the best effort to ensure that the comparison between the actual MAC and the expected MAC is performed in constant time.
+
+.. function:: psa_mac_abort
+
+    .. summary::
+        Abort a MAC operation.
+
+    .. param:: psa_mac_operation_t * operation
+        Initialized MAC operation.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    Aborting an operation frees all associated resources except for the ``operation`` object itself. Once aborted, the operation object can be reused for another operation by calling `psa_mac_sign_setup()` or `psa_mac_verify_setup()` again.
+
+    This function can be called any time after the operation object has been initialized by one of the methods described in `psa_mac_operation_t`.
+
+    In particular, calling `psa_mac_abort()` after the operation has been terminated by a call to `psa_mac_abort()`, `psa_mac_sign_finish()` or `psa_mac_verify_finish()` is safe and has no effect.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_HMAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an HMAC algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an HMAC algorithm, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    HMAC is a family of MAC algorithms that are based on a hash function.
+
+.. macro:: PSA_ALG_IS_BLOCK_CIPHER_MAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a MAC algorithm based on a block cipher.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a MAC algorithm based on a block cipher, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_FULL_LENGTH_MAC
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Macro to construct the MAC algorithm with a full length MAC, from a truncated MAC algorithm.
+
+    .. param:: mac_alg
+        A MAC algorithm identifier (value of type `psa_algorithm_t` such that :code:`PSA_ALG_IS_MAC(alg)` is true). This can be a truncated or untruncated MAC algorithm.
+
+    .. return::
+        The corresponding MAC algorithm with a full length MAC.
+
+        Unspecified if ``alg`` is not a supported MAC algorithm.
+
+.. macro:: PSA_MAC_LENGTH
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        The size of the output of `psa_mac_compute()` and `psa_mac_sign_finish()`, in bytes.
+
+    .. param:: key_type
+        The type of the MAC key.
+    .. param:: key_bits
+        The size of the MAC key in bits.
+    .. param:: alg
+        A MAC algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_MAC(alg)` is true).
+
+    .. return::
+        The MAC length for the specified algorithm with the specified key parameters.
+
+        ``0`` if the MAC algorithm is not recognized.
+
+        Either ``0`` or the correct length for a MAC algorithm that the implementation recognizes, but does not support.
+
+        Unspecified if the key parameters are not consistent with the algorithm.
+
+    This is also the MAC length that `psa_mac_verify()` and `psa_mac_verify_finish()` expects.
+
+    See also `PSA_MAC_MAX_SIZE`.
+
+.. macro:: PSA_MAC_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Maximum size of a MAC.
+
+    This macro must expand to a compile-time constant integer.
+    It is recommended that this value is the maximum size of a MAC supported by the implementation, in bytes. The value must not be smaller than this maximum.
+
+    See also `PSA_MAC_LENGTH()`.
diff --git a/docs/html/_sources/api/ops/pke.rst.txt b/docs/html/_sources/api/ops/pke.rst.txt
new file mode 100644
index 0000000..9ffde10
--- /dev/null
+++ b/docs/html/_sources/api/ops/pke.rst.txt
@@ -0,0 +1,220 @@
+.. _pke:
+
+Asymmetric encryption
+=====================
+
+.. _asymmetric-encryption-algorithms:
+
+Asymmetric encryption algorithms
+--------------------------------
+
+.. macro:: PSA_ALG_RSA_PKCS1V15_CRYPT
+    :definition: ((psa_algorithm_t)0x07000200)
+
+    .. summary::
+        RSA PKCS#1 v1.5 encryption.
+
+.. macro:: PSA_ALG_RSA_OAEP
+    :definition: /* specification-defined value */
+
+    .. summary::
+        RSA OAEP encryption.
+
+    .. param:: hash_alg
+        The hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true) to use for MGF1.
+
+    .. return::
+        The corresponding RSA OAEP signature algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This is the encryption scheme defined by :RFC:`8017` (PKCS#1: RSA Cryptography Specifications) under the name RSAES-OAEP, with the message generation function MGF1.
+
+Asymmetric encryption functions
+-------------------------------
+
+.. function:: psa_asymmetric_encrypt
+
+    .. summary::
+        Encrypt a short message with a public key.
+
+    .. param:: psa_key_id_t key
+        Identifer of the key to use for the operation. It must be a public key or an asymmetric key pair.
+        It must allow the usage `PSA_KEY_USAGE_ENCRYPT`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric encryption algorithm that is compatible with the type of ``key``.
+    .. param:: const uint8_t * input
+        The message to encrypt.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: const uint8_t * salt
+        A salt or label, if supported by the encryption algorithm. If the algorithm does not support a salt, pass ``NULL``. If the algorithm supports an optional salt, pass ``NULL`` to indicate that there is no salt.
+    .. param:: size_t salt_length
+        Size of the ``salt`` buffer in bytes. If ``salt`` is ``NULL``, pass ``0``.
+    .. param:: uint8_t * output
+        Buffer where the encrypted message is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The required output size is :code:`PSA_ASYMMETRIC_ENCRYPT_OUTPUT_SIZE(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size respectively of ``key``.
+        * `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported asymmetric encryption.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_ENCRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small.
+        `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_SIZE()` or `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    * For `PSA_ALG_RSA_PKCS1V15_CRYPT`, no salt is supported.
+
+.. function:: psa_asymmetric_decrypt
+
+    .. summary::
+        Decrypt a short message with a private key.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must be an asymmetric key pair.
+        It must allow the usage `PSA_KEY_USAGE_DECRYPT`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric encryption algorithm that is compatible with the type of ``key``.
+    .. param:: const uint8_t * input
+        The message to decrypt.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: const uint8_t * salt
+        A salt or label, if supported by the encryption algorithm. If the algorithm does not support a salt, pass ``NULL``. If the algorithm supports an optional salt, pass ``NULL`` to indicate that there is no salt.
+    .. param:: size_t salt_length
+        Size of the ``salt`` buffer in bytes. If ``salt`` is ``NULL``, pass ``0``.
+    .. param:: uint8_t * output
+        Buffer where the decrypted message is to be written.
+    .. param:: size_t output_size
+        Size of the ``output`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The required output size is :code:`PSA_ASYMMETRIC_DECRYPT_OUTPUT_SIZE(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size respectively of ``key``.
+        * `PSA_ASYMMETRIC_DECRYPT_OUTPUT_MAX_SIZE` evaluates to the maximum output size of any supported asymmetric decryption.
+
+    .. param:: size_t * output_length
+        On success, the number of bytes that make up the returned output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_DECRYPT` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``output`` buffer is too small.
+        `PSA_ASYMMETRIC_DECRYPT_OUTPUT_SIZE()` or `PSA_ASYMMETRIC_DECRYPT_OUTPUT_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_INVALID_PADDING
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    * For `PSA_ALG_RSA_PKCS1V15_CRYPT`, no salt is supported.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_RSA_OAEP
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an RSA OAEP encryption algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an RSA OAEP algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ASYMMETRIC_ENCRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient output buffer size for `psa_asymmetric_encrypt()`.
+
+    .. param:: key_type
+        An asymmetric key type, either a key pair or a public key.
+    .. param:: key_bits
+        The size of the key in bits.
+    .. param:: alg
+        The signature algorithm.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_asymmetric_encrypt()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+    This macro returns a sufficient buffer size for a ciphertext produced using a key of the specified type and size, with the specified algorithm. Note that the actual size of the ciphertext might be smaller, depending on the algorithm.
+
+    .. warning::
+        This function might evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    See also `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_ASYMMETRIC_ENCRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_asymmetric_encrypt()`, for any supported asymmetric encryption.
+
+    See also `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_SIZE()`.
+
+.. macro:: PSA_ASYMMETRIC_DECRYPT_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient output buffer size for `psa_asymmetric_decrypt()`.
+
+    .. param:: key_type
+        An asymmetric key type, either a key pair or a public key.
+    .. param:: key_bits
+        The size of the key in bits.
+    .. param:: alg
+        The signature algorithm.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_asymmetric_decrypt()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+    This macro returns a sufficient buffer size for a ciphertext produced using a key of the specified type and size, with the specified algorithm. Note that the actual size of the ciphertext might be smaller, depending on the algorithm.
+
+    .. warning::
+        This function might evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    See also `PSA_ASYMMETRIC_DECRYPT_OUTPUT_MAX_SIZE`.
+
+.. macro:: PSA_ASYMMETRIC_DECRYPT_OUTPUT_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        A sufficient output buffer size for `psa_asymmetric_decrypt()`, for any supported asymmetric decryption.
+
+    See also `PSA_ASYMMETRIC_DECRYPT_OUTPUT_SIZE()`.
diff --git a/docs/html/_sources/api/ops/rng.rst.txt b/docs/html/_sources/api/ops/rng.rst.txt
new file mode 100644
index 0000000..f670bd9
--- /dev/null
+++ b/docs/html/_sources/api/ops/rng.rst.txt
@@ -0,0 +1,34 @@
+Other cryptographic services
+============================
+
+.. _rng:
+
+Random number generation
+------------------------
+
+.. function:: psa_generate_random
+
+    .. summary::
+        Generate random bytes.
+
+    .. param:: uint8_t * output
+        Output buffer for the generated data.
+    .. param:: size_t output_size
+        Number of bytes to generate and output.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    .. warning::
+        This function **can** fail! Callers MUST check the return status and MUST NOT use the content of the output buffer if the return status is not `PSA_SUCCESS`.
+
+    .. note::
+        To generate a key, use `psa_generate_key()` instead.
diff --git a/docs/html/_sources/api/ops/sign.rst.txt b/docs/html/_sources/api/ops/sign.rst.txt
new file mode 100644
index 0000000..a0025b5
--- /dev/null
+++ b/docs/html/_sources/api/ops/sign.rst.txt
@@ -0,0 +1,474 @@
+.. _sign:
+
+Asymmetric signature
+====================
+
+.. _sign-algorithms:
+
+Asymmetric signature algorithms
+-------------------------------
+
+.. macro:: PSA_ALG_RSA_PKCS1V15_SIGN
+    :definition: /* specification-defined value */
+
+    .. summary::
+        RSA PKCS#1 v1.5 signature with hashing.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true). This includes `PSA_ALG_ANY_HASH` when specifying the algorithm in a usage policy.
+
+    .. return::
+        The corresponding RSA PKCS#1 v1.5 signature algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This is the signature scheme defined by :RFC:`8017` (PKCS#1: RSA Cryptography Specifications) under the name RSASSA-PKCS1-v1_5.
+
+.. macro:: PSA_ALG_RSA_PKCS1V15_SIGN_RAW
+    :definition: ((psa_algorithm_t) 0x06000200))
+
+    .. summary::
+        Raw PKCS#1 v1.5 signature.
+
+    The input to this algorithm is the DigestInfo structure used by :RFC:`8017#9.2` (PKCS#1: RSA Cryptography Specifications), in steps 3–6.
+
+.. macro:: PSA_ALG_RSA_PSS
+    :definition: /* specification-defined value */
+
+    .. summary::
+        RSA PSS signature with hashing.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true). This includes `PSA_ALG_ANY_HASH` when specifying the algorithm in a usage policy.
+
+    .. return::
+        The corresponding RSA PSS signature algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This is the signature scheme defined by :RFC:`8017` (PKCS#1: RSA Cryptography Specifications) under the name RSASSA-PSS, with the message generation function MGF1, and with a salt length equal to the length of the hash. The specified hash algorithm is used to hash the input message, to create the salted hash, and for the mask generation.
+
+.. macro:: PSA_ALG_ECDSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        ECDSA signature with hashing.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true). This includes `PSA_ALG_ANY_HASH` when specifying the algorithm in a usage policy.
+
+    .. return::
+        The corresponding ECDSA signature algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This is the *Elliptic Curve Digital Signature Algorithm (ECDSA)* defined by ANSI X9.62-2005, with a random per-message secret number (*k*).
+
+    The representation of the signature as a byte string consists of the concatenation of the signature values *r* and *s*. Each of *r* and *s* is encoded as an *N*-octet string, where *N* is the length of the base point of the curve in octets. Each value is represented in big-endian order, with the most significant octet first.
+
+.. macro:: PSA_ALG_ECDSA_ANY
+    :definition: ((psa_algorithm_t) 0x06000600))
+
+    .. summary::
+        ECDSA signature without hashing.
+
+    This is the same signature scheme as `PSA_ALG_ECDSA()`, but without specifying a hash algorithm. This algorithm is only recommended to sign or verify a sequence of bytes that are an already-calculated hash. Note that the input is padded with zeros on the left or truncated on the left as required to fit the curve size.
+
+.. macro:: PSA_ALG_DETERMINISTIC_ECDSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Deterministic ECDSA signature with hashing.
+
+    .. param:: hash_alg
+        A hash algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_HASH(hash_alg)` is true). This includes `PSA_ALG_ANY_HASH` when specifying the algorithm in a usage policy.
+
+    .. return::
+        The corresponding deterministic ECDSA signature algorithm.
+
+        Unspecified if ``hash_alg`` is not a supported hash algorithm.
+
+    This is the deterministic ECDSA signature scheme defined by :RFC:`6979`.
+
+    The representation of a signature is the same as with `PSA_ALG_ECDSA()`.
+
+    Note that when this algorithm is used for verification, signatures made with randomized ECDSA (:code:`PSA_ALG_ECDSA(hash_alg)`) with the same private key are accepted. In other words, :code:`PSA_ALG_DETERMINISTIC_ECDSA(hash_alg)` differs from :code:`PSA_ALG_ECDSA(hash_alg)` only for signature, not for verification.
+
+Asymmetric signature functions
+------------------------------
+
+.. function:: psa_sign_message
+
+    .. summary::
+        Sign a message with a private key. For hash-and-sign algorithms, this includes the hashing step.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must be an asymmetric key pair. The key must allow the usage `PSA_KEY_USAGE_SIGN_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric signature algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_SIGN_MESSAGE(alg)` is true), that is compatible with the type of ``key``.
+    .. param:: const uint8_t * input
+        The input message to sign.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: uint8_t * signature
+        Buffer where the signature is to be written.
+    .. param:: size_t signature_size
+        Size of the ``signature`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The required signature size is :code:`PSA_SIGN_OUTPUT_SIZE(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size respectively of ``key``.
+        * `PSA_SIGNATURE_MAX_SIZE` evaluates to the maximum signature size of any supported signature algorithm.
+
+    .. param:: size_t * signature_length
+        On success, the number of bytes that make up the returned signature value.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_SIGN_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``signature`` buffer is too small.
+        `PSA_SIGN_OUTPUT_SIZE()` or `PSA_SIGNATURE_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    ..  note::
+        To perform a multi-part hash-and-sign signature algorithm, first use a :ref:`multi-part hash operation <hash-mp>` and then pass the resulting hash to `psa_sign_hash()`. :code:`PSA_ALG_GET_HASH(alg)` can be used to determine the hash algorithm to use.
+
+.. function:: psa_verify_message
+
+    .. summary::
+        Verify the signature of a message with a public key, using a hash-and-sign verification algorithm.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must be a public key or an asymmetric key pair. The key must allow the usage `PSA_KEY_USAGE_VERIFY_MESSAGE`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric signature algorithm (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_SIGN_MESSAGE(alg)` is true), that is compatible with the type of ``key``.
+    .. param:: const uint8_t * input
+        The message whose signature is to be verified.
+    .. param:: size_t input_length
+        Size of the ``input`` buffer in bytes.
+    .. param:: const uint8_t * signature
+        Buffer containing the signature to verify.
+    .. param:: size_t signature_length
+        Size of the ``signature`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The signature is valid.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_VERIFY_MESSAGE` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The calculation was performed successfully, but the passed signature is not a valid signature.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    ..  note::
+        To perform a multi-part hash-and-sign signature verification algorithm, first use a :ref:`multi-part hash operation <hash-mp>` to hash the message and then pass the resulting hash to `psa_verify_hash()`. :code:`PSA_ALG_GET_HASH(alg)` can be used to determine the hash algorithm to use.
+
+.. function:: psa_sign_hash
+
+    .. summary::
+        Sign an already-calculated hash with a private key.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must be an asymmetric key pair. The key must allow the usage `PSA_KEY_USAGE_SIGN_HASH`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric signature algorithm that separates the hash and sign operations (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_SIGN_HASH(alg)` is true), that is compatible with the type of ``key``.
+    .. param:: const uint8_t * hash
+        The input to sign. This is usually the hash of a message. See the detailed description of this function and the description of individual signature algorithms for a detailed description of acceptable inputs.
+    .. param:: size_t hash_length
+        Size of the ``hash`` buffer in bytes.
+    .. param:: uint8_t * signature
+        Buffer where the signature is to be written.
+    .. param:: size_t signature_size
+        Size of the ``signature`` buffer in bytes.
+        This must be appropriate for the selected algorithm and key:
+
+        * The required signature size is :code:`PSA_SIGN_OUTPUT_SIZE(key_type, key_bits, alg)` where ``key_type`` and ``key_bits`` are the type and bit-size respectively of ``key``.
+        * `PSA_SIGNATURE_MAX_SIZE` evaluates to the maximum signature size of any supported signature algorithm.
+
+    .. param:: size_t * signature_length
+        On success, the number of bytes that make up the returned signature value.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_SIGN_HASH` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_BUFFER_TOO_SMALL
+        The size of the ``signature`` buffer is too small.
+        `PSA_SIGN_OUTPUT_SIZE()` or `PSA_SIGNATURE_MAX_SIZE` can be used to determine the required buffer size.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_INSUFFICIENT_ENTROPY
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    With most signature mechanisms that follow the hash-and-sign paradigm, the hash input to this function is the hash of the message to sign. The hash algorithm is encoded in the signature algorithm.
+
+    Some hash-and-sign mechanisms apply a padding or encoding to the hash. In such cases, the encoded hash must be passed to this function. The current version of this specification defines one such signature algorithm: `PSA_ALG_RSA_PKCS1V15_SIGN_RAW`.
+
+    .. note::
+        To perform a hash-and-sign algorithm, the hash must be calculated before passing it to this function. This can be done by calling `psa_hash_compute()` or with a multi-part hash operation. Alternatively, to hash and sign a message in a single call, use `psa_sign_message()`.
+
+.. function:: psa_verify_hash
+
+    .. summary::
+        Verify the signature of a hash or short message using a public key.
+
+    .. param:: psa_key_id_t key
+        Identifier of the key to use for the operation. It must be a public key or an asymmetric key pair. The key must allow the usage `PSA_KEY_USAGE_VERIFY_HASH`.
+    .. param:: psa_algorithm_t alg
+        An asymmetric signature algorithm that separates the hash and sign operations (``PSA_ALG_XXX`` value such that :code:`PSA_ALG_IS_SIGN_HASH(alg)` is true), that is compatible with the type of ``key``.
+    .. param:: const uint8_t * hash
+        The input whose signature is to be verified. This is usually the hash of a message. See the detailed description of this function and the description of individual signature algorithms for a detailed description of acceptable inputs.
+    .. param:: size_t hash_length
+        Size of the ``hash`` buffer in bytes.
+    .. param:: const uint8_t * signature
+        Buffer containing the signature to verify.
+    .. param:: size_t signature_length
+        Size of the ``signature`` buffer in bytes.
+
+    .. return:: psa_status_t
+    .. retval:: PSA_SUCCESS
+        The signature is valid.
+    .. retval:: PSA_ERROR_INVALID_HANDLE
+    .. retval:: PSA_ERROR_NOT_PERMITTED
+        The key does not have the `PSA_KEY_USAGE_VERIFY_HASH` flag, or it does not permit the requested algorithm.
+    .. retval:: PSA_ERROR_INVALID_SIGNATURE
+        The calculation was performed successfully, but the passed signature is not a valid signature.
+    .. retval:: PSA_ERROR_NOT_SUPPORTED
+    .. retval:: PSA_ERROR_INVALID_ARGUMENT
+    .. retval:: PSA_ERROR_INSUFFICIENT_MEMORY
+    .. retval:: PSA_ERROR_COMMUNICATION_FAILURE
+    .. retval:: PSA_ERROR_HARDWARE_FAILURE
+    .. retval:: PSA_ERROR_CORRUPTION_DETECTED
+    .. retval:: PSA_ERROR_STORAGE_FAILURE
+    .. retval:: PSA_ERROR_DATA_CORRUPT
+    .. retval:: PSA_ERROR_DATA_INVALID
+    .. retval:: PSA_ERROR_BAD_STATE
+        The library has not been previously initialized by `psa_crypto_init()`. It is implementation-dependent whether a failure to initialize results in this error code.
+
+    With most signature mechanisms that follow the hash-and-sign paradigm, the hash input to this function is the hash of the message to sign. The hash algorithm is encoded in the signature algorithm.
+
+    Some hash-and-sign mechanisms apply a padding or encoding to the hash. In such cases, the encoded hash must be passed to this function. The current version of this specification defines one such signature algorithm: `PSA_ALG_RSA_PKCS1V15_SIGN_RAW`.
+
+    .. note::
+        To perform a hash-and-sign verification algorithm, the hash must be calculated before passing it to this function. This can be done by calling `psa_hash_compute()` or with a multi-part hash operation. Alternatively, to hash and verify a message signature in a single call, use `psa_verify_message()`.
+
+Support macros
+--------------
+
+.. macro:: PSA_ALG_IS_SIGN_MESSAGE
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a signature algorithm that can be used with `psa_sign_message()` and `psa_verify_message()`.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a signature algorithm that can be used to sign a message. ``0`` if ``alg`` is a signature algorithm that can only be used to sign an already-calculated hash. ``0`` if ``alg`` is not a signature algorithm. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_IS_SIGN_HASH
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a signature algorithm that can be used with `psa_sign_hash()` and `psa_verify_hash()`.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a signature algorithm that can be used to sign a hash. ``0`` if ``alg`` is a signature algorithm that can only be used to sign a message. ``0`` if ``alg`` is not a signature algorithm. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_IS_RSA_PKCS1V15_SIGN
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an RSA PKCS#1 v1.5 signature algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an RSA PKCS#1 v1.5 signature algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_IS_RSA_PSS
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is an RSA PSS signature algorithm.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an RSA PSS signature algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_IS_ECDSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is ECDSA.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is an ECDSA algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+.. macro:: PSA_ALG_IS_DETERMINISTIC_ECDSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is deterministic ECDSA.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a deterministic ECDSA algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See also `PSA_ALG_IS_ECDSA()` and `PSA_ALG_IS_RANDOMIZED_ECDSA()`.
+
+.. macro:: PSA_ALG_IS_RANDOMIZED_ECDSA
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is randomized ECDSA.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a randomized ECDSA algorithm, ``0`` otherwise.
+
+        This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    See also `PSA_ALG_IS_ECDSA()` and `PSA_ALG_IS_DETERMINISTIC_ECDSA()`.
+
+.. macro:: PSA_ALG_IS_HASH_AND_SIGN
+    :definition: /* specification-defined value */
+
+    .. summary::
+        Whether the specified algorithm is a hash-and-sign algorithm that signs exactly the hash value.
+
+    .. param:: alg
+        An algorithm identifier (value of type `psa_algorithm_t`).
+
+    .. return::
+        ``1`` if ``alg`` is a hash-and-sign algorithm that signs exactly the hash value, ``0`` otherwise. This macro can return either ``0`` or ``1`` if ``alg`` is not a supported algorithm identifier.
+
+    This macro identifies algorithms that can be used with `psa_sign_hash()` that use the exact message hash value as an input the signature operation. This excludes hash-and-sign algorithms that require a encoded or modified hash for the signature step in the algorithm, such as `PSA_ALG_RSA_PKCS1V15_SIGN_RAW`.
+
+.. macro:: PSA_ALG_ANY_HASH
+    :definition: ((psa_algorithm_t)0x020000ff)
+
+    .. summary::
+        In a hash-and-sign algorithm policy, allow any hash algorithm.
+
+    This value can be used to form the algorithm usage field of a policy for a signature algorithm that is parametrized by a hash. A key with this policy can then be used to perform operations using the same signature algorithm parametrized with any supported hash.
+    A signature algorithm policy created using this macro is a wildcard policy, and `PSA_ALG_IS_WILDCARD()` will return true.
+
+    This value must not be used to build other algorithms that are parametrized over a hash. For any valid use of this macro to build an algorithm ``alg``, :code:`PSA_ALG_IS_HASH_AND_SIGN(alg)` is true.
+
+    This value must not be used to build an algorithm specification to perform an operation. It is only valid to build policies.
+
+    .. rubric:: Usage
+
+    For example, suppose that ``PSA_xxx_SIGNATURE`` is one of the following macros:
+
+    * `PSA_ALG_RSA_PKCS1V15_SIGN`
+    * `PSA_ALG_RSA_PSS`
+    * `PSA_ALG_ECDSA`
+    * `PSA_ALG_DETERMINISTIC_ECDSA`
+
+    The following sequence of operations shows how `PSA_ALG_ANY_HASH` can be used in a key policy:
+
+    * Set the key usage field using `PSA_ALG_ANY_HASH`, for example:
+
+      .. autocode::
+          psa_set_key_usage_flags(&attributes, PSA_KEY_USAGE_SIGN_MESSAGE); // or VERIFY_MESSAGE
+          psa_set_key_algorithm(&attributes, PSA_xxx_SIGNATURE(PSA_ALG_ANY_HASH));
+
+    * Import or generate key material.
+    * Call `psa_sign_message()` or `psa_verify_message()`, passing an algorithm built from ``PSA_xxx_SIGNATURE`` and a specific hash. Each call to sign or verify a message can use a different hash algorithm.
+
+      .. autocode::
+          psa_sign_message(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA_256), ...);
+          psa_sign_message(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA_512), ...);
+          psa_sign_message(key, PSA_xxx_SIGNATURE(PSA_ALG_SHA3_256), ...);
+
+
+.. macro:: PSA_SIGN_OUTPUT_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Sufficient signature buffer size for `psa_sign_message()` and `psa_sign_hash()`.
+
+    .. param:: key_type
+        An asymmetric key type. This can be a key pair type or a public key type.
+    .. param:: key_bits
+        The size of the key in bits.
+    .. param:: alg
+        The signature algorithm.
+
+    .. return::
+        If the parameters are valid and supported, return a buffer size in bytes that guarantees that `psa_sign_message()` and `psa_sign_hash()` will not fail with `PSA_ERROR_BUFFER_TOO_SMALL`. If the parameters are a valid combination that is not supported by the implementation, this macro must return either a sensible size or ``0``. If the parameters are not valid, the return value is unspecified.
+
+    This macro returns a sufficient buffer size for a signature using a key of the specified type and size, with the specified algorithm. Note that the actual size of the signature might be smaller, as some algorithms produce a variable-size signature.
+
+    .. warning::
+        This function might evaluate its arguments multiple times or zero times. Providing arguments that have side effects will result in implementation-specific behavior, and is non-portable.
+
+    See also `PSA_SIGNATURE_MAX_SIZE`.
+
+.. macro:: PSA_SIGNATURE_MAX_SIZE
+    :definition: /* implementation-defined value */
+
+    .. summary::
+        Maximum size of an asymmetric signature.
+
+    This macro must expand to a compile-time constant integer.
+    It is recommended that this value is the maximum size of an asymmetric signature supported by the implementation, in bytes. The value must not be smaller than this maximum.
+
+    See also `PSA_SIGN_OUTPUT_SIZE()`.
diff --git a/docs/html/_sources/appendix/example_header.rst.txt b/docs/html/_sources/appendix/example_header.rst.txt
new file mode 100644
index 0000000..32ce590
--- /dev/null
+++ b/docs/html/_sources/appendix/example_header.rst.txt
@@ -0,0 +1,18 @@
+.. _appendix-example-header:
+
+Example header file
+-------------------
+
+Each implementation of the PSA Crypto API must provide a header file named **psa/crypto.h**, in which the API elements in this specification are defined.
+
+This appendix provides a example of the **psa/crypto.h** header file with all of the API elements. This can be used as a starting point or reference for an implementation.
+
+.. note:
+    Not all of the API elements are fully defined. An implementation must provide the full definition.
+
+    The header will not compile without these missing definitions, and might require reordering to satisfy C compilation rules.
+
+psa/crypto.h
+~~~~~~~~~~~~
+
+.. autoinclude:: /../include/psa/crypto.h
diff --git a/docs/html/_sources/appendix/history.rst.txt b/docs/html/_sources/appendix/history.rst.txt
new file mode 100644
index 0000000..494ad62
--- /dev/null
+++ b/docs/html/_sources/appendix/history.rst.txt
@@ -0,0 +1,623 @@
+Changes to the API
+==================
+
+Release information
+-------------------
+
+All published versions of this document have been **non-confidential**.
+
+The change history table lists the changes that have been made to this document.
+
+.. tabularcolumns:: |\Y{.15}\Y{.15}\Y{.7}|
+
+.. list-table::
+    :header-rows: 1
+    :widths: 3,3,14
+
+    *   -   **Date**
+        -   **Version**
+        -   **Comments**
+
+    *   -   **Jan 2019**
+        -   1.0 beta 1
+        -   First public beta release.
+
+    *   -   **Feb 2019**
+        -   1.0 beta 2
+        -   Update for release with other PSA Dev API specifications.
+
+    *   -   **May 2019**
+        -   1.0 beta 3
+        -   Update for release with other PSA API specifications.
+
+            * Alignment with PSA API specifications.
+            * Changes to the key creation API.
+            * Changes to the handling of key lifetimes.
+            * Replaced 'generators' with key derivation operations.
+
+    *   -   **Feb 2020**
+        -   1.0.0
+        -   1.0 API finalized.
+
+            * Removed implementation APIs and definitions.
+            * Merged key handles with key identifiers.
+            * Recoded algorithm identifiers.
+            * Restructured key types.
+            * Provide buffer size macros for all output buffers.
+            * Provide sign-message signature operations.
+            * Add functions to suspend and resume hash operations.
+            * Reallocated key types and algorithm identifiers.
+            * Many minor corrections and clarifications.
+
+The detailed changes in each release are described in the following sections.
+
+Document change history
+-----------------------
+
+Changes between *1.0 beta 1* and *1.0 beta 2*
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. rubric:: Changes to the API
+
+-   Remove obsolete definition ``PSA_ALG_IS_KEY_SELECTION``.
+-   `PSA_AEAD_FINISH_OUTPUT_SIZE`: remove spurious parameter ``plaintext_length``.
+
+.. rubric:: Clarifications
+
+-   ``psa_key_agreement()``: document ``alg`` parameter.
+
+.. rubric:: Other changes
+
+-   Document formatting improvements.
+
+Changes between *1.0 beta 2* and *1.0 beta 3*
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. rubric:: Changes to the API
+
+-   Change the value of error codes, and some names, to align
+    with other PSA specifications. The name changes are:
+
+    * ``PSA_ERROR_UNKNOWN_ERROR`` → `PSA_ERROR_GENERIC_ERROR`
+    * ``PSA_ERROR_OCCUPIED_SLOT`` → `PSA_ERROR_ALREADY_EXISTS`
+    * ``PSA_ERROR_EMPTY_SLOT`` → `PSA_ERROR_DOES_NOT_EXIST`
+    * ``PSA_ERROR_INSUFFICIENT_CAPACITY`` → `PSA_ERROR_INSUFFICIENT_DATA`
+    * ``PSA_ERROR_TAMPERING_DETECTED`` → `PSA_ERROR_CORRUPTION_DETECTED`
+
+-   Change the way keys are created to avoid “half-filled” handles
+    that contained key metadata, but no key material.
+    Now, to create a key, first fill in a data structure containing
+    its attributes, then pass this structure to a function that
+    both allocates resources for the key and fills in the key
+    material. This affects the following functions:
+
+    * `psa_import_key()`, `psa_generate_key()`, ``psa_generator_import_key()``
+      and `psa_copy_key()` now take an attribute structure, as
+      a pointer to `psa_key_attributes_t`, to specify key metadata.
+      This replaces the previous method of passing arguments to
+      ``psa_create_key()`` or to the key material creation function
+      or calling ``psa_set_key_policy()``.
+    * ``psa_key_policy_t`` and functions operating on that type
+      no longer exist. A key's policy is now accessible as part of
+      its attributes.
+    * ``psa_get_key_information()`` is also replaced by accessing the
+      key's attributes, retrieved with `psa_get_key_attributes()`.
+    * ``psa_create_key()`` no longer exists. Instead, set the key id
+      attribute and the lifetime attribute before creating the
+      key material.
+
+-   Allow `psa_aead_update()` to buffer data.
+
+-   New buffer size calculation macros.
+
+-   Key identifiers are no longer specific to a given lifetime value. ``psa_open_key()`` no longer takes a ``lifetime`` parameter.
+
+-   Define a range of key identifiers for use by applications and a separate range for use by implementations.
+
+-   Avoid the unusual terminology "generator": call them
+    "key derivation operations" instead. Rename a number of functions
+    and other identifiers related to for clarity and consistency:
+
+    * ``psa_crypto_generator_t`` → `psa_key_derivation_operation_t`
+    * ``PSA_CRYPTO_GENERATOR_INIT`` → `PSA_KEY_DERIVATION_OPERATION_INIT`
+    * ``psa_crypto_generator_init()`` → `psa_key_derivation_operation_init()`
+    * ``PSA_GENERATOR_UNBRIDLED_CAPACITY`` → `PSA_KEY_DERIVATION_UNLIMITED_CAPACITY`
+    * ``psa_set_generator_capacity()`` → `psa_key_derivation_set_capacity()`
+    * ``psa_get_generator_capacity()`` → `psa_key_derivation_get_capacity()`
+    * ``psa_key_agreement()`` → `psa_key_derivation_key_agreement()`
+    * ``psa_generator_read()`` → `psa_key_derivation_output_bytes()`
+    * ``psa_generate_derived_key()`` → `psa_key_derivation_output_key()`
+    * ``psa_generator_abort()`` → `psa_key_derivation_abort()`
+    * ``psa_key_agreement_raw_shared_secret()`` → `psa_raw_key_agreement()`
+    * ``PSA_KDF_STEP_xxx`` → ``PSA_KEY_DERIVATION_INPUT_xxx``
+    * ``PSA_xxx_KEYPAIR`` → ``PSA_xxx_KEY_PAIR``
+
+-   Convert TLS1.2 KDF descriptions to multistep key derivation.
+
+.. rubric:: Clarifications
+
+-   Specify ``psa_generator_import_key()`` for most key types.
+
+-   Clarify the behavior in various corner cases.
+
+-   Document more error conditions.
+
+Changes between *1.0 beta 3* and *1.0.0*
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. rubric:: Changes to the API
+
+-   Added `PSA_CRYPTO_API_VERSION_MAJOR` and `PSA_CRYPTO_API_VERSION_MINOR` to report the PSA Cyrpto API version.
+
+-   Removed ``PSA_ALG_GMAC`` algorithm identifier.
+
+-   Removed internal implementation macros from the API specification:
+
+    * ``PSA_AEAD_TAG_LENGTH_OFFSET``
+    * ``PSA_ALG_AEAD_FROM_BLOCK_FLAG``
+    * ``PSA_ALG_AEAD_TAG_LENGTH_MASK``
+    * ``PSA__ALG_AEAD_WITH_DEFAULT_TAG_LENGTH__CASE``
+    * ``PSA_ALG_CATEGORY_AEAD``
+    * ``PSA_ALG_CATEGORY_ASYMMETRIC_ENCRYPTION``
+    * ``PSA_ALG_CATEGORY_CIPHER``
+    * ``PSA_ALG_CATEGORY_HASH``
+    * ``PSA_ALG_CATEGORY_KEY_AGREEMENT``
+    * ``PSA_ALG_CATEGORY_KEY_DERIVATION``
+    * ``PSA_ALG_CATEGORY_MAC``
+    * ``PSA_ALG_CATEGORY_MASK``
+    * ``PSA_ALG_CATEGORY_SIGN``
+    * ``PSA_ALG_CIPHER_FROM_BLOCK_FLAG``
+    * ``PSA_ALG_CIPHER_MAC_BASE``
+    * ``PSA_ALG_CIPHER_STREAM_FLAG``
+    * ``PSA_ALG_DETERMINISTIC_ECDSA_BASE``
+    * ``PSA_ALG_ECDSA_BASE``
+    * ``PSA_ALG_ECDSA_IS_DETERMINISTIC``
+    * ``PSA_ALG_HASH_MASK``
+    * ``PSA_ALG_HKDF_BASE``
+    * ``PSA_ALG_HMAC_BASE``
+    * ``PSA_ALG_IS_KEY_DERIVATION_OR_AGREEMENT``
+    * ``PSA_ALG_IS_VENDOR_DEFINED``
+    * ``PSA_ALG_KEY_AGREEMENT_MASK``
+    * ``PSA_ALG_KEY_DERIVATION_MASK``
+    * ``PSA_ALG_MAC_SUBCATEGORY_MASK``
+    * ``PSA_ALG_MAC_TRUNCATION_MASK``
+    * ``PSA_ALG_RSA_OAEP_BASE``
+    * ``PSA_ALG_RSA_PKCS1V15_SIGN_BASE``
+    * ``PSA_ALG_RSA_PSS_BASE``
+    * ``PSA_ALG_TLS12_PRF_BASE``
+    * ``PSA_ALG_TLS12_PSK_TO_MS_BASE``
+    * ``PSA_ALG_VENDOR_FLAG``
+    * ``PSA_BITS_TO_BYTES``
+    * ``PSA_BYTES_TO_BITS``
+    * ``PSA_ECDSA_SIGNATURE_SIZE``
+    * ``PSA_HMAC_MAX_HASH_BLOCK_SIZE``
+    * ``PSA_KEY_EXPORT_ASN1_INTEGER_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_DSA_KEY_PAIR_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_DSA_PUBLIC_KEY_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_ECC_KEY_PAIR_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_ECC_PUBLIC_KEY_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_RSA_KEY_PAIR_MAX_SIZE``
+    * ``PSA_KEY_EXPORT_RSA_PUBLIC_KEY_MAX_SIZE``
+    * ``PSA_KEY_TYPE_CATEGORY_FLAG_PAIR``
+    * ``PSA_KEY_TYPE_CATEGORY_KEY_PAIR``
+    * ``PSA_KEY_TYPE_CATEGORY_MASK``
+    * ``PSA_KEY_TYPE_CATEGORY_PUBLIC_KEY``
+    * ``PSA_KEY_TYPE_CATEGORY_RAW``
+    * ``PSA_KEY_TYPE_CATEGORY_SYMMETRIC``
+    * ``PSA_KEY_TYPE_DH_GROUP_MASK``
+    * ``PSA_KEY_TYPE_DH_KEY_PAIR_BASE``
+    * ``PSA_KEY_TYPE_DH_PUBLIC_KEY_BASE``
+    * ``PSA_KEY_TYPE_ECC_CURVE_MASK``
+    * ``PSA_KEY_TYPE_ECC_KEY_PAIR_BASE``
+    * ``PSA_KEY_TYPE_ECC_PUBLIC_KEY_BASE``
+    * ``PSA_KEY_TYPE_IS_VENDOR_DEFINED``
+    * ``PSA_KEY_TYPE_VENDOR_FLAG``
+    * ``PSA_MAC_TRUNCATED_LENGTH``
+    * ``PSA_MAC_TRUNCATION_OFFSET``
+    * ``PSA_ROUND_UP_TO_MULTIPLE``
+    * ``PSA_RSA_MINIMUM_PADDING_SIZE``
+    * ``PSA_VENDOR_ECC_MAX_CURVE_BITS``
+    * ``PSA_VENDOR_RSA_MAX_KEY_BITS``
+
+-   Remove the definition of implementation-defined macros from the specification, and clarified the implementation requirements for these macros in :title:`implementation-specific-macro`.
+
+    * Macros with implementation-defined values are indicated by ``/* implementation-defined value */`` in the API prototype.
+      The implementation must provide the implementation.
+
+    * Macros for algorithm and key type construction and inspection have specification-defined values.
+      This is indicated by ``/* specification-defined value */`` in the API prototype.
+      Example definitions of these macros is provided in :title:`appendix-specdef-values`.
+
+-   Changed the semantics of multi-part operations.
+
+    * Formalize the standard pattern for multi-part operations.
+    * Require all errors to result in an error state, requiring a call to ``psa_xxx_abort()`` to reset the object.
+    * Define behavior in illegal and impossible operation states, and for copying and reusing operation objects.
+
+    Although the API signatures have not changed, this change requires modifications to application flows that handle error conditions in multi-part operations.
+
+-   Merge the key identifier and key handle concepts in the API.
+
+    * Replaced all references to key handles with key identifiers, or something similar.
+    * Replaced all uses of ``psa_key_handle_t`` with `psa_key_id_t` in the API, and removes the ``psa_key_handle_t`` type.
+    * Removed ``psa_open_key`` and ``psa_close_key``.
+    * Added `PSA_KEY_ID_NULL` for the never valid zero key identifier.
+    * Document rules related to destroying keys whilst in use.
+    * Added the `PSA_KEY_USAGE_CACHE` usage policy and the related `psa_purge_key()` API.
+    * Added clarification about caching keys to non-volatile memory.
+
+-   Renamed ``PSA_ALG_TLS12_PSK_TO_MS_MAX_PSK_LEN`` to `PSA_TLS12_PSK_TO_MS_PSK_MAX_SIZE`.
+
+-   Relax definition of implementation-defined types.
+
+    * This is indicated in the specification by ``/* implementation-defined type */`` in the type definition.
+    * The specification only defines the name of implementation-defined types, and does not require that the implementation is a C struct.
+
+-   Zero-length keys are not permitted. Attempting to create one will now result in an error.
+
+-   Relax the constraints on inputs to key derivation:
+
+    * `psa_key_derivation_input_bytes()` can be used for secret input steps. This is necessary if a zero-length input is required by the application.
+    * `psa_key_derivation_input_key()` can be used for non-secret input steps.
+
+-   Multi-part cipher operations now require that the IV is passed using `psa_cipher_set_iv()`, the option to provide this as part of the input to `psa_cipher_update()` has been removed.
+
+    The format of the output from `psa_cipher_encrypt()`, and input to `psa_cipher_decrypt()`, is documented.
+
+-   Support macros to calculate the size of output buffers, IVs and nonces.
+
+    -   Macros to calculate a key and/or algorithm specific result are provided for all output buffers. The new macros are:
+
+        * `PSA_AEAD_NONCE_LENGTH()`
+        * `PSA_CIPHER_ENCRYPT_OUTPUT_SIZE()`
+        * `PSA_CIPHER_DECRYPT_OUTPUT_SIZE()`
+        * `PSA_CIPHER_UPDATE_OUTPUT_SIZE()`
+        * `PSA_CIPHER_FINISH_OUTPUT_SIZE()`
+        * `PSA_CIPHER_IV_LENGTH()`
+        * `PSA_EXPORT_PUBLIC_KEY_OUTPUT_SIZE()`
+        * `PSA_RAW_KEY_AGREEMENT_OUTPUT_SIZE()`
+
+    -   Macros that evaluate to a maximum type-independent buffer size are provided. The new macros are:
+
+        * `PSA_AEAD_ENCRYPT_OUTPUT_MAX_SIZE()`
+        * `PSA_AEAD_DECRYPT_OUTPUT_MAX_SIZE()`
+        * `PSA_AEAD_UPDATE_OUTPUT_MAX_SIZE()`
+        * `PSA_AEAD_FINISH_OUTPUT_MAX_SIZE`
+        * `PSA_AEAD_VERIFY_OUTPUT_MAX_SIZE`
+        * `PSA_AEAD_NONCE_MAX_SIZE`
+        * `PSA_AEAD_TAG_MAX_SIZE`
+        * `PSA_ASYMMETRIC_ENCRYPT_OUTPUT_MAX_SIZE`
+        * `PSA_ASYMMETRIC_DECRYPT_OUTPUT_MAX_SIZE`
+        * `PSA_CIPHER_ENCRYPT_OUTPUT_MAX_SIZE()`
+        * `PSA_CIPHER_DECRYPT_OUTPUT_MAX_SIZE()`
+        * `PSA_CIPHER_UPDATE_OUTPUT_MAX_SIZE()`
+        * `PSA_CIPHER_FINISH_OUTPUT_MAX_SIZE`
+        * `PSA_CIPHER_IV_MAX_SIZE`
+        * `PSA_EXPORT_KEY_PAIR_MAX_SIZE`
+        * `PSA_EXPORT_PUBLIC_KEY_MAX_SIZE`
+        * `PSA_RAW_KEY_AGREEMENT_OUTPUT_MAX_SIZE`
+
+    -   AEAD output buffer size macros are now parameterized on the key type as well as the algorithm:
+
+        * `PSA_AEAD_ENCRYPT_OUTPUT_SIZE()`
+        * `PSA_AEAD_DECRYPT_OUTPUT_SIZE()`
+        * `PSA_AEAD_UPDATE_OUTPUT_SIZE()`
+        * `PSA_AEAD_FINISH_OUTPUT_SIZE()`
+        * `PSA_AEAD_TAG_LENGTH()`
+        * `PSA_AEAD_VERIFY_OUTPUT_SIZE()`
+
+    -   Some existing macros have been renamed to ensure that the name of the support macros are consistent. The following macros have been renamed:
+
+        * ``PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH()`` → `PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG()`
+        * ``PSA_ALG_AEAD_WITH_TAG_LENGTH()`` → `PSA_ALG_AEAD_WITH_SHORTENED_TAG()`
+        * ``PSA_KEY_EXPORT_MAX_SIZE()`` → `PSA_EXPORT_KEY_OUTPUT_SIZE()`
+        * ``PSA_HASH_SIZE()`` → `PSA_HASH_LENGTH()`
+        * ``PSA_MAC_FINAL_SIZE()`` → `PSA_MAC_LENGTH()`
+        * ``PSA_BLOCK_CIPHER_BLOCK_SIZE()`` → `PSA_BLOCK_CIPHER_BLOCK_LENGTH()`
+        * ``PSA_MAX_BLOCK_CIPHER_BLOCK_SIZE`` → `PSA_BLOCK_CIPHER_BLOCK_MAX_SIZE`
+
+    -   Documentation of the macros and of related APIs has been updated to reference the related API elements.
+
+-   Provide hash-and-sign operations as well as sign-the-hash operations. The API for asymmetric signature has been changed to clarify the use of the new functions.
+
+    - The existing asymmetric signature API has been renamed to clarify that this is for signing a hash that is already computed:
+
+      * ``PSA_KEY_USAGE_SIGN`` → `PSA_KEY_USAGE_SIGN_HASH`
+      * ``PSA_KEY_USAGE_VERIFY`` → `PSA_KEY_USAGE_VERIFY_HASH`
+      * ``psa_asymmetric_sign()`` → `psa_sign_hash()`
+      * ``psa_asymmetric_verify()`` → `psa_verify_hash()`
+
+    - New APIs added to provide the complete message signing operation:
+
+      * `PSA_KEY_USAGE_SIGN_MESSAGE`
+      * `PSA_KEY_USAGE_VERIFY_MESSAGE`
+      * `psa_sign_message()`
+      * `psa_verify_message()`
+
+    - New Support macros to identify which algorithms can be used in which signing API:
+
+      * `PSA_ALG_IS_SIGN_HASH()`
+      * `PSA_ALG_IS_SIGN_MESSAGE()`
+
+    - Renamed support macros that apply to both signing APIs:
+
+      * ``PSA_ASYMMETRIC_SIGN_OUTPUT_SIZE()`` → `PSA_SIGN_OUTPUT_SIZE()`
+      * ``PSA_ASYMMETRIC_SIGNATURE_MAX_SIZE`` → `PSA_SIGNATURE_MAX_SIZE`
+
+    - The usage policy values have been changed, including for `PSA_KEY_USAGE_DERIVE`.
+
+-   Restructure `psa_key_type_t` and reassign all key type values.
+
+    - `psa_key_type_t` changes from 32-bit to 16-bit integer.
+    - Reassigned the key type categories.
+    - Add a parity bit to the key type to ensure that valid key type values differ by at least 2 bits.
+    - 16-bit elliptic curve ids (``psa_ecc_curve_t``) replaced by 8-bit ECC curve family ids (`psa_ecc_family_t`).
+      16-bit  Diffie-Hellman group ids (``psa_dh_group_t``) replaced by 8-bit DH group family ids (`psa_dh_family_t`).
+
+      * These ids are no longer related to the IANA Group Registry specification.
+      * The new key type values do not encode the key size for ECC curves or DH groups. The key bit size from the key attributes identify a specific ECC curve or DH group within the family.
+
+    -   The following macros have been removed:
+
+        * ``PSA_DH_GROUP_FFDHE2048``
+        * ``PSA_DH_GROUP_FFDHE3072``
+        * ``PSA_DH_GROUP_FFDHE4096``
+        * ``PSA_DH_GROUP_FFDHE6144``
+        * ``PSA_DH_GROUP_FFDHE8192``
+        * ``PSA_ECC_CURVE_BITS``
+        * ``PSA_ECC_CURVE_BRAINPOOL_P256R1``
+        * ``PSA_ECC_CURVE_BRAINPOOL_P384R1``
+        * ``PSA_ECC_CURVE_BRAINPOOL_P512R1``
+        * ``PSA_ECC_CURVE_CURVE25519``
+        * ``PSA_ECC_CURVE_CURVE448``
+        * ``PSA_ECC_CURVE_SECP160K1``
+        * ``PSA_ECC_CURVE_SECP160R1``
+        * ``PSA_ECC_CURVE_SECP160R2``
+        * ``PSA_ECC_CURVE_SECP192K1``
+        * ``PSA_ECC_CURVE_SECP192R1``
+        * ``PSA_ECC_CURVE_SECP224K1``
+        * ``PSA_ECC_CURVE_SECP224R1``
+        * ``PSA_ECC_CURVE_SECP256K1``
+        * ``PSA_ECC_CURVE_SECP256R1``
+        * ``PSA_ECC_CURVE_SECP384R1``
+        * ``PSA_ECC_CURVE_SECP521R1``
+        * ``PSA_ECC_CURVE_SECT163K1``
+        * ``PSA_ECC_CURVE_SECT163R1``
+        * ``PSA_ECC_CURVE_SECT163R2``
+        * ``PSA_ECC_CURVE_SECT193R1``
+        * ``PSA_ECC_CURVE_SECT193R2``
+        * ``PSA_ECC_CURVE_SECT233K1``
+        * ``PSA_ECC_CURVE_SECT233R1``
+        * ``PSA_ECC_CURVE_SECT239K1``
+        * ``PSA_ECC_CURVE_SECT283K1``
+        * ``PSA_ECC_CURVE_SECT283R1``
+        * ``PSA_ECC_CURVE_SECT409K1``
+        * ``PSA_ECC_CURVE_SECT409R1``
+        * ``PSA_ECC_CURVE_SECT571K1``
+        * ``PSA_ECC_CURVE_SECT571R1``
+        * ``PSA_KEY_TYPE_GET_CURVE``
+        * ``PSA_KEY_TYPE_GET_GROUP``
+
+    -   The following macros have been added:
+
+        * `PSA_DH_FAMILY_RFC7919`
+        * `PSA_ECC_FAMILY_BRAINPOOL_P_R1`
+        * `PSA_ECC_FAMILY_SECP_K1`
+        * `PSA_ECC_FAMILY_SECP_R1`
+        * `PSA_ECC_FAMILY_SECP_R2`
+        * `PSA_ECC_FAMILY_SECT_K1`
+        * `PSA_ECC_FAMILY_SECT_R1`
+        * `PSA_ECC_FAMILY_SECT_R2`
+        * `PSA_ECC_FAMILY_MONTGOMERY`
+        * `PSA_KEY_TYPE_DH_GET_FAMILY`
+        * `PSA_KEY_TYPE_ECC_GET_FAMILY`
+
+    -   The following macros have new values:
+
+        * `PSA_KEY_TYPE_AES`
+        * `PSA_KEY_TYPE_ARC4`
+        * `PSA_KEY_TYPE_CAMELLIA`
+        * `PSA_KEY_TYPE_CHACHA20`
+        * `PSA_KEY_TYPE_DERIVE`
+        * `PSA_KEY_TYPE_DES`
+        * `PSA_KEY_TYPE_HMAC`
+        * `PSA_KEY_TYPE_NONE`
+        * `PSA_KEY_TYPE_RAW_DATA`
+        * `PSA_KEY_TYPE_RSA_KEY_PAIR`
+        * `PSA_KEY_TYPE_RSA_PUBLIC_KEY`
+
+    -   The following macros with specification-defined values have new example implementations:
+
+        * `PSA_BLOCK_CIPHER_BLOCK_LENGTH`
+        * `PSA_KEY_TYPE_DH_KEY_PAIR`
+        * `PSA_KEY_TYPE_DH_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_ECC_KEY_PAIR`
+        * `PSA_KEY_TYPE_ECC_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_IS_ASYMMETRIC`
+        * `PSA_KEY_TYPE_IS_DH`
+        * `PSA_KEY_TYPE_IS_DH_KEY_PAIR`
+        * `PSA_KEY_TYPE_IS_DH_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_IS_ECC`
+        * `PSA_KEY_TYPE_IS_ECC_KEY_PAIR`
+        * `PSA_KEY_TYPE_IS_ECC_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_IS_KEY_PAIR`
+        * `PSA_KEY_TYPE_IS_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_IS_RSA`
+        * `PSA_KEY_TYPE_IS_UNSTRUCTURED`
+        * `PSA_KEY_TYPE_KEY_PAIR_OF_PUBLIC_KEY`
+        * `PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR`
+
+-   Add ECC family `PSA_ECC_FAMILY_FRP` for the FRP256v1 curve.
+
+-   Restructure `psa_algorithm_t` encoding, to increase consistency across algorithm categories.
+
+    -   Algorithms that include a hash operation all use the same structure to encode the hash algorithm. The following ``PSA_ALG_XXXX_GET_HASH()`` macros have all been replaced by a single macro `PSA_ALG_GET_HASH()`:
+
+        * ``PSA_ALG_HKDF_GET_HASH()``
+        * ``PSA_ALG_HMAC_GET_HASH()``
+        * ``PSA_ALG_RSA_OAEP_GET_HASH()``
+        * ``PSA_ALG_SIGN_GET_HASH()``
+        * ``PSA_ALG_TLS12_PRF_GET_HASH()``
+        * ``PSA_ALG_TLS12_PSK_TO_MS_GET_HASH()``
+
+    -   Stream cipher algorithm macros have been removed; the key type indicates which cipher to use. Instead of ``PSA_ALG_ARC4`` and ``PSA_ALG_CHACHA20``, use `PSA_ALG_STREAM_CIPHER`.
+
+    All of the other ``PSA_ALG_XXX`` macros have updated values or updated example implementations.
+
+    -   The following macros have new values:
+
+        * `PSA_ALG_ANY_HASH`
+        * `PSA_ALG_CBC_MAC`
+        * `PSA_ALG_CBC_NO_PADDING`
+        * `PSA_ALG_CBC_PKCS7`
+        * `PSA_ALG_CCM`
+        * `PSA_ALG_CFB`
+        * `PSA_ALG_CHACHA20_POLY1305`
+        * `PSA_ALG_CMAC`
+        * `PSA_ALG_CTR`
+        * `PSA_ALG_ECDH`
+        * `PSA_ALG_ECDSA_ANY`
+        * `PSA_ALG_FFDH`
+        * `PSA_ALG_GCM`
+        * `PSA_ALG_MD2`
+        * `PSA_ALG_MD4`
+        * `PSA_ALG_MD5`
+        * `PSA_ALG_OFB`
+        * `PSA_ALG_RIPEMD160`
+        * `PSA_ALG_RSA_PKCS1V15_CRYPT`
+        * `PSA_ALG_RSA_PKCS1V15_SIGN_RAW`
+        * `PSA_ALG_SHA_1`
+        * `PSA_ALG_SHA_224`
+        * `PSA_ALG_SHA_256`
+        * `PSA_ALG_SHA_384`
+        * `PSA_ALG_SHA_512`
+        * `PSA_ALG_SHA_512_224`
+        * `PSA_ALG_SHA_512_256`
+        * `PSA_ALG_SHA3_224`
+        * `PSA_ALG_SHA3_256`
+        * `PSA_ALG_SHA3_384`
+        * `PSA_ALG_SHA3_512`
+        * `PSA_ALG_XTS`
+
+    -   The following macros with specification-defined values have new example implementations:
+
+        * `PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG()`
+        * `PSA_ALG_AEAD_WITH_SHORTENED_TAG()`
+        * `PSA_ALG_DETERMINISTIC_ECDSA()`
+        * `PSA_ALG_ECDSA()`
+        * `PSA_ALG_FULL_LENGTH_MAC()`
+        * `PSA_ALG_HKDF()`
+        * `PSA_ALG_HMAC()`
+        * `PSA_ALG_IS_AEAD()`
+        * `PSA_ALG_IS_AEAD_ON_BLOCK_CIPHER()`
+        * `PSA_ALG_IS_ASYMMETRIC_ENCRYPTION()`
+        * `PSA_ALG_IS_BLOCK_CIPHER_MAC()`
+        * `PSA_ALG_IS_CIPHER()`
+        * `PSA_ALG_IS_DETERMINISTIC_ECDSA()`
+        * `PSA_ALG_IS_ECDH()`
+        * `PSA_ALG_IS_ECDSA()`
+        * `PSA_ALG_IS_FFDH()`
+        * `PSA_ALG_IS_HASH()`
+        * `PSA_ALG_IS_HASH_AND_SIGN()`
+        * `PSA_ALG_IS_HKDF()`
+        * `PSA_ALG_IS_HMAC()`
+        * `PSA_ALG_IS_KEY_AGREEMENT()`
+        * `PSA_ALG_IS_KEY_DERIVATION()`
+        * `PSA_ALG_IS_MAC()`
+        * `PSA_ALG_IS_RANDOMIZED_ECDSA()`
+        * `PSA_ALG_IS_RAW_KEY_AGREEMENT()`
+        * `PSA_ALG_IS_RSA_OAEP()`
+        * `PSA_ALG_IS_RSA_PKCS1V15_SIGN()`
+        * `PSA_ALG_IS_RSA_PSS()`
+        * `PSA_ALG_IS_SIGN()`
+        * `PSA_ALG_IS_SIGN_MESSAGE()`
+        * `PSA_ALG_IS_STREAM_CIPHER()`
+        * `PSA_ALG_IS_TLS12_PRF()`
+        * `PSA_ALG_IS_TLS12_PSK_TO_MS()`
+        * `PSA_ALG_IS_WILDCARD()`
+        * `PSA_ALG_KEY_AGREEMENT()`
+        * `PSA_ALG_KEY_AGREEMENT_GET_BASE()`
+        * `PSA_ALG_KEY_AGREEMENT_GET_KDF()`
+        * `PSA_ALG_RSA_OAEP()`
+        * `PSA_ALG_RSA_PKCS1V15_SIGN()`
+        * `PSA_ALG_RSA_PSS()`
+        * `PSA_ALG_TLS12_PRF()`
+        * `PSA_ALG_TLS12_PSK_TO_MS()`
+        * `PSA_ALG_TRUNCATED_MAC()`
+
+-   Added ECB block cipher mode, with no padding, as `PSA_ALG_ECB_NO_PADDING`.
+
+-   Add functions to suspend and resume hash operations:
+
+    * `psa_hash_suspend()` halts the current operation and outputs a hash suspend state.
+    * `psa_hash_resume()` continues a previously suspended hash operation.
+
+    The format of the hash suspend state is documented in :title:`hash-suspend-state`, and supporting macros are provided for using this API:
+
+    * `PSA_HASH_SUSPEND_OUTPUT_SIZE()`
+    * `PSA_HASH_SUSPEND_OUTPUT_MAX_SIZE`
+    * `PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH`
+    * `PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH()`
+    * `PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH()`
+    * `PSA_HASH_BLOCK_LENGTH()`
+
+-   Complement `PSA_ERROR_STORAGE_FAILURE` with new error codes `PSA_ERROR_DATA_CORRUPT` and `PSA_ERROR_DATA_INVALID`. These permit an implementation to distinguish different causes of failure when reading from key storage.
+
+-   Added input step `PSA_KEY_DERIVATION_INPUT_CONTEXT` for key derivation, supporting obvious mapping from the step identifiers to common KDF constructions.
+
+.. rubric:: Clarifications
+
+-   Clarified rules regarding modification of parameters in concurrent environments.
+
+-   Guarantee that :code:`psa_destroy_key(PSA_KEY_ID_NULL)` always returns `PSA_SUCCESS`.
+
+-   Clarified the TLS PSK to MS key agreement algorithm.
+
+-   Document the key policy requirements for all APIs that accept a key parameter.
+
+-   Document more of the error codes for each function.
+
+.. rubric:: Other changes
+
+-   Require C99 for this specification instead of C89.
+
+-   Removed references to non-standard mbed-crypto header files. The only header file that applications need to include is **psa/crypto.h**.
+
+-   Reorganized the API reference, grouping the elements in a more natural way.
+
+-   Improved the cross referencing between all of the document sections, and from code snippets to API element descriptions.
+
+Planned changes for version 1.0.x
+---------------------------------
+
+Future versions of this specification that use a 1.0.x version will describe the same API as this specification. Any changes will not affect application compatibility and will not introduce major features. These updates are intended to add minor requirements on implementations, introduce optional definitions, make corrections, clarify potential or actual ambiguities, or improve the documentation.
+
+These are the changes that we are currently planning to make for version 1.0.x:
+
+* Declare identifiers for additional cryptographic algorithms.
+* Mandate certain checks when importing some types of asymmetric keys.
+* Specify the computation of algorithm and key type values.
+* Further clarifications on API usage and implementation.
+
+
+.. _future:
+
+Future additions
+----------------
+
+Major additions to the API will be defined in future drafts and editions of a 1.x or 2.x version of this specification. Features that are being considered include:
+
+-  Multi-part operations for hybrid cryptography. For example, this includes
+   hash-and-sign for EdDSA, and hybrid encryption for ECIES.
+-  A more general interface to key derivation and key exchange. This would
+   enable an application to derive a non-extractable session key from
+   non-extractable secrets, without leaking the intermediate material.
+-  Key wrapping mechanisms to extract and import keys in an encrypted and authenticated form.
+-  Key discovery mechanisms. This would enable an application to locate a key by
+   its name or attributes.
+-  Implementation capability description. This would enable an application to
+   determine the algorithms, key types and storage lifetimes that the
+   implementation provides.
+-  An ownership and access control mechanism allowing a multi-client
+   implementation to have privileged clients that are able to manage keys of
+   other clients.
diff --git a/docs/html/_sources/appendix/specdef_values.rst.txt b/docs/html/_sources/appendix/specdef_values.rst.txt
new file mode 100644
index 0000000..3a6a06e
--- /dev/null
+++ b/docs/html/_sources/appendix/specdef_values.rst.txt
@@ -0,0 +1,231 @@
+.. _appendix-specdef-values:
+
+Example macro implementations
+-----------------------------
+
+This appendix provides example implementations of the function-like macros that have specification-defined values.
+
+.. note::
+    In a future version of this specification, these example implementations will be replaced with a pseudo-code representation of the macro's computation in the macro description.
+
+The examples here provide correct results for the valid inputs defined by each API, for an implementation that supports all of the defined algorithms and key types. An implementation can provide alternative definitions of these macros:
+
+* If the implementation does not support all of the algorithms or key types, it can provide a simpler definition of applicable macros.
+* If the implementation provides vendor-specific algorithms or key types, it needs to extend the definitions of applicable macros.
+
+Algorithm macros
+~~~~~~~~~~~~~~~~
+
+:code:`PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG(aead_alg)`
+    :code:`((((aead_alg) & ~0x003f0000) == 0x05400100) ? PSA_ALG_CCM : (((aead_alg) & ~0x003f0000) == 0x05400200) ? PSA_ALG_GCM : (((aead_alg) & ~0x003f0000) == 0x05000500) ? PSA_ALG_CHACHA20_POLY1305 : PSA_ALG_NONE)`
+
+:code:`PSA_ALG_AEAD_WITH_SHORTENED_TAG(aead_alg, tag_length)`
+    :code:`((psa_algorithm_t) (((aead_alg) & ~0x003f0000) | (((tag_length) & 0x3f) << 16)))`
+
+:code:`PSA_ALG_DETERMINISTIC_ECDSA(hash_alg)`
+    :code:`((psa_algorithm_t) (0x06000700 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_ECDSA(hash_alg)`
+    :code:`((psa_algorithm_t) (0x06000600 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_FULL_LENGTH_MAC(mac_alg)`
+    :code:`((psa_algorithm_t) ((mac_alg) & ~0x003f0000))`
+
+:code:`PSA_ALG_GET_HASH(alg)`
+    :code:`(((alg) & 0x000000ff) == 0 ? PSA_ALG_NONE : 0x02000000 | ((alg) & 0x000000ff))`
+
+:code:`PSA_ALG_HKDF(hash_alg)`
+    :code:`((psa_algorithm_t) (0x08000100 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_HMAC(hash_alg)`
+    :code:`((psa_algorithm_t) (0x03800000 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_IS_AEAD(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x05000000)`
+
+:code:`PSA_ALG_IS_AEAD_ON_BLOCK_CIPHER(alg)`
+    :code:`(((alg) & 0x7f400000) == 0x05400000)`
+
+:code:`PSA_ALG_IS_ASYMMETRIC_ENCRYPTION(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x07000000)`
+
+:code:`PSA_ALG_IS_BLOCK_CIPHER_MAC(alg)`
+    :code:`(((alg) & 0x7fc00000) == 0x03c00000)`
+
+:code:`PSA_ALG_IS_CIPHER(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x03000000)`
+
+:code:`PSA_ALG_IS_DETERMINISTIC_ECDSA(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x06000700)`
+
+:code:`PSA_ALG_IS_ECDH(alg)`
+    :code:`(((alg) & 0x7fff0000) == 0x09020000)`
+
+:code:`PSA_ALG_IS_ECDSA(alg)`
+    :code:`(((alg) & ~0x000001ff) == 0x06000600)`
+
+:code:`PSA_ALG_IS_FFDH(alg)`
+    :code:`(((alg) & 0x7fff0000) == 0x09010000)`
+
+:code:`PSA_ALG_IS_HASH(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x02000000)`
+
+:code:`PSA_ALG_IS_HASH_AND_SIGN(alg)`
+    :code:`(PSA_ALG_IS_RSA_PSS(alg) || PSA_ALG_IS_RSA_PKCS1V15_SIGN(alg) || PSA_ALG_IS_ECDSA(alg))`
+
+:code:`PSA_ALG_IS_HKDF(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x08000100)`
+
+:code:`PSA_ALG_IS_HMAC(alg)`
+    :code:`(((alg) & 0x7fc0ff00) == 0x03800000)`
+
+:code:`PSA_ALG_IS_KEY_AGREEMENT(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x09000000)`
+
+:code:`PSA_ALG_IS_KEY_DERIVATION(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x08000000)`
+
+:code:`PSA_ALG_IS_MAC(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x03000000)`
+
+:code:`PSA_ALG_IS_RANDOMIZED_ECDSA(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x06000600)`
+
+:code:`PSA_ALG_IS_RAW_KEY_AGREEMENT(alg)`
+    :code:`(((alg) & 0x7f00ffff) == 0x09000000)`
+
+:code:`PSA_ALG_IS_RSA_OAEP(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x07000300)`
+
+:code:`PSA_ALG_IS_RSA_PKCS1V15_SIGN(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x06000200)`
+
+:code:`PSA_ALG_IS_RSA_PSS(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x06000300)`
+
+:code:`PSA_ALG_IS_SIGN(alg)`
+    :code:`(((alg) & 0x7f000000) == 0x06000000)`
+
+:code:`PSA_ALG_IS_SIGN_HASH(alg)`
+    :code:`PSA_ALG_IS_SIGN(alg)`
+
+:code:`PSA_ALG_IS_SIGN_MESSAGE(alg)`
+    :code:`(PSA_ALG_IS_SIGN(alg) && (alg) != PSA_ALG_ECDSA_ANY && (alg) != PSA_ALG_RSA_PKCS1V15_SIGN_RAW)`
+
+:code:`PSA_ALG_IS_STREAM_CIPHER(alg)`
+    :code:`(((alg) & 0x7f800000) == 0x04800000)`
+
+:code:`PSA_ALG_IS_TLS12_PRF(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x08000200)`
+
+:code:`PSA_ALG_IS_TLS12_PSK_TO_MS(alg)`
+    :code:`(((alg) & ~0x000000ff) == 0x08000300)`
+
+:code:`PSA_ALG_IS_WILDCARD(alg)`
+    :code:`(PSA_ALG_GET_HASH(alg) == PSA_ALG_HASH_ANY)`
+
+:code:`PSA_ALG_KEY_AGREEMENT(ka_alg, kdf_alg)`
+    :code:`((ka_alg) | (kdf_alg))`
+
+:code:`PSA_ALG_KEY_AGREEMENT_GET_BASE(alg)`
+    :code:`((psa_algorithm_t)((alg) & 0xffff0000))`
+
+:code:`PSA_ALG_KEY_AGREEMENT_GET_KDF(alg)`
+    :code:`((psa_algorithm_t)((alg) & 0xfe00ffff))`
+
+:code:`PSA_ALG_RSA_OAEP(hash_alg)`
+    :code:`((psa_algorithm_t)(0x07000300 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_RSA_PKCS1V15_SIGN(hash_alg)`
+    :code:`((psa_algorithm_t)(0x06000200 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_RSA_PSS(hash_alg)`
+    :code:`((psa_algorithm_t)(0x06000300 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_TLS12_PRF(hash_alg)`
+    :code:`((psa_algorithm_t) (0x08000200 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_TLS12_PSK_TO_MS(hash_alg)`
+    :code:`((psa_algorithm_t) (0x08000300 | ((hash_alg) & 0x000000ff)))`
+
+:code:`PSA_ALG_TRUNCATED_MAC(mac_alg, mac_length)`
+    :code:`((psa_algorithm_t) (((mac_alg) & ~0x003f0000) | (((mac_length) & 0x3f) << 16)))`
+
+Key type macros
+~~~~~~~~~~~~~~~
+
+:code:`PSA_BLOCK_CIPHER_BLOCK_LENGTH(type)`
+    :code:`(1u << (((type) >> 8) & 7))`
+
+:code:`PSA_KEY_TYPE_DH_GET_FAMILY(type)`
+    :code:`((psa_dh_family_t) ((type) & 0x00ff))`
+
+:code:`PSA_KEY_TYPE_DH_KEY_PAIR(group)`
+    :code:`((psa_key_type_t) (0x7200 | (group)))`
+
+:code:`PSA_KEY_TYPE_DH_PUBLIC_KEY(group)`
+    :code:`((psa_key_type_t) (0x4200 | (group)))`
+
+:code:`PSA_KEY_TYPE_ECC_GET_FAMILY(type)`
+    :code:`((psa_ecc_family_t) ((type) & 0x00ff))`
+
+:code:`PSA_KEY_TYPE_ECC_KEY_PAIR(curve)`
+    :code:`((psa_key_type_t) (0x7100 | (curve)))`
+
+:code:`PSA_KEY_TYPE_ECC_PUBLIC_KEY(curve)`
+    :code:`((psa_key_type_t) (0x4100 | (curve)))`
+
+:code:`PSA_KEY_TYPE_IS_ASYMMETRIC(type)`
+    :code:`(((type) & 0x4000) == 0x4000)`
+
+:code:`PSA_KEY_TYPE_IS_DH(type)`
+    :code:`((PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR(type) & 0xff00) == 0x4200)`
+
+:code:`PSA_KEY_TYPE_IS_DH_KEY_PAIR(type)`
+    :code:`(((type) & 0xff00) == 0x7200)`
+
+:code:`PSA_KEY_TYPE_IS_DH_PUBLIC_KEY(type)`
+    :code:`(((type) & 0xff00) == 0x4200)`
+
+:code:`PSA_KEY_TYPE_IS_ECC(type)`
+    :code:`((PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR(type) & 0xff00) == 0x4100)`
+
+:code:`PSA_KEY_TYPE_IS_ECC_KEY_PAIR(type)`
+    :code:`(((type) & 0xff00) == 0x7100)`
+
+:code:`PSA_KEY_TYPE_IS_ECC_PUBLIC_KEY(type)`
+    :code:`(((type) & 0xff00) == 0x4100)`
+
+:code:`PSA_KEY_TYPE_IS_KEY_PAIR(type)`
+    :code:`(((type) & 0x7000) == 0x7000)`
+
+:code:`PSA_KEY_TYPE_IS_PUBLIC_KEY(type)`
+    :code:`(((type) & 0x7000) == 0x4000)`
+
+:code:`PSA_KEY_TYPE_IS_RSA(type)`
+    :code:`(PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR(type) == 0x4001)`
+
+:code:`PSA_KEY_TYPE_IS_UNSTRUCTURED(type)`
+    :code:`(((type) & 0x7000) == 0x1000 || ((type) & 0x7000) == 0x2000)`
+
+:code:`PSA_KEY_TYPE_KEY_PAIR_OF_PUBLIC_KEY(type)`
+    :code:`((psa_key_type_t) ((type) | 0x3000))`
+
+:code:`PSA_KEY_TYPE_PUBLIC_KEY_OF_KEY_PAIR(type)`
+    :code:`((psa_key_type_t) ((type) & ~0x3000))`
+
+Hash suspend state macros
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+:code:`PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH(alg)`
+    :code:`((alg)==PSA_ALG_MD2 ? 64 : (alg)==PSA_ALG_MD4 || (alg)==PSA_ALG_MD5 ? 16 : (alg)==PSA_ALG_RIPEMD160 || (alg)==PSA_ALG_SHA_1 ? 20 : (alg)==PSA_ALG_SHA_224 || (alg)==PSA_ALG_SHA_256 ? 32 : (alg)==PSA_ALG_SHA_512 || (alg)==PSA_ALG_SHA_384 || (alg)==PSA_ALG_SHA_512_256 ? 64 : 0)`
+
+    .. Could simplify a little if allowed to return 64 for every alg value that is not MD4/MD5/RIPEMD160/SHA1/SHA223/SHA256
+
+:code:`PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH(alg)`
+    :code:`((alg)==PSA_ALG_MD2 ? 1 : (alg)==PSA_ALG_MD4 || (alg)==PSA_ALG_MD5 || (alg)==PSA_ALG_RIPEMD160 || (alg)==PSA_ALG_SHA_1 || (alg)==PSA_ALG_SHA_224 || (alg)==PSA_ALG_SHA_256 ? 8 : (alg)==PSA_ALG_SHA_512 || (alg)==PSA_ALG_SHA_384 || (alg)==PSA_ALG_SHA_512_256 ? 16 : 0)`
+
+    .. Could simplify if allowed to return 8 for every alg value that is not MD2 or SHA512/SHA384/SHA512-256
+
+:code:`PSA_HASH_SUSPEND_OUTPUT_SIZE(alg)`
+    :code:`(PSA_HASH_SUSPEND_ALGORITHM_FIELD_LENGTH + PSA_HASH_SUSPEND_INPUT_LENGTH_FIELD_LENGTH(alg) + PSA_HASH_SUSPEND_HASH_STATE_FIELD_LENGTH(alg) + PSA_HASH_BLOCK_LENGTH(alg) - 1)`
diff --git a/docs/html/_sources/index.rst.txt b/docs/html/_sources/index.rst.txt
new file mode 100644
index 0000000..375ee65
--- /dev/null
+++ b/docs/html/_sources/index.rst.txt
@@ -0,0 +1,36 @@
+==============================
+PSA Cryptography API |version|
+==============================
+
+.. toctree::
+   :maxdepth: 3
+
+   overview/intro
+   overview/goals
+   overview/functionality
+   overview/sample-arch
+   overview/conventions
+   overview/implementation
+   overview/usage
+   api/library/index
+   api/keys/index
+   api/ops/index
+
+.. only:: html
+
+    .. toctree::
+
+        appendix/example_header
+        appendix/specdef_values
+        appendix/history
+
+
+.. raw:: html
+
+   <h2 id="indices">Indices</h2>
+
+   <ul>
+     <li><a class="reference internal" href="genindex.html">General index</a></li>
+     <li><a class="reference internal" href="psa_c-identifiers.html">Index of identifiers</a></li>
+     <li><a class="reference internal" href="search.html">Search</a></li>
+   </ul>
diff --git a/docs/html/_sources/overview/conventions.rst.txt b/docs/html/_sources/overview/conventions.rst.txt
new file mode 100644
index 0000000..8baf991
--- /dev/null
+++ b/docs/html/_sources/overview/conventions.rst.txt
@@ -0,0 +1,281 @@
+Library conventions
+-------------------
+
+Error handling
+~~~~~~~~~~~~~~
+
+Return status
+^^^^^^^^^^^^^
+
+Almost all functions return a status indication of type `psa_status_t`. This
+is an enumeration of integer values, with ``0`` (`PSA_SUCCESS`) indicating
+successful operation and other values indicating errors. The exceptions are
+functions which only access objects that are intended to be implemented as
+simple data structures. Such functions cannot fail and either return
+``void`` or a data value.
+
+Unless specified otherwise, if multiple error conditions apply, an
+implementation is free to return any of the applicable error codes. The choice
+of error code is considered an implementation quality issue. Different
+implementations can make different choices, for example to favor code size over
+ease of debugging or vice versa.
+
+If the behavior is undefined, for example, if a function receives an invalid
+pointer as a parameter, this specification makes no guarantee that the function
+will return an error. Implementations are encouraged to return an error or halt
+the application in a manner that is appropriate for the platform if the
+undefined behavior condition can be detected. However, application developers need to be aware that undefined behavior conditions cannot be detected in general.
+
+Behavior on error
+^^^^^^^^^^^^^^^^^
+
+All function calls must be implemented atomically:
+
+-  When a function returns a type other than `psa_status_t`, the requested
+   action has been carried out.
+-  When a function returns the status `PSA_SUCCESS`, the requested action has
+   been carried out.
+-  When a function returns another status of type `psa_status_t`, no action
+   has been carried out. The content of the output parameters is undefined, but
+   otherwise the state of the system has not changed, except as described below.
+
+In general, functions that modify the system state, for example, creating or
+destroying a key, must leave the system state unchanged if they return an error
+code. There are specific conditions that can result in different behavior:
+
+-  The status `PSA_ERROR_BAD_STATE` indicates that a parameter was not in a
+   valid state for the requested action. This parameter might have been modified
+   by the call and is now in an undefined state. The only valid action on an
+   object in an undefined state is to abort it with the appropriate
+   ``psa_abort_xxx()`` function.
+-  The status `PSA_ERROR_INSUFFICIENT_DATA` indicates that a key
+   derivation object has reached its maximum capacity. The key derivation
+   operation might have been modified by the call. Any further attempt to obtain
+   output from the key derivation operation will return
+   `PSA_ERROR_INSUFFICIENT_DATA`.
+-  The status `PSA_ERROR_COMMUNICATION_FAILURE` indicates that the
+   communication between the application and the cryptoprocessor has broken
+   down. In this case, the cryptoprocessor must either finish the requested
+   action successfully, or interrupt the action and roll back the system to its
+   original state. Because it is often impossible to report the outcome to the
+   application after a communication failure, this specification does not
+   provide a way for the application to determine whether the action was
+   successful.
+-  The statuses `PSA_ERROR_STORAGE_FAILURE`, `PSA_ERROR_DATA_CORRUPT`, `PSA_ERROR_HARDWARE_FAILURE`
+   and `PSA_ERROR_CORRUPTION_DETECTED` might indicate data corruption in the
+   system state. When a function returns one of these statuses, the system state
+   might have changed from its previous state before the function call, even
+   though the function call failed.
+-  Some system states cannot be rolled back, for example, the internal state of
+   the random number generator or the content of access logs.
+
+Unless otherwise documented, the content of output parameters is not defined
+when a function returns a status other than `PSA_SUCCESS`. It is recommended
+that implementations set output parameters to safe defaults to avoid leaking
+confidential data and limit risk, in case an application does not properly
+handle all errors.
+
+Parameter conventions
+~~~~~~~~~~~~~~~~~~~~~
+
+Pointer conventions
+^^^^^^^^^^^^^^^^^^^
+
+Unless explicitly stated in the documentation of a function, all pointers must
+be valid pointers to an object of the specified type.
+
+A parameter is considered a **buffer** if it points to an array of bytes. A
+buffer parameter always has the type ``uint8_t *`` or ``const uint8_t *``, and
+always has an associated parameter indicating the size of the array. Note that a
+parameter of type ``void *`` is never considered a buffer.
+
+All parameters of pointer type must be valid non-null pointers, unless the
+pointer is to a buffer of length ``0`` or the function’s documentation
+explicitly describes the behavior when the pointer is null. Passing a null
+pointer as a function parameter in other cases is expected to abort the caller
+on implementations where this is the normal behavior for a null pointer
+dereference.
+
+Pointers to input parameters can be in read-only memory. Output parameters must
+be in writable memory. Output parameters that are not buffers must also be
+readable, and the implementation must be able to write to a non-buffer output
+parameter and read back the same value, as explained in the
+:title:`stability-of-parameters` section.
+
+Input buffer sizes
+^^^^^^^^^^^^^^^^^^
+
+For input buffers, the parameter convention is:
+
+``const uint8_t *foo``
+   Pointer to the first byte of the data. The pointer
+   can be invalid if the buffer size is ``0``.
+
+``size_t foo_length``
+   Size of the buffer in bytes.
+
+The interface never uses input-output buffers.
+
+Output buffer sizes
+^^^^^^^^^^^^^^^^^^^
+
+For output buffers, the parameter convention is:
+
+``uint8_t *foo``
+   Pointer to the first byte of the data. The pointer can be
+   invalid if the buffer size is ``0``.
+
+``size_t foo_size``
+   The size of the buffer in bytes.
+
+``size_t *foo_length``
+   On successful return, contains the length of the
+   output in bytes.
+
+The content of the data buffer and of ``*foo_length`` on errors is unspecified,
+unless explicitly mentioned in the function description. They might be unmodified
+or set to a safe default. On successful completion, the content of the buffer
+between the offsets ``*foo_length`` and ``foo_size`` is also unspecified.
+
+Functions return `PSA_ERROR_BUFFER_TOO_SMALL` if the buffer size is
+insufficient to carry out the requested operation. The interface defines macros
+to calculate a sufficient buffer size for each operation that has an output
+buffer. These macros return compile-time constants if their arguments are
+compile-time constants, so they are suitable for static or stack allocation.
+Refer to an individual function’s documentation for the associated output size
+macro.
+
+Some functions always return exactly as much data as the size of the output
+buffer. In this case, the parameter convention changes to:
+
+``uint8_t *foo``
+   Pointer to the first byte of the output. The pointer can be
+   invalid if the buffer size is ``0``.
+
+``size_t foo_length``
+   The number of bytes to return in ``foo`` if
+   successful.
+
+Overlap between parameters
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Output parameters that are not buffers must not overlap with any input buffer or
+with any other output parameter. Otherwise, the behavior is undefined.
+
+Output buffers can overlap with input buffers. In this event, the implementation
+must return the same result as if the buffers did not overlap. The
+implementation must behave as if it had copied all the inputs into temporary
+memory, as far as the result is concerned. However, it is possible that overlap
+between parameters will affect the performance of a function call. Overlap might
+also affect memory management security if the buffer is located in memory that
+the caller shares with another security context, as described in the
+:title:`stability-of-parameters` section.
+
+.. _stability-of-parameters:
+
+Stability of parameters
+^^^^^^^^^^^^^^^^^^^^^^^
+
+In some environments, it is possible for the content of a parameter to change
+while a function is executing. It might also be possible for the content of an
+output parameter to be read before the function terminates. This can happen if
+the application is multithreaded. In some implementations, memory can be shared
+between security contexts, for example, between tasks in a multitasking
+operating system, between a user land task and the kernel, or between the
+Non-secure world and the Secure world of a trusted execution environment.
+
+This section describes the assumptions that an implementation can make about
+function parameters, and the guarantees that the implementation must provide
+about how it accesses parameters.
+
+Parameters that are not buffers are assumed to be under the caller’s full
+control. In a shared memory environment, this means that the parameter must be
+in memory that is exclusively accessible by the application. In a multithreaded
+environment, this means that the parameter must not be modified during the
+execution, and the value of an output parameter is undetermined until the
+function returns. The implementation can read an input parameter that is not a
+buffer multiple times and expect to read the same data. The implementation can
+write to an output parameter that is not a buffer and expect to read back the
+value that it last wrote. The implementation has the same permissions on buffers
+that overlap with a buffer in the opposite direction.
+
+In an environment with multiple threads or with shared memory, the
+implementation carefully accesses non-overlapping buffer parameters in order to
+prevent any security risk resulting from the content of the buffer being
+modified or observed during the execution of the function. In an input buffer
+that does not overlap with an output buffer, the implementation reads each byte
+of the input once, at most. The implementation does not read from an output
+buffer that does not overlap with an input buffer. Additionally, the
+implementation does not write data to a non-overlapping output buffer if this
+data is potentially confidential and the implementation has not yet verified
+that outputting this data is authorized.
+
+Unless otherwise specified, the implementation must not keep a reference to any
+parameter once a function call has returned.
+
+Key types and algorithms
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Types of cryptographic keys and cryptographic algorithms are encoded separately.
+Each is encoded by using an integral type: `psa_key_type_t` and
+`psa_algorithm_t`, respectively.
+
+There is some overlap in the information conveyed by key types and algorithms.
+Both types contain enough information, so that the meaning of an algorithm type
+value does not depend on what type of key it is used with, and vice versa.
+However, the particular instance of an algorithm might depend on the key type. For
+example, the algorithm `PSA_ALG_GCM` can be instantiated as any AEAD algorithm
+using the GCM mode over a block cipher. The underlying block cipher is
+determined by the key type.
+
+Key types do not encode the key size. For example, AES-128, AES-192 and AES-256
+share a key type `PSA_KEY_TYPE_AES`.
+
+Structure of key and algorithm types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Both types use a partial bitmask structure, which allows the analysis and
+building of values from parts. However, the interface defines constants, so that
+applications do not need to depend on the encoding, and an implementation might
+only care about the encoding for code size optimization.
+
+The encodings follows a few conventions:
+
+-  The highest bit is a vendor flag. Current and future versions of this
+   specification will only define values where this bit is clear.
+   Implementations that wish to define additional implementation-specific values
+   must use values where this bit is set, to avoid conflicts with future
+   versions of this specification.
+-  The next few highest bits indicate the corresponding algorithm category:
+   hash, MAC, symmetric cipher, asymmetric encryption, and so on.
+-  The following bits identify a family of algorithms in a category-dependent
+   manner.
+-  In some categories and algorithm families, the lowest-order bits indicate a
+   variant in a systematic way. For example, algorithm families that are
+   parametrized around a hash function encode the hash in the 8 lowest bits.
+
+.. _concurrency:
+
+Concurrent calls
+~~~~~~~~~~~~~~~~
+
+In some environments, an application can make calls to the PSA crypto API in
+separate threads. In such an environment, concurrent calls are performed
+correctly, as if the calls were executed in sequence, provided that they obey
+the following constraints:
+
+-  There is no overlap between an output parameter of one call and an input or
+   output parameter of another call. Overlap between input parameters is
+   permitted.
+-  If a call destroys a key, then no other call must destroy or use that key.
+   *Using*, in this context, includes all functions of multi-part operations
+   which have used the key as an input in a previous function.
+-  Concurrent calls that use the same key are permitted.
+-  Concurrent calls must not use the same operation object.
+
+If any of these constraints are violated, the behavior is undefined.
+
+If the application modifies an input parameter while a function call is in
+progress, the behavior is undefined.
+
+Individual implementations can provide additional guarantees.
diff --git a/docs/html/_sources/overview/functionality.rst.txt b/docs/html/_sources/overview/functionality.rst.txt
new file mode 100644
index 0000000..004f8bc
--- /dev/null
+++ b/docs/html/_sources/overview/functionality.rst.txt
@@ -0,0 +1,647 @@
+.. _functionality-overview:
+
+Functionality overview
+----------------------
+
+This section provides a high-level overview of the functionality provided by the
+interface defined in this specification. Refer to the `API definition
+<api-reference>` for a detailed description.
+
+`future` describes features that might be included in future versions of this
+specification.
+
+Due to the modularity of the interface, almost every part of the library is
+optional. The only mandatory function is `psa_crypto_init()`.
+
+Library management
+~~~~~~~~~~~~~~~~~~
+
+Applications must call `psa_crypto_init()` to initialize the library before
+using any other function.
+
+Key management
+~~~~~~~~~~~~~~
+
+Applications always access keys indirectly via an identifier, and can perform
+operations using a key without accessing the key material. This allows keys to
+be *non-extractable*, where an application can use a key but is not permitted to
+obtain the key material. Non-extractable keys are bound to the device, can be
+rate-limited and can have their usage restricted by policies.
+
+Each key has a set of attributes that describe the key and the policy for using
+the key. A `psa_key_attributes_t` object contains all of the attributes, which
+is used when creating a key and when querying key attributes.
+
+Each key has a *lifetime* that determines when the key material is destroyed.
+There are two types of lifetimes: `volatile <volatile-keys>` and
+`persistent <persistent-keys>`.
+
+.. _volatile-keys:
+
+Volatile keys
+^^^^^^^^^^^^^
+
+A *volatile* key exists until it explicitly destroyed with `psa_destroy_key()`
+or until the application terminates, which conceptually destroys all of its
+volatile keys.
+
+Conceptually, a volatile key is stored in RAM. Volatile keys have the
+lifetime `PSA_KEY_LIFETIME_VOLATILE`.
+
+To create a volatile key:
+
+1. Populate a `psa_key_attributes_t` object with the required type, size, policy
+   and other key attributes.
+2. Create the key with `psa_import_key()`, `psa_generate_key()`,
+   `psa_key_derivation_output_key()` or `psa_copy_key()`. If successful, these
+   functions output a transient `key identifier <key-ids>`.
+
+To destroy a volatile key, call `psa_destroy_key()` with the key identifier.
+
+.. _persistent-keys:
+
+Persistent keys
+^^^^^^^^^^^^^^^
+
+A *persistent* key exists until it explicitly destroyed with `psa_destroy_key()`
+or until it is wiped by the reset or destruction of the device.
+
+Each persistent key has a permanent key identifier, which acts as a name for the key.
+Within an application, the key identifier corresponds to a single key. The
+application specifies the key identifier when the key is created and when
+using the key.
+
+Persistent keys can be stored in different storage areas; this is indicated
+through different lifetime values. This specification defines a single lifetime
+value `PSA_KEY_LIFETIME_PERSISTENT` which corresponds to a default storage
+area. Implementations can define alternative lifetime values corresponding to
+different storage areas with different retention policies, or to secure elements
+with different security characteristics.
+
+To create a persistent key:
+
+1. Populate a `psa_key_attributes_t` object with the key’s type, size, policy
+   and other attributes.
+2. In the attributes object, set the desired lifetime and persistent identifier
+   for the key.
+3. Create the key with one of the *key creation functions*:
+
+   * `psa_import_key()`
+   * `psa_generate_key()`
+   * `psa_key_derivation_output_key()`
+   * `psa_copy_key()`
+
+   If successful, these functions output the `key identifier <key-ids>`
+   that was specified by the application in step 2.
+
+To access an existing persistent key: use the key identifier in any API that
+requires a key.
+
+To remove cached copies of key material for persistent keys created with the
+`PSA_KEY_USAGE_CACHE` policy: call `psa_purge_key()` with the key identifier.
+
+To destroy a persistent key: call `psa_destroy_key()` with the key identifier.
+Destroying a persistent key permanently removes it from memory and storage.
+
+The key lifetime and identifier are set when the key is created and cannot be
+changed without destroying the key first. If the original key permits copying,
+then the application can specify a different lifetime for the copy of the key.
+
+.. _key-ids:
+
+Key identifiers
+^^^^^^^^^^^^^^^
+
+Key identifiers are integral values that act as permanent names for persistent
+keys, or as transient references to volatile keys. Key identifiers use the
+`psa_key_id_t` type, and the range of identifier values is divided as follows:
+
+:code:`PSA_KEY_ID_NULL = 0`
+    Reserved as an invalid key identifier.
+:code:`PSA_KEY_ID_USER_MIN - PSA_KEY_ID_USER_MAX`
+    Applications can freely choose persistent key identifiers in this range.
+:code:`PSA_KEY_ID_VENDOR_MIN - PSA_KEY_ID_VENDOR_MAX`
+    Implementations can define additional persistent key identifiers in this
+    range, and must allocate any volatile key identifiers from this range.
+
+Key identifiers outside these ranges are reserved for future use.
+
+Key identifiers are output from a successful call to one of
+the key creation functions. For persistent keys, this is the same identifier
+as the one specified in the key attributes used to create the key.
+The key identifier remains valid until it is invalidated by passing it to
+`psa_destroy_key()`. A volatile key identifier must not be used after it has been
+invalidated.
+
+Valid key identifiers must have distinct values within the same application. If
+the implementation provides `caller isolation <isolation>`, then key
+identifiers are local to each application. That is, the same key identifier in two
+applications corresponds to two different keys.
+
+If an invalid key identifier is provided as a parameter in any function, the
+function will return `PSA_ERROR_INVALID_HANDLE`; except for the special case of
+calling :code:`psa_destroy_key(PSA_KEY_ID_NULL)`, which has no effect and always
+returns `PSA_SUCCESS`.
+
+There must be a matching call to `psa_destroy_key()` for each successful call
+to a create a volatile key.
+
+A call to `psa_destroy_key()` destroys the key material, and will cause any active
+operations that are using the key to fail. Therefore an application must not
+destroy a key while an operation using that key is in progress, unless the
+application is prepared to handle a failure of the operation.
+
+Recommendations of minimum standards for key management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most implementations provide the following functions:
+
+*  `psa_import_key()`. The exceptions are implementations that only give access
+   to a key or keys that are provisioned by proprietary means, and do not allow
+   the main application to use its own cryptographic material.
+
+*  `psa_get_key_attributes()` and the ``psa_get_key_xxx()`` accessor functions.
+   They are easy to implement, and it is difficult to write applications and to
+   diagnose issues without being able to check the metadata.
+
+*  `psa_export_public_key()`. This function is usually provided if the
+   implementation supports any asymmetric algorithm, since public-key
+   cryptography often requires the delivery of a public key that is associated
+   with a protected private key.
+
+*  `psa_export_key()`. However, highly constrained implementations that are
+   designed to work only with short-term keys, or only with long-term
+   non-extractable keys, do not need to provide this function.
+
+Usage policies
+~~~~~~~~~~~~~~
+
+All keys have an associated policy that regulates which operations are permitted
+on the key. Each key policy is a set of usage flags and a specific algorithm
+that is permitted with the key. The policy is part of the key attributes that
+are managed by a `psa_key_attributes_t` object.
+
+The usage flags are encoded in a bitmask, which has the type
+`psa_key_usage_t`. Four kinds of usage flag can be specified:
+
+*  The extractable flag `PSA_KEY_USAGE_EXPORT` determines whether the key
+   material can be extracted.
+*  The copyable flag `PSA_KEY_USAGE_COPY` determines whether the key material
+   can be copied into a new key, which can have a different lifetime or a more
+   restrictive policy.
+*  The cacheable flag `PSA_KEY_USAGE_CACHE` determines whether the
+   implementation is permitted to retain non-essential copies of the
+   key material in RAM. This policy only applies to persistent keys. See also
+   :title:`key-material`.
+*  The other usage flags, for example, `PSA_KEY_USAGE_ENCRYPT` and `PSA_KEY_USAGE_SIGN_MESSAGE`,
+   determine whether the corresponding operation is permitted on the key.
+
+In addition to the usage bitmask, a policy specifies which algorithm is
+permitted with the key. This specification only defines policies that restrict
+keys to a single algorithm, which is consistent with both common practice and
+security good practice.
+
+A highly constrained implementation might not be able to support all the policies
+that can be expressed through this interface. If an implementation cannot create
+a key with the required policy, it must return an appropriate error code when
+the key is created.
+
+Symmetric cryptography
+~~~~~~~~~~~~~~~~~~~~~~
+
+This specification defines interfaces for the following types of symmetric
+cryptographic operation:
+
+*  Message digests, commonly known as hash functions.
+*  Message authentication codes (MAC).
+*  Symmetric ciphers.
+*  Authenticated encryption with associated data (AEAD).
+
+For each type of symmetric cryptographic operation, the API includes:
+
+*  A pair of *single-part* functions. For example, compute and verify, or
+   encrypt and decrypt.
+*  A series of functions that permit *multi-part operations*.
+
+Single-part Functions
+^^^^^^^^^^^^^^^^^^^^^
+
+Single-part functions are APIs that implement the cryptographic operation in a
+single function call. This is the easiest API to use when all of the inputs and
+outputs fit into the application memory.
+
+Some use cases involve messages that are too large to be assembled in memory, or
+require non-default configuration of the algorithm. These use cases require the
+use of a :title:`multi-part operation <multi-part-operations>`.
+
+.. _multi-part-operations:
+
+Multi-part operations
+^^^^^^^^^^^^^^^^^^^^^
+
+Multi-part operations are APIs which split a single cryptographic operation into
+a sequence of separate steps. This enables fine control over the configuration
+of the cryptographic operation, and allows the message data to be processed in
+fragments instead of all at once. For example, the following situations require
+the use of a multi-part operation:
+
+-  Processing messages that cannot be assembled in memory.
+-  Using a deterministic IV for unauthenticated encryption.
+-  Providing the IV separately for unauthenticated encryption or decryption.
+-  Separating the AEAD authentication tag from the cipher text.
+
+Each multi-part operation defines a specific object type to maintain the state
+of the operation. These types are implementation-defined. All multi-part
+operations follow the same pattern of use:
+
+1.  **Allocate:** Allocate memory for an operation object of the appropriate
+    type. The application can use any allocation strategy: stack, heap, static, etc.
+
+2.  **Initialize:** Initialize or assign the operation object by one of the
+    following methods:
+
+       -  Set it to logical zero. This is automatic for static and global
+          variables. Explicit initialization must use the associated
+          ``PSA_xxx_INIT`` macro as the type is implementation-defined.
+       -  Set it to all-bits zero. This is automatic if the object was
+          allocated with ``calloc()``.
+       -  Assign the value of the associated macro ``PSA_xxx_INIT``.
+       -  Assign the result of calling the associated function
+          ``psa_xxx_init()``.
+
+    The resulting object is now *inactive*.
+
+    It is an error to initialize an operation object that is in *active* or
+    *error* states. This can leak memory or other resources.
+
+3.  **Setup:** Start a new multi-part operation on an *inactive* operation
+    object. Each operation object will define one or more setup functions to
+    start a specific operation.
+
+    On success, a setup function will put an operation object into an *active*
+    state. On failure, the operation object will remain *inactive*.
+
+4.  **Update:** Update an *active* operation object. The update function can
+    provide additional parameters, supply data for processing or generate
+    outputs.
+
+    On success, the operation object remains *active*. On failure, the
+    operation object will enter an *error* state.
+
+5.  **Finish:** To end the operation, call the applicable finishing function.
+    This will take any final inputs, produce any final outputs, and then
+    release any resources associated with the operation.
+
+    On success, the operation object returns to the *inactive* state. On
+    failure, the operation object will enter an *error* state.
+
+An operation can be aborted at any stage during its use by calling the
+associated ``psa_xxx_abort()`` function. This will release any resources
+associated with the operation and return the operation object to the *inactive*
+state.
+
+Any error that occurs to an operation while it is in an *active* state will
+result in the operation entering an *error* state. The application must call the
+associated ``psa_xxx_abort()`` function to release the operation resources and
+return the object to the *inactive* state.
+
+Once an operation object is returned to the *inactive* state, it can be reused
+by calling one of the applicable setup functions again.
+
+If a multi-part operation object is not initialized before use, the behavior is
+undefined.
+
+If a multi-part operation function determines that the operation object is not in
+any valid state, it can return `PSA_ERROR_CORRUPTION_DETECTED`.
+
+If a multi-part operation function is called with an operation object in the
+wrong state, the function will return `PSA_ERROR_BAD_STATE` and the operation
+object will enter the *error* state.
+
+It is safe to move a multi-part operation object to a different memory location,
+for example, using a bitwise copy, and then to use the object in the new
+location. For example, an application can allocate an operation object on the
+stack and return it, or the operation object can be allocated within memory
+managed by a garbage collector. However, this does not permit the following
+behaviors:
+
+-  Moving the object while a function is being called on the object. This is
+   not safe. See also `concurrency`.
+-  Working with both the original and the copied operation objects. This
+   requires cloning the operation, which is only available for hash operations
+   using `psa_hash_clone()`.
+
+Each type of multi-part operation can have multiple *active* states.
+Documentation for the specific operation describes the configuration and update
+functions, and any requirements about their usage and ordering.
+
+Message digests (Hashes)
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The single-part hash functions are:
+
+-   `psa_hash_compute()` to calculate the hash of a message.
+-   `psa_hash_compare()` to compare the hash of a message with a reference value.
+
+The `psa_hash_operation_t` `multi-part operation <multi-part-operations>`
+allows messages to be processed in fragments:
+
+1. Initialize the `psa_hash_operation_t` object to zero, or by assigning the
+   value of the associated macro `PSA_HASH_OPERATION_INIT`.
+2. Call `psa_hash_setup()` to specify the required hash algorithm, call
+   `psa_hash_clone()` to duplicate the state of *active* `psa_hash_operation_t`
+   object, or call `psa_hash_resume()` to restart a hash operation with the
+   output from a previously suspended hash operation.
+3. Call the `psa_hash_update()` function on successive chunks of the message.
+4. At the end of the message, call the required finishing function:
+
+   -  To suspend the hash operation and extract a hash suspend state,
+      call `psa_hash_suspend()`. The output state can subsequently be used
+      to resume the hash operation.
+   -  To calculate the digest of a message, call `psa_hash_finish()`.
+   -  To verify the digest of a message against a reference value, call
+      `psa_hash_verify()`.
+
+To abort the operation or recover from an error, call `psa_hash_abort()`.
+
+Message authentication codes (MACs)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The single-part MAC functions are:
+
+-  `psa_mac_compute()` to calculate the MAC of a message.
+-  `psa_mac_verify()` to compare the MAC of a message with a reference value.
+
+The `psa_mac_operation_t` `multi-part operation <multi-part-operations>`
+allows messages to be processed in fragments:
+
+1. Initialize the `psa_mac_operation_t` object to zero, or by assigning the
+   value of the associated macro `PSA_MAC_OPERATION_INIT`.
+2. Call `psa_mac_sign_setup()` or `psa_mac_verify_setup()` to specify the
+   algorithm and key.
+3. Call the `psa_mac_update()` function on successive chunks of the message.
+4. At the end of the message, call the required finishing function:
+
+   -  To calculate the MAC of the message, call `psa_mac_sign_finish()`.
+   -  To verify the MAC of the message against a reference value, call
+      `psa_mac_verify_finish()`.
+
+To abort the operation or recover from an error, call `psa_mac_abort()`.
+
+Encryption and decryption
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. note::
+
+    The unauthenticated cipher API is provided to implement legacy protocols and
+    for use cases where the data integrity and authenticity is guaranteed by
+    non-cryptographic means. It is recommended that newer protocols use
+    :title:`func-aead`.
+
+The single-part functions for encrypting or decrypting a message using an
+unauthenticated symmetric cipher are:
+
+-  `psa_cipher_encrypt()` to encrypt a message using an unauthenticated symmetric
+   cipher. The encryption function generates a random IV. Use the multi-part API
+   to provide a deterministic IV: this is not secure in general, but
+   can be secure in some conditions that depend on the algorithm.
+-  `psa_cipher_decrypt()` to decrypt a message using an unauthenticated symmetric
+   cipher.
+
+The `psa_cipher_operation_t` `multi-part operation <multi-part-operations>`
+permits alternative initialization parameters and allows messages to be
+processed in fragments:
+
+1. Initialize the `psa_cipher_operation_t` object to zero, or by assigning the
+   value of the associated macro `PSA_CIPHER_OPERATION_INIT`.
+2. Call `psa_cipher_encrypt_setup()` or `psa_cipher_decrypt_setup()` to specify the
+   algorithm and key.
+3. Provide additional parameters:
+
+   -  When encrypting data, generate or set an initialization vector (IV),
+      nonce, or similar initial value such as an initial counter value. To
+      generate a random IV, which is recommended in most protocols, call
+      `psa_cipher_generate_iv()`. To set the IV, call `psa_cipher_set_iv()`.
+   -  When decrypting, set the IV or nonce. To set the IV, call
+      `psa_cipher_set_iv()`.
+4. Call the `psa_cipher_update()` function on successive chunks of the message.
+5. Call `psa_cipher_finish()` to complete the operation and return any final
+   output.
+
+To abort the operation or recover from an error, call `psa_cipher_abort()`.
+
+.. _func-aead:
+
+Authenticated encryption (AEAD)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The single-part AEAD functions are:
+
+-  `psa_aead_encrypt()` to encrypt a message using an authenticated symmetric
+   cipher.
+-  `psa_aead_decrypt()` to decrypt a message using an authenticated symmetric
+   cipher.
+
+These functions follow the interface recommended by :RFC:`5116`.
+
+The encryption function requires a nonce to be provided. To generate a random
+nonce, either call `psa_generate_random()` or use the AEAD multi-part API.
+
+The `psa_aead_operation_t` `multi-part operation <multi-part-operations>`
+permits alternative initialization parameters and allows messages to be
+processed in fragments:
+
+1. Initialize the `psa_aead_operation_t` object to zero, or by assigning the
+   value of the associated macro `PSA_AEAD_OPERATION_INIT`.
+2. Call `psa_aead_encrypt_setup()` or `psa_aead_decrypt_setup()` to specify the
+   algorithm and key.
+3. Provide additional parameters:
+
+   -  If the algorithm requires it, call `psa_aead_set_lengths()` to specify the
+      length of the non-encrypted and encrypted inputs to the operation.
+   -  When encrypting, call either `psa_aead_generate_nonce()` or
+      `psa_aead_set_nonce()` to generate or set the nonce.
+   -  When decrypting, call `psa_aead_set_nonce()` to set the nonce.
+4. Call `psa_aead_update_ad()` zero or more times with fragments of the
+   non-encrypted additional data.
+5. Call `psa_aead_update()` zero or more times with fragments of the plaintext
+   or ciphertext to encrypt or decrypt.
+6. At the end of the message, call the required finishing function:
+
+   -  To complete an encryption operation, call `psa_aead_finish()` to compute
+      and return authentication tag.
+   -  To complete a decryption operation, call `psa_aead_verify()` to
+      compute the authentication tag and verify it against a reference value.
+
+To abort the operation or recover from an error, call `psa_aead_abort()`.
+
+Having a multi-part interface to authenticated encryption raises specific issues.
+
+Multi-part authenticated decryption produces partial results that are not
+authenticated. Applications must not use or expose partial results of
+authenticated decryption until `psa_aead_verify()` has returned a success
+status and must destroy all partial results without revealing them if
+`psa_aead_verify()` returns a failure status. Revealing partial results, either directly or indirectly through the application’s behavior, can compromise the
+confidentiality of all inputs that are encrypted with the same key.
+
+For encryption, some common algorithms cannot be processed in a streaming
+fashion. For SIV mode, the whole plaintext must be known before the encryption
+can start; the multi-part AEAD API is not meant to be usable with SIV mode. For
+CCM mode, the length of the plaintext must be known before the encryption can
+start; the application can call the function `psa_aead_set_lengths()` to provide
+these lengths before providing input.
+
+.. _key-derivation:
+
+Key derivation
+^^^^^^^^^^^^^^
+
+A key derivation encodes a deterministic method to generate a finite stream of
+bytes. This data stream is computed by the cryptoprocessor and extracted in
+chunks. If two key derivation operations are constructed with the same
+parameters, then they produce the same output.
+
+A key derivation consists of two phases:
+
+1. Input collection. This is sometimes known as *extraction*: the operation
+   “extracts” information from the inputs to generate a pseudorandom
+   intermediate secret value.
+2. Output generation. This is sometimes known as *expansion*: the operation
+   “expands” the intermediate secret value to the desired output length.
+
+The specification defines a `multi-part operation <multi-part-operations>`
+API for key derivation that allows for multiple key and non-key outputs to be
+extracted from a single derivation operation object.
+
+In an implementation with `isolation <isolation>`, the intermediate
+state of the key derivation is not visible to the caller, and if an output of
+the derivation is a non-exportable key, then this key cannot be recovered
+outside the isolation boundary.
+
+Applications use the `psa_key_derivation_operation_t` type to create key
+derivation operations. The operation object is used as follows:
+
+1. Initialize a `psa_key_derivation_operation_t` object to zero or to
+   `PSA_KEY_DERIVATION_OPERATION_INIT`.
+2. Call `psa_key_derivation_setup()` to select a key derivation algorithm.
+3. Call the functions `psa_key_derivation_input_bytes()` and
+   `psa_key_derivation_input_key()`, or `psa_key_derivation_key_agreement()` to
+   provide the inputs to the key derivation algorithm. Many key derivation
+   algorithms take multiple inputs; the ``step`` parameter to these functions
+   indicates which input is being provided. The documentation for each key
+   derivation algorithm describes the expected inputs for that algorithm and
+   in what order to pass them.
+4. Optionally, call `psa_key_derivation_set_capacity()` to set a limit on the
+   amount of data that can be output from the key derivation operation.
+5. Call `psa_key_derivation_output_key()` to create a derived key, or
+   `psa_key_derivation_output_bytes()` to export the derived data. These
+   functions can be called multiple times to read successive output from the key
+   derivation, until the stream is exhausted when its capacity has been reached.
+6. Key derivation does not finish in the same way as other multi-part
+   operations. Call `psa_key_derivation_abort()` to release the key derivation
+   operation memory when the object is no longer required.
+
+To recover from an error, call `psa_key_derivation_abort()` to release the key
+derivation operation memory.
+
+A key derivation operation cannot be rewound. Once a part of the stream has been
+output, it cannot be output again. This ensures that the same part of the output
+will not be used for different purposes.
+
+Example of the symmetric cryptography API
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Here is an example of a use case where a master key is used to generate both a
+message encryption key and an IV for the encryption, and the derived key and IV
+are then used to encrypt a message.
+
+1. Derive the message encryption material from the master key.
+
+   1. Initialize a `psa_key_derivation_operation_t` object to zero or to
+      `PSA_KEY_DERIVATION_OPERATION_INIT`.
+   2. Call `psa_key_derivation_setup()` with `PSA_ALG_HKDF` as the algorithm.
+   3. Call `psa_key_derivation_input_key()` with the step
+      `PSA_KEY_DERIVATION_INPUT_SECRET` and the master key.
+   4. Call `psa_key_derivation_input_bytes()` with the step
+      `PSA_KEY_DERIVATION_INPUT_INFO` and a public value that uniquely
+      identifies the message.
+   5. Populate a `psa_key_attributes_t` object with the derived message
+      encryption key’s attributes.
+   6. Call `psa_key_derivation_output_key()` to create the derived message key.
+   7. Call `psa_key_derivation_output_bytes()` to generate the derived IV.
+   8. Call `psa_key_derivation_abort()` to release the key derivation operation
+      memory.
+
+2. Encrypt the message with the derived material.
+
+   1. Initialize a `psa_cipher_operation_t` object to zero or to
+      `PSA_CIPHER_OPERATION_INIT`.
+   2. Call `psa_cipher_encrypt_setup()` with the derived message encryption key.
+   3. Call `psa_cipher_set_iv()` using the derived IV retrieved above.
+   4. Call `psa_cipher_update()` one or more times to encrypt the message.
+   5. Call `psa_cipher_finish()` at the end of the message.
+
+3. Call `psa_destroy_key()` to clear the generated key.
+
+Asymmetric cryptography
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This specification defines functions for asymmetric cryptography, including
+asymmetric encryption, asymmetric signature, and two-way key agreement.
+
+Asymmetric encryption
+^^^^^^^^^^^^^^^^^^^^^
+
+Asymmetric encryption is provided through the functions
+`psa_asymmetric_encrypt()` and `psa_asymmetric_decrypt()`.
+
+Hash-and-sign
+^^^^^^^^^^^^^
+
+The signature and verification functions `psa_sign_message()` and
+`psa_verify_message()` take a message as one of their inputs and perform a
+hash-and-sign algorithm.
+
+The functions `psa_sign_hash()` and `psa_verify_hash()` take a message hash as
+one of their inputs. This is useful for signing pre-computed hashes, or for
+implementing hash-and-sign using a :ref:`multi-part hash operation <hash-mp>`
+before signing the resulting hash. To determine which
+hash algorithm to use, call the macro `PSA_ALG_GET_HASH()` on the
+corresponding signature algorithm.
+
+Some hash-and-sign algorithms add padding to the message hash before completing
+the signing operation. The format of the padding that is used depends on the
+algorithm used to construct the signature.
+
+Key agreement
+^^^^^^^^^^^^^
+
+This specification defines two functions for a Diffie-Hellman-style key
+agreement where each party combines its own private key with the peer’s public
+key.
+
+The recommended approach is to use a `key derivation
+operation <key-derivation>` with the `psa_key_derivation_key_agreement()`
+input function, which calculates a shared secret for the key derivation
+function.
+
+Where an application needs direct access to the shared secret, it can call
+`psa_raw_key_agreement()` instead. Note that in general the shared secret is not
+directly suitable for use as a key because it is biased.
+
+Randomness and key generation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We strongly recommended that implementations include a random generator,
+consisting of a cryptographically secure pseudo-random generator (CSPRNG), which
+is adequately seeded with a cryptographic-quality hardware entropy source,
+commonly referred to as a true random number generator (TRNG). Constrained
+implementations can omit the random generation functionality if they do not
+implement any algorithm that requires randomness internally, and they do not
+provide a key generation functionality. For example, a special-purpose component
+for signature verification can omit this.
+
+It is recommended that applications use `psa_generate_key()`,
+`psa_cipher_generate_iv()` or `psa_aead_generate_nonce()` to generate
+suitably-formatted random data, as applicable. In addition, the API includes a
+function `psa_generate_random()` to generate and extract arbitrary random data.
diff --git a/docs/html/_sources/overview/goals.rst.txt b/docs/html/_sources/overview/goals.rst.txt
new file mode 100644
index 0000000..48a2f75
--- /dev/null
+++ b/docs/html/_sources/overview/goals.rst.txt
@@ -0,0 +1,194 @@
+.. _design-goals:
+
+Design goals
+------------
+
+Suitable for constrained devices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The interface is suitable for a vast range of devices: from special-purpose
+cryptographic processors that process data with a built-in key, to constrained
+devices running custom application code, such as microcontrollers, and
+multi-application devices, such as servers. Consequentially, the interface is
+scalable and modular.
+
+-  *Scalable*: devices only need to implement the functionality that they will
+   use.
+-  *Modular*: larger devices implement larger subsets of the same interface,
+   rather than different interfaces.
+
+In this interface, all operations on unbounded amounts of data
+allow *multi-part* processing, as long as the calculations on the data are
+performed in a streaming manner. This means that the application does not need
+to store the whole message in memory at one time. As a result, this
+specification is suitable for very constrained devices, including those where
+memory is very limited.
+
+Memory outside the keystore boundary is managed by the application. An
+implementation of the interface is not required to retain any state between
+function calls, apart from the content of the keystore and other data that must
+be kept inside the keystore security boundary.
+
+The interface does not expose the representation of keys and intermediate data,
+except when required for interchange. This allows each implementation to choose
+optimal data representations. Implementations with multiple components are also
+free to choose which memory area to use for internal data.
+
+A keystore interface
+~~~~~~~~~~~~~~~~~~~~
+
+The specification allows cryptographic operations to be performed on a key to
+which the application does not have direct access. Except where required for
+interchange, applications access all keys indirectly, by an identifier. The key
+material corresponding to that identifier can reside inside a security boundary
+that prevents it from being extracted, except as permitted by a policy that is
+defined when the key is created.
+
+.. _isolation:
+
+Optional isolation
+~~~~~~~~~~~~~~~~~~
+
+Implementations can isolate the cryptoprocessor from the calling application,
+and can further isolate multiple calling applications. The interface allows the
+implementation to be separated between a frontend and a backend. In an isolated
+implementation, the frontend is the part of the implementation that is located
+in the same isolation boundary as the application, which the application
+accesses by function calls. The backend is the part of the implementation that
+is located in a different environment, which is protected from the frontend.
+Various technologies can provide protection, for example:
+
+-  Process isolation in an operating system.
+-  Partition isolation, either with a virtual machine or a partition manager.
+-  Physical separation between devices.
+
+Communication between the frontend and backend is beyond the scope of this
+specification.
+
+In an isolated implementation, the backend can serve more than one
+implementation instance. In this case, a single backend communicates with
+multiple instances of the frontend. The backend must enforce **caller
+isolation**: it must ensure that assets of one frontend are not visible to any
+other frontend. The mechanism for identifying callers is beyond the scope of this
+specification. An implementation that provides caller isolation must document
+the identification mechanism. An implementation that provides isolation must
+document any implementation-specific extension of the API that enables frontend
+instances to share data in any form.
+
+In summary, there are three types of implementation:
+
+-  No isolation: there is no security boundary between the application and the
+   cryptoprocessor. For example, a statically or dynamically linked library is
+   an implementation with no isolation.
+-  Cryptoprocessor isolation: there is a security boundary between the
+   application and the cryptoprocessor, but the cryptoprocessor does not
+   communicate with other applications. For example, a cryptoprocessor chip that
+   is a companion to an application processor is an implementation with
+   cryptoprocessor isolation.
+-  Caller isolation: there are multiple application instances, with a security
+   boundary between the application instances among themselves, as well as
+   between the cryptoprocessor and the application instances. For example, a
+   cryptography service in a multiprocess environment is an implementation with
+   caller and cryptoprocessor isolation.
+
+Choice of algorithms
+~~~~~~~~~~~~~~~~~~~~
+
+The specification defines a low-level cryptographic interface, where the caller
+explicitly chooses which algorithm and which security parameters they use. This
+is necessary to implement protocols that are inescapable in various use cases.
+The design of the interface enables applications to implement widely-used
+protocols and data exchange formats, as well as custom ones.
+
+As a consequence, all cryptographic functionality operates according to the
+precise algorithm specified by the caller. However, this does not apply to
+device-internal functionality, which does not involve any form of
+interoperability, such as random number generation. The specification does not
+include generic higher-level interfaces, where the implementation chooses the
+best algorithm for a purpose. However, higher-level libraries can be built on
+top of the PSA Crypto API.
+
+Another consequence is that the specification permits the use of algorithms, key
+sizes and other parameters that, while known to be insecure, might be necessary to
+support legacy protocols or legacy data. Where major weaknesses are known, the
+algorithm descriptions give applicable warnings. However, the lack of a warning
+both does not and cannot indicate that an algorithm is secure in all circumstances.
+Application developers need to research the security of the protocols and
+algorithms that they plan to use to determine if these meet their requirements.
+
+The interface facilitates algorithm agility. As a consequence, cryptographic
+primitives are presented through generic functions with a parameter indicating
+the specific choice of algorithm. For example, there is a single function to
+calculate a message digest, which takes a parameter that identifies the specific
+hash algorithm.
+
+Ease of use
+~~~~~~~~~~~
+
+The interface is designed to be as user-friendly as possible, given the
+aforementioned constraints on suitability for various types of devices and on
+the freedom to choose algorithms.
+
+In particular, the code flows are designed to reduce the risk of dangerous
+misuse. The interface is designed in part to make it harder to misuse. Where
+possible, it is designed so that
+typical mistakes result in test failures, rather than subtle security issues.
+Implementations avoid leaking data when a function is called with invalid
+parameters, to the extent allowed by the C language and by implementation size
+constraints.
+
+Example use cases
+~~~~~~~~~~~~~~~~~
+
+This section lists some of the use cases that were considered during the design
+of this API. This list is not exhaustive, nor are all implementations required to
+support all use cases.
+
+Network Security (TLS)
+^^^^^^^^^^^^^^^^^^^^^^
+
+The API provides all of the cryptographic primitives needed to establish TLS
+connections.
+
+Secure Storage
+^^^^^^^^^^^^^^
+
+The API provides all primitives related to storage encryption, block or
+file-based, with master encryption keys stored inside a key store.
+
+Network Credentials
+^^^^^^^^^^^^^^^^^^^
+
+The API provides network credential management inside a key store, for example,
+for X.509-based authentication or pre-shared keys on enterprise networks.
+
+Device Pairing
+^^^^^^^^^^^^^^
+
+The API provides support for key agreement protocols that are often used for
+secure pairing of devices over wireless channels. For example, the pairing of an
+NFC token or a Bluetooth device might use key agreement protocols upon
+first use.
+
+Secure Boot
+^^^^^^^^^^^
+
+The API provides primitives for use during firmware integrity and authenticity
+validation, during a secure or trusted boot process.
+
+Attestation
+^^^^^^^^^^^
+
+The API provides primitives used in attestation activities. Attestation is the
+ability for a device to sign an array of bytes with a device private key and
+return the result to the caller. There are several use cases; ranging from attestation
+of the device state, to the ability to generate a key pair and prove that it has
+been generated inside a secure key store. The API provides access to the
+algorithms commonly used for attestation.
+
+Factory Provisioning
+^^^^^^^^^^^^^^^^^^^^
+
+Most IoT devices receive a unique identity during the factory provisioning
+process, or once they have been deployed to the field. This API provides the APIs necessary for
+populating a device with keys that represent that identity.
diff --git a/docs/html/_sources/overview/implementation.rst.txt b/docs/html/_sources/overview/implementation.rst.txt
new file mode 100644
index 0000000..b85ef16
--- /dev/null
+++ b/docs/html/_sources/overview/implementation.rst.txt
@@ -0,0 +1,290 @@
+.. _implementation-considerations:
+
+Implementation considerations
+-----------------------------
+
+Implementation-specific aspects of the interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Implementation profile
+^^^^^^^^^^^^^^^^^^^^^^
+
+Implementations can implement a subset of the API and a subset of the available
+algorithms. The implemented subset is known as the implementation’s profile. The
+documentation for each implementation must describe the profile that it
+implements. This specification’s companion documents also define a number of
+standard profiles.
+
+.. _implementation-defined-type:
+
+Implementation-specific types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This specification defines a number of implementation-specific types, which
+represent objects whose content depends on the implementation. These are defined
+as C ``typedef`` types in this specification, with a comment
+:code:`/* implementation-defined type */` in place of the underlying type
+definition. For some types the specification constrains the type, for example,
+by requiring that the type is a ``struct``, or that it is convertible to and
+from an unsigned integer. In the implementation's version of **psa/crypto.h**,
+these types need to be defined as complete C types so that objects of these
+types can be instantiated by application code.
+
+Applications that rely on the implementation specific definition of any of these
+types might not be portable to other implementations of this specification.
+
+.. _implementation-specific-macro:
+
+Implementation-specific macros
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some macro constants and function-like macros are precisely defined by this
+specification. The use of an exact definition is essential if the definition can
+appear in more than one header file within a compilation.
+
+Other macros that are defined by this specification have a macro body that is
+implementation-specific. The description of an implementation-specific macro can
+optionally specify each of the following requirements:
+
+* Input domains: the macro must be valid for arguments within the input domain.
+* A return type: the macro result must be compatible with this type.
+* Output range: the macro result must lie in the output range.
+* Computed value: A precise mapping of valid input to output values.
+
+Each implementation-specific macro is in one of following categories:
+
+.. _specification-defined-value:
+
+*Specification-defined value*
+
+    The result type and computed value of the macro expression is defined by
+    this specification, but the definition of the macro body is provided by the
+    implementation.
+
+    These macros are indicated in this specification using the comment
+    :code:`/* specification-defined value */`.
+
+    .. TODO!!
+        Change this text when we have provided pseudo-code implementations of
+        all the relevant macro expressions.
+
+    For function-like macros with specification-defined values:
+
+    * Example implementations are provided in an appendix to this specification.
+      See :title:`appendix-specdef-values`.
+
+    * The expected computation for valid and supported input arguments will be
+      defined as pseudo-code in a future version of this specification.
+
+.. _implementation-defined-value:
+
+*Implementation-defined value*
+
+    The value of the macro expression is implementation-defined.
+
+    For some macros, the computed value is derived from the specification of one
+    or more cryptographic algorithms. In these cases, the result must exactly
+    match the value in those external specifications.
+
+    These macros are indicated in this specification using the comment
+    :code:`/* implementation-defined value */`.
+
+Some of these macros compute a result based on an algorithm or key type.
+If an implementation defines vendor-specific algorithms or
+key types, then it must provide an implementation for such macros that takes all
+relevant algorithms and types into account. Conversely, an implementation that
+does not support a certain algorithm or key type can define such macros in a
+simpler way that does not take unsupported argument values into account.
+
+Some macros define the minimum sufficient output buffer size for certain
+functions. In some cases, an implementation is allowed to require a buffer size
+that is larger than the theoretical minimum. An implementation must define
+minimum-size macros in such a way that it guarantees that the buffer of the
+resulting size is sufficient for the output of the corresponding function. Refer
+to each macro’s documentation for the applicable requirements.
+
+Porting to a platform
+~~~~~~~~~~~~~~~~~~~~~
+
+Platform assumptions
+^^^^^^^^^^^^^^^^^^^^
+
+This specification is designed for a C99 platform. The interface is defined in
+terms of C macros, functions and objects.
+
+The specification assumes 8-bit bytes, and “byte” and “octet” are used
+synonymously.
+
+Platform-specific types
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The specification makes use of some types defined in C99. These types must be
+defined in the implementation version of **psa/crypto.h** or by a header
+included in this file. The following C99 types are used:
+
+``uint8_t``, ``uint16_t``, ``uint32_t``
+   Unsigned integer types with 8, 16 and 32 value bits respectively.
+   These types are defined by the C99 header **stdint.h**.
+
+Cryptographic hardware support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Implementations are encouraged to make use of hardware accelerators where
+available. A future version of this specification will define a function
+interface that calls drivers for hardware accelerators and external
+cryptographic hardware.
+
+Security requirements and recommendations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Error detection
+^^^^^^^^^^^^^^^
+
+Implementations that provide isolation between the caller and the cryptography
+processing environment must validate parameters to ensure that the cryptography
+processing environment is protected from attacks caused by passing invalid
+parameters.
+
+Even implementations that do not provide isolation are recommended to detect bad
+parameters and fail-safe where possible.
+
+Indirect object references
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Implementations can use different strategies for allocating key identifiers,
+and other types of indirect object reference.
+
+Implementations that provide isolation between the caller and the cryptography
+processing environment must consider the threats relating to abuse and misuse
+of key identifiers and other indirect resource references. For example,
+multi-part operations can be implemented as backend state to which the client
+only maintains an indirect reference in the application's multi-part operation
+object.
+
+An implementation that supports multiple callers must implement strict isolation
+of API resources between different callers. For example, a client must not be
+able to obtain a reference to another client's key by guessing the key
+identifier value. Isolation of key identifiers can be achieved in several ways.
+For example:
+
+-  There is a single identifier namespace for all clients, and the
+   implementation verifies that the client is the owner of the identifier when
+   looking up the key.
+-  Each client has an independent identifier namespace, and the implementation
+   uses a client specific identifier-to-key mapping when looking up the key.
+
+After a volatile key identifier is destroyed, it is recommended that the
+implementation does not immediately reuse the same identifier value for a
+different key. This reduces the risk of an attack that is able to exploit a key
+identifier reuse vulnerability within an application.
+
+.. _memory-cleanup:
+
+Memory cleanup
+^^^^^^^^^^^^^^
+
+Implementations must wipe all sensitive data from memory when it is no longer
+used. It is recommended that they wipe this sensitive data as soon as possible. All
+temporary data used during the execution of a function, such as stack buffers,
+must be wiped before the function returns. All data associated with an object,
+such as a multi-part operation, must be wiped, at the latest, when the object
+becomes inactive, for example, when a multi-part operation is aborted.
+
+The rationale for this non-functional requirement is to minimize impact if the
+system is compromised. If sensitive data is wiped immediately after use, only
+data that is currently in use can be leaked. It does not compromise past data.
+
+.. _key-material:
+
+Managing key material
+^^^^^^^^^^^^^^^^^^^^^
+
+In implementations that have limited volatile memory for keys, the
+implementation is permitted to store a `volatile key <volatile-keys>` to a
+temporary location in non-volatile memory. The implementation must delete any
+such copies when the key is destroyed, and it is recommended that these copies
+are deleted as soon as the key is reloaded into volatile memory. An
+implementation that uses this method must clear any stored volatile key material
+on startup.
+
+Implementing the `memory cleanup rule <memory-cleanup>` for persistent keys
+can result in inefficiencies when the same persistent key is used sequentially
+in multiple cryptographic operations. The inefficiency stems from loading the
+key from non-volatile storage on each use of the key. The `PSA_KEY_USAGE_CACHE`
+policy allows an application to request that the implementation does not cleanup
+non-essential copies of persistent key material, effectively suspending the
+cleanup rules for that key. The effects of this policy depend on the
+implementation and the key, for example:
+
+-  For volatile keys or keys in a secure element with no open/close mechanism,
+   this is likely to have no effect.
+-  For persistent keys that are not in a secure element, this allows the
+   implementation to keep the key in a memory cache outside of the memory used
+   by ongoing operations.
+-  For keys in a secure element with an open/close mechanism, this is a hint to
+   keep the key open in the secure element.
+
+The application can indicate when it has finished using the key by calling
+`psa_purge_key()`, to request that the key material is cleaned from memory.
+
+Safe outputs on error
+^^^^^^^^^^^^^^^^^^^^^
+
+Implementations must ensure that confidential data is not written to output
+parameters before validating that the disclosure of this confidential data is
+authorized. This requirement is particularly important for implementations where
+the caller can share memory with another security context, as described in the
+`stability-of-parameters` section.
+
+In most cases, the specification does not define the content of output
+parameters when an error occurs. It is recommended that implementations try to
+ensure that the content of output parameters is as safe as possible, in case an
+application flaw or a data leak causes it to be used. In particular, Arm
+recommends that implementations avoid placing partial output in output buffers
+when an action is interrupted. The meaning of “safe as possible” depends on the
+implementation, as different environments require different compromises between
+implementation complexity, overall robustness and performance. Some common
+strategies are to leave output parameters unchanged, in case of errors, or
+zeroing them out.
+
+Attack resistance
+^^^^^^^^^^^^^^^^^
+
+Cryptographic code tends to manipulate high-value secrets, from which other
+secrets can be unlocked. As such, it is a high-value target for attacks. There
+is a vast body of literature on attack types, such as side channel attacks and
+glitch attacks. Typical side channels include timing, cache access patterns,
+branch-prediction access patterns, power consumption, radio emissions and more.
+
+This specification does not specify particular requirements for attack
+resistance. Implementers are encouraged to consider the attack resistance
+desired in each use case and design their implementation accordingly. Security
+standards for attack resistance for particular targets might be applicable in
+certain use cases.
+
+Other implementation considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Philosophy of resource management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The specification allows most functions to return
+`PSA_ERROR_INSUFFICIENT_MEMORY`. This gives implementations the freedom to
+manage memory as they please.
+
+Alternatively, the interface is also designed for conservative strategies of
+memory management. An implementation can avoid dynamic memory allocation
+altogether by obeying certain restrictions:
+
+-  Pre-allocate memory for a predefined number of keys, each with sufficient
+   memory for all key types that can be stored.
+-  For multi-part operations, in an implementation without isolation, place all
+   the data that needs to be carried over from one step to the next in the
+   operation object. The application is then fully in control of how memory is
+   allocated for the operation.
+-  In an implementation with isolation, pre-allocate memory for a predefined
+   number of operations inside the cryptoprocessor.
+
+.. Inclusion of algorithms
+
+   Inline algorithm-generic functions into specialized functions at compile/link time
diff --git a/docs/html/_sources/overview/intro.rst.txt b/docs/html/_sources/overview/intro.rst.txt
new file mode 100644
index 0000000..416cde7
--- /dev/null
+++ b/docs/html/_sources/overview/intro.rst.txt
@@ -0,0 +1,36 @@
+Introduction
+------------
+
+Arm’s Platform Security Architecture (PSA) is a holistic set of threat models,
+security analyses, hardware and firmware architecture specifications, an
+open source firmware reference implementation, and an independent evaluation
+and certification scheme. PSA provides a recipe, based on
+industry best practice, that allows security to be consistently designed in, at
+both a hardware and firmware level.
+
+The PSA Cryptographic API (Crypto API) described in this document is an
+important PSA component that provides an interface to cryptographic operations
+on resource-constrained devices. The interface is user-friendly, while still
+providing access to the low-level primitives used in modern cryptography. It
+does not require that the user has access to the key material. Instead, it uses
+opaque key identifiers.
+
+This document is part of the PSA family of specifications. It defines an
+interface for cryptographic services, including cryptography primitives and a
+key storage functionality.
+
+This document includes:
+
+-  A `rationale <design-goals>` for the design.
+-  A `high-level overview of the functionality <functionality-overview>`
+   provided by the interface.
+-  A `description of typical architectures <architectures>` of
+   implementations for this specification.
+-  General considerations `for implementers <implementation-considerations>`
+   of this specification and `for applications <usage-considerations>` that
+   use the interface defined in this specification.
+-  A `detailed definition <api-reference>` of the API.
+
+Companion documents will define *profiles* for this specification. A profile is
+a minimum mandatory subset of the interface that a compliant implementation must
+provide.
diff --git a/docs/html/_sources/overview/sample-arch.rst.txt b/docs/html/_sources/overview/sample-arch.rst.txt
new file mode 100644
index 0000000..499283e
--- /dev/null
+++ b/docs/html/_sources/overview/sample-arch.rst.txt
@@ -0,0 +1,121 @@
+.. _architectures:
+
+Sample architectures
+--------------------
+
+This section describes some example architectures that can be used for
+implementations of the interface described in this specification. This list is
+not exhaustive and the section is entirely non-normative.
+
+Single-partition architecture
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the single-partition architecture, there is no security boundary inside the system. The
+application code can access all the system memory, including the memory used by
+the cryptographic services described in this specification. Thus, the
+architecture provides `no isolation <isolation>`.
+
+This architecture does not conform to the Arm *Platform Security Architecture
+Security Model*. However, it is useful for providing cryptographic services
+that use the same interface, even on devices that cannot support any security
+boundary. So, while this architecture is not the primary design goal of the API
+defined in the present specification, it is supported.
+
+The functions in this specification simply execute the underlying algorithmic
+code. Security checks can be kept to a minimum, since the cryptoprocessor cannot
+defend against a malicious application. Key import and export copy data inside
+the same memory space.
+
+This architecture also describes a subset of some larger systems, where the
+cryptographic services are implemented inside a high-security partition,
+separate from the code of the main application, though it shares this
+high-security partition with other platform security services.
+
+.. _isolated-cryptoprocessor:
+
+Cryptographic token and single-application processor
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This system is composed of two partitions: one is a cryptoprocessor and the
+other partition runs an application. There is a security boundary between the
+two partitions, so that the application cannot access the cryptoprocessor,
+except through its public interface. Thus, the architecture provides
+`cryptoprocessor isolation <isolation>`. The cryptoprocessor has
+some non-volatile storage, a TRNG, and possibly, some cryptographic accelerators.
+
+There are a number of potential physical realizations: the cryptoprocessor might
+be a separate chip, a separate processor on the same chip, or a logical
+partition using a combination of hardware and software to provide the isolation.
+These realizations are functionally equivalent in terms of the offered software
+interface, but they would typically offer different levels of security
+guarantees.
+
+The PSA crypto API in the application processor consists of a thin layer of code
+that translates function calls to remote procedure calls in the cryptoprocessor.
+All cryptographic computations are, therefore, performed inside the
+cryptoprocessor. Non-volatile keys are stored inside the cryptoprocessor.
+
+Cryptoprocessor with no key storage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As in the :title:`isolated-cryptoprocessor` architecture, this system
+is also composed of two partitions separated by a security boundary and also
+provides `cryptoprocessor isolation <isolation>`.
+However, unlike the previous architecture, in this system, the cryptoprocessor
+does not have any secure, persistent storage that could be used to store
+application keys.
+
+If the cryptoprocessor is not capable of storing cryptographic material, then
+there is little use for a separate cryptoprocessor, since all data would have to
+be imported by the application.
+
+The cryptoprocessor can provide useful services if it is able to store at least
+one key. This might be a hardware unique key that is burnt to one-time
+programmable memory during the manufacturing of the device. This key can be used
+for one or more purposes:
+
+-  Encrypt and authenticate data stored in the application processor.
+-  Communicate with a paired device.
+-  Allow the application to perform operations with keys that are derived from
+   the hardware unique key.
+
+Multi-client cryptoprocessor
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is an expanded variant of the `cryptographic token plus application
+architecture <isolated-cryptoprocessor>`. In this
+variant, the cryptoprocessor serves multiple applications that are mutually
+untrustworthy. This architecture provides `caller
+isolation <isolation>`.
+
+In this architecture, API calls are translated to remote procedure calls, which
+encode the identity of the client application. The cryptoprocessor carefully
+segments its internal storage to ensure that a client’s data is never leaked to
+another client.
+
+Multi-cryptoprocessor architecture
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This system includes multiple cryptoprocessors. There are several reasons to
+have multiple cryptoprocessors:
+
+-  Different compromises between security and performance for different keys.
+   Typically, this means a cryptoprocessor that runs on the same hardware as the
+   main application and processes short-term secrets, a secure element or a
+   similar separate chip that retains long-term secrets.
+-  Independent provisioning of certain secrets.
+-  A combination of a non-removable cryptoprocessor and removable ones, for
+   example, a smartcard or HSM.
+-  Cryptoprocessors managed by different stakeholders who do not trust each
+   other.
+
+The keystore implementation needs to dispatch each request to the correct
+processor. For example:
+
+-  All requests involving a non-extractable key must be processed in the
+   cryptoprocessor that holds that key.
+-  Requests involving a persistent key must be processed in the cryptoprocessor
+   that corresponds to the key’s lifetime value.
+-  Requests involving a volatile key might target a cryptoprocessor based on
+   parameters supplied by the application, or based on considerations such as
+   performance inside the implementation.
diff --git a/docs/html/_sources/overview/usage.rst.txt b/docs/html/_sources/overview/usage.rst.txt
new file mode 100644
index 0000000..1d1f2c9
--- /dev/null
+++ b/docs/html/_sources/overview/usage.rst.txt
@@ -0,0 +1,71 @@
+.. _usage-considerations:
+
+Usage considerations
+--------------------
+
+Security recommendations
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Always check for errors
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Most functions in this API can return errors. All functions that can fail have
+the return type `psa_status_t`. A few functions cannot fail, and thus, return
+``void`` or some other type.
+
+If an error occurs, unless otherwise specified, the content of the output
+parameters is undefined and must not be used.
+
+Some common causes of errors include:
+
+-  In implementations where the keys are stored and processed in a separate
+   environment from the application, all functions that need to access the
+   cryptography processing environment might fail due to an error in the
+   communication between the two environments.
+-  If an algorithm is implemented with a hardware accelerator, which is
+   logically separate from the application processor, the accelerator might fail,
+   even when the application processor keeps running normally.
+-  Most functions might fail due to a lack of resources. However, some
+   implementations guarantee that certain functions always have sufficient
+   memory.
+-  All functions that access persistent keys might fail due to a storage failure.
+-  All functions that require randomness might fail due to a lack of entropy.
+   Implementations are encouraged to seed the random generator with sufficient
+   entropy during the execution of `psa_crypto_init()`. However, some security
+   standards require periodic reseeding from a hardware random generator, which
+   can fail.
+
+Shared memory and concurrency
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some environments allow applications to be multithreaded, while others do not.
+In some environments, applications can share memory with a different security
+context. In environments with multithreaded applications or shared memory,
+applications must be written carefully to avoid data corruption or leakage. This
+specification requires the application to obey certain constraints.
+
+In general, this API allows either one writer or any number of simultaneous
+readers, on any given object. In other words, if two or more calls access the
+same object concurrently, then the behavior is only well-defined if all the
+calls are only reading from the object and do not modify it. Read accesses
+include reading memory by input parameters and reading keystore content by using
+a key. For more details, refer to the `concurrency`
+section.
+
+If an application shares memory with another security context, it can pass
+shared memory blocks as input buffers or output buffers, but not as non-buffer
+parameters. For more details, refer to the :title:`stability-of-parameters` section.
+
+Cleaning up after use
+^^^^^^^^^^^^^^^^^^^^^
+
+To minimize impact if the system is compromised, it is recommended that
+applications wipe all sensitive data from memory when it is no longer used. That
+way, only data that is currently in use can be leaked, and past data is not
+compromised.
+
+Wiping sensitive data includes:
+
+-  Clearing temporary buffers in the stack or on the heap.
+-  Aborting operations if they will not be finished.
+-  Destroying keys that are no longer used.