diff --git a/docs/1.1.0/html/overview/conventions.html b/docs/1.1.0/html/overview/conventions.html
new file mode 100644
index 0000000..9d2d4ea
--- /dev/null
+++ b/docs/1.1.0/html/overview/conventions.html
@@ -0,0 +1,464 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>5. Library conventions &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="6. Implementation considerations" href="implementation.html" />
+    <link rel="prev" title="4. Sample architectures" href="sample-arch.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="library-conventions">
+<span id="id1"></span><h1>5. Library conventions</h1>
+<div class="section" id="header-files">
+<h2>5.1. Header files</h2>
+<p>The header file for the PSA Cryptography API has the name <code class="file docutils literal"><span class="pre">psa/crypto.h</span></code>. All of the API elements that are provided by an implementation must be visible to an application program that includes this header file.</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>#include &quot;psa/crypto.h&quot;
+</pre></div>
+</div>
+<p>Implementations must provide their own version of the <code class="file docutils literal"><span class="pre">psa/crypto.h</span></code> header file. Implementations can provide a subset of the API defined in this specification and a subset of the available algorithms. <a class="reference internal" href="../appendix/example_header.html#appendix-example-header"><span class="secref">Example header file</span></a> provides an incomplete, example header file which includes all of the API elements. See also <a class="reference internal" href="implementation.html#implementation-considerations"><span class="secref">Implementation considerations</span></a>.</p>
+<p>This API uses some of the common status codes that are defined by <span><em>Arm® Platform Security Architecture Firmware Framework</em> <a class="reference internal" href="../about.html#citation-ff-m"><span class="cite">[FF-M]</span></a></span> as part of the <code class="file docutils literal"><span class="pre">psa/error.h</span></code> header file. Applications are not required to explicitly include the <code class="file docutils literal"><span class="pre">psa/error.h</span></code> header file when using these status codes with the PSA Crypto API. See <a class="reference internal" href="../api/library/status.html#status-codes"><span class="secref">PSA status codes</span></a>.</p>
+</div>
+<div class="section" id="api-conventions">
+<span id="id2"></span><h2>5.2. API conventions</h2>
+<p>The interface in this specification is defined in terms of C macros, data types, and functions.</p>
+<div class="section" id="identifier-names">
+<h3>5.2.1. Identifier names</h3>
+<p>All of the identifiers defined in this API begin with the prefix <code class="docutils literal"><span class="pre">psa_</span></code>, for types and functions, or <code class="docutils literal"><span class="pre">PSA_</span></code> for macros.</p>
+<p>Future versions of this specification will use the same prefix for additional API elements. It is recommended that applications and implementations do not use this prefix for their own identifiers, to avoid a potential conflict with a future version of the PSA Crypto API.</p>
+</div>
+<div class="section" id="basic-types">
+<h3>5.2.2. Basic types</h3>
+<p>This specification makes use of standard C data types, including the fixed-width integer types from the ISO C99 specification update <a class="reference internal" href="../about.html#citation-c99"><span class="cite">[C99]</span></a>. The following standard C types are used:</p>
+<table border="1" class="colwidths-auto docutils align-left">
+<tbody valign="top">
+<tr class="row-odd"><td><code class="docutils literal"><span class="pre">int32_t</span></code></td>
+<td>a 32-bit signed integer</td>
+</tr>
+<tr class="row-even"><td><code class="docutils literal"><span class="pre">uint8_t</span></code></td>
+<td>an 8-bit unsigned integer</td>
+</tr>
+<tr class="row-odd"><td><code class="docutils literal"><span class="pre">uint16_t</span></code></td>
+<td>a 16-bit unsigned integer</td>
+</tr>
+<tr class="row-even"><td><code class="docutils literal"><span class="pre">uint32_t</span></code></td>
+<td>a 32-bit unsigned integer</td>
+</tr>
+<tr class="row-odd"><td><code class="docutils literal"><span class="pre">uint64_t</span></code></td>
+<td>a 64-bit unsigned integer</td>
+</tr>
+<tr class="row-even"><td><code class="docutils literal"><span class="pre">size_t</span></code></td>
+<td>an unsigned integer large enough to hold the size of an object in memory</td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="data-types">
+<h3>5.2.3. Data types</h3>
+<p>Integral types are defined for specific API elements to provide clarity in the interface definition, and to improve code readability. For example, <a class="reference internal" href="../api/ops/algorithms.html#c.psa_algorithm_t" title="psa_algorithm_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_algorithm_t</span></code></a> and <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_status_t</span></code></a>.</p>
+<p>Structure types are declared using <code class="docutils literal"><span class="pre">typedef</span></code> instead of a <code class="docutils literal"><span class="pre">struct</span></code> tag, also to improve code readability.</p>
+<p>Fully-defined types must be declared exactly as defined in this specification. Types that are not fully defined in this specification must be defined by an implementation. See <a class="reference internal" href="implementation.html#implementation-defined-type"><span class="secref">Implementation-specific types</span></a>.</p>
+</div>
+<div class="section" id="constants">
+<h3>5.2.4. Constants</h3>
+<p>Constant values are defined using C macros. Constants defined in this specification have names that are all upper-case.</p>
+<p>A constant macro evaluates to a compile-time constant expression.</p>
+</div>
+<div class="section" id="function-like-macros">
+<h3>5.2.5. Function-like macros</h3>
+<p>Function-like macros are C macros that take parameters, providing supporting functionality in the API. Function-like macros defined in this specification have names that are all upper-case.</p>
+<p>Function-like macros are permitted to evaluate each argument multiple times or zero times. Providing arguments that have side effects will result in <a class="reference internal" href="../about.html#term-implementation-defined"><span class="scterm">IMPLEMENTATION DEFINED</span></a> behavior, and is non-portable.</p>
+<p>If all of the arguments to a function-like macro are compile-time constant expressions, the then result evaluates to a compile-time constant expression.</p>
+<p>If an argument to a function-like macro has an invalid value (for example, a value outside the domain of the function-like macro), then the result is <a class="reference internal" href="../about.html#term-implementation-defined"><span class="scterm">IMPLEMENTATION DEFINED</span></a>.</p>
+</div>
+<div class="section" id="functions">
+<h3>5.2.6. Functions</h3>
+<p>Functions defined in this specification have names that are all lower-case.</p>
+<p>An implementation is permitted to declare any API function with <code class="docutils literal"><span class="pre">static</span> <span class="pre">inline</span></code> linkage, instead of the default <code class="docutils literal"><span class="pre">extern</span></code> linkage.</p>
+<p>An implementation is permitted to also define a function-like macro with the same name as a function in this specification. If an implementation defines a function-like macro for a function from this specification, then:</p>
+<ul class="simple">
+<li>The implementation must also provide a definition of the function. This enables an application to take the address of a function defined in this specification.</li>
+<li>The function-like macro must expand to code that evaluates each of its arguments exactly once, as if the call was made to a C function. This enables an application to safely use arbitrary expressions as arguments to a function defined in this specification.</li>
+</ul>
+<p>If a non-pointer argument to a function has an invalid value (for example, a value outside the domain of the function), then the function will normally return an error, as specified in the function definition. See also <a class="reference internal" href="#error-handling"><span class="secref">Error handling</span></a>.</p>
+<p>If a pointer argument to a function has an invalid value (for example, a pointer outside the address space of the program, or a null pointer), the result is <a class="reference internal" href="../about.html#term-implementation-defined"><span class="scterm">IMPLEMENTATION DEFINED</span></a>. See also <a class="reference internal" href="#pointer-conventions"><span class="secref">Pointer conventions</span></a>.</p>
+</div>
+</div>
+<div class="section" id="error-handling">
+<span id="id3"></span><h2>5.3. Error handling</h2>
+<div class="section" id="return-status">
+<h3>5.3.1. Return status</h3>
+<p>Almost all functions return a status indication of type <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_status_t</span></code></a>. This
+is an enumeration of integer values, with <code class="docutils literal"><span class="pre">0</span></code> (<a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_SUCCESS</span></code></a>) 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
+<code class="docutils literal"><span class="pre">void</span></code> or a data value.</p>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="behavior-on-error">
+<h3>5.3.2. Behavior on error</h3>
+<p>All function calls must be implemented atomically:</p>
+<ul class="simple">
+<li>When a function returns a type other than <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_status_t</span></code></a>, the requested
+action has been carried out.</li>
+<li>When a function returns the status <a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_SUCCESS</span></code></a>, the requested action has
+been carried out.</li>
+<li>When a function returns another status of type <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_status_t</span></code></a>, 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.</li>
+</ul>
+<p>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:</p>
+<ul class="simple">
+<li>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_BAD_STATE" title="PSA_ERROR_BAD_STATE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_BAD_STATE</span></code></a> 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
+<code class="docutils literal"><span class="pre">psa_abort_xxx()</span></code> function.</li>
+<li>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_INSUFFICIENT_DATA" title="PSA_ERROR_INSUFFICIENT_DATA"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_INSUFFICIENT_DATA</span></code></a> 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
+<a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_INSUFFICIENT_DATA" title="PSA_ERROR_INSUFFICIENT_DATA"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_INSUFFICIENT_DATA</span></code></a>.</li>
+<li>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_COMMUNICATION_FAILURE" title="PSA_ERROR_COMMUNICATION_FAILURE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_COMMUNICATION_FAILURE</span></code></a> 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.</li>
+<li>The statuses <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_STORAGE_FAILURE" title="PSA_ERROR_STORAGE_FAILURE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_STORAGE_FAILURE</span></code></a>, <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_DATA_CORRUPT" title="PSA_ERROR_DATA_CORRUPT"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_DATA_CORRUPT</span></code></a>, <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_HARDWARE_FAILURE" title="PSA_ERROR_HARDWARE_FAILURE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_HARDWARE_FAILURE</span></code></a>
+and <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_CORRUPTION_DETECTED" title="PSA_ERROR_CORRUPTION_DETECTED"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_CORRUPTION_DETECTED</span></code></a> 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.</li>
+<li>Some system states cannot be rolled back, for example, the internal state of
+the random number generator or the content of access logs.</li>
+</ul>
+<p>Unless otherwise documented, the content of output parameters is not defined
+when a function returns a status other than <a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_SUCCESS</span></code></a>. 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.</p>
+</div>
+</div>
+<div class="section" id="parameter-conventions">
+<h2>5.4. Parameter conventions</h2>
+<div class="section" id="pointer-conventions">
+<span id="id4"></span><h3>5.4.1. Pointer conventions</h3>
+<p>Unless explicitly stated in the documentation of a function, all pointers must
+be valid pointers to an object of the specified type.</p>
+<p>A parameter is considered a <strong>buffer</strong> if it points to an array of bytes. A
+buffer parameter always has the type <code class="docutils literal"><span class="pre">uint8_t</span> <span class="pre">*</span></code> or <code class="docutils literal"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*</span></code>, and
+always has an associated parameter indicating the size of the array. Note that a
+parameter of type <code class="docutils literal"><span class="pre">void</span> <span class="pre">*</span></code> is never considered a buffer.</p>
+<p>All parameters of pointer type must be valid non-null pointers, unless the
+pointer is to a buffer of length <code class="docutils literal"><span class="pre">0</span></code> 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.</p>
+<p>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
+<a class="reference internal" href="#stability-of-parameters"><span class="secref">Stability of parameters</span></a>.</p>
+</div>
+<div class="section" id="input-buffer-sizes">
+<h3>5.4.2. Input buffer sizes</h3>
+<p>For input buffers, the parameter convention is:</p>
+<dl class="docutils">
+<dt><code class="docutils literal"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt>
+<dd>Pointer to the first byte of the data. The pointer
+can be invalid if the buffer size is <code class="docutils literal"><span class="pre">0</span></code>.</dd>
+<dt><code class="docutils literal"><span class="pre">size_t</span> <span class="pre">foo_length</span></code></dt>
+<dd>Size of the buffer in bytes.</dd>
+</dl>
+<p>The interface never uses input-output buffers.</p>
+</div>
+<div class="section" id="output-buffer-sizes">
+<span id="output-buffers"></span><h3>5.4.3. Output buffer sizes</h3>
+<p>For output buffers, the parameter convention is:</p>
+<dl class="docutils">
+<dt><code class="docutils literal"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt>
+<dd>Pointer to the first byte of the data. The pointer can be
+invalid if the buffer size is <code class="docutils literal"><span class="pre">0</span></code>.</dd>
+<dt><code class="docutils literal"><span class="pre">size_t</span> <span class="pre">foo_size</span></code></dt>
+<dd>The size of the buffer in bytes.</dd>
+<dt><code class="docutils literal"><span class="pre">size_t</span> <span class="pre">*foo_length</span></code></dt>
+<dd>On successful return, contains the length of the
+output in bytes.</dd>
+</dl>
+<p>The content of the data buffer and of <code class="docutils literal"><span class="pre">*foo_length</span></code> 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 <code class="docutils literal"><span class="pre">*foo_length</span></code> and <code class="docutils literal"><span class="pre">foo_size</span></code> is also unspecified.</p>
+<p>Functions return <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_BUFFER_TOO_SMALL" title="PSA_ERROR_BUFFER_TOO_SMALL"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_BUFFER_TOO_SMALL</span></code></a> 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.</p>
+<p>Some functions always return exactly as much data as the size of the output
+buffer. In this case, the parameter convention changes to:</p>
+<dl class="docutils">
+<dt><code class="docutils literal"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt>
+<dd>Pointer to the first byte of the output. The pointer can be
+invalid if the buffer size is <code class="docutils literal"><span class="pre">0</span></code>.</dd>
+<dt><code class="docutils literal"><span class="pre">size_t</span> <span class="pre">foo_length</span></code></dt>
+<dd>The number of bytes to return in <code class="docutils literal"><span class="pre">foo</span></code> if
+successful.</dd>
+</dl>
+</div>
+<div class="section" id="overlap-between-parameters">
+<span id="buffer-overlap"></span><h3>5.4.4. Overlap between parameters</h3>
+<p>Output parameters that are not buffers must not overlap with any input buffer or
+with any other output parameter. Otherwise, the behavior is undefined.</p>
+<p>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
+<a class="reference internal" href="#stability-of-parameters"><span class="secref">Stability of parameters</span></a>.</p>
+</div>
+<div class="section" id="stability-of-parameters">
+<span id="id5"></span><h3>5.4.5. Stability of parameters</h3>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>Unless otherwise specified, the implementation must not keep a reference to any
+parameter once a function call has returned.</p>
+</div>
+</div>
+<div class="section" id="key-types-and-algorithms">
+<h2>5.5. Key types and algorithms</h2>
+<p>Types of cryptographic keys and cryptographic algorithms are encoded separately.
+Each is encoded by using an integral type: <a class="reference internal" href="../api/keys/types.html#c.psa_key_type_t" title="psa_key_type_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_key_type_t</span></code></a> and
+<a class="reference internal" href="../api/ops/algorithms.html#c.psa_algorithm_t" title="psa_algorithm_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_algorithm_t</span></code></a>, respectively.</p>
+<p>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 <a class="reference internal" href="../api/ops/aead.html#c.PSA_ALG_GCM" title="PSA_ALG_GCM"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ALG_GCM</span></code></a> 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.</p>
+<p>Key types do not encode the key size. For example, AES-128, AES-192 and AES-256
+share a key type <a class="reference internal" href="../api/keys/types.html#c.PSA_KEY_TYPE_AES" title="PSA_KEY_TYPE_AES"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_TYPE_AES</span></code></a>.</p>
+<div class="section" id="structure-of-key-types-and-algorithms">
+<h3>5.5.1. Structure of key types and algorithms</h3>
+<p>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.</p>
+<p>The encodings follows a few conventions:</p>
+<ul class="simple">
+<li>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.</li>
+<li>The next few highest bits indicate the algorithm or key category:
+hash, MAC, symmetric cipher, asymmetric encryption, and so on.</li>
+<li>The following bits identify a family of algorithms or keys in a category-dependent
+manner.</li>
+<li>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.</li>
+</ul>
+<p>The <a class="reference internal" href="../appendix/encodings.html#appendix-encodings"><span class="secref">Algorithm and key type encoding</span></a> appendix provides a full definition of the encoding of key types and algorithm identifiers.</p>
+</div>
+</div>
+<div class="section" id="concurrent-calls">
+<span id="concurrency"></span><h2>5.6. Concurrent calls</h2>
+<p>In some environments, an application can make calls to the PSA crypto API in
+separate threads. In such an environment, <em>concurrent calls</em> are two or more
+calls to the API whose execution can overlap in time.</p>
+<p>Concurrent calls are performed correctly, as if the calls were executed in
+sequence, provided that they obey the following constraints:</p>
+<ul class="simple">
+<li>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.</li>
+<li>A call to destroy a key must not overlap with a concurrent call to any of
+the following functions:<ul>
+<li>Any call where the same key identifier is a parameter to the call.</li>
+<li>Any call in a multi-part operation, where the same key identifier was
+used as a parameter to a previous step in the multi-part operation.</li>
+</ul>
+</li>
+<li>Concurrent calls must not use the same operation object.</li>
+</ul>
+<p>If any of these constraints are violated, the behavior is undefined.</p>
+<p>If the application modifies an input parameter while a function call is in
+progress, the behavior is undefined.</p>
+<p>Individual implementations can provide additional guarantees.</p>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">5. Library conventions</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#header-files">5.1. Header files</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#api-conventions">5.2. API conventions</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#identifier-names">5.2.1. Identifier names</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#basic-types">5.2.2. Basic types</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#data-types">5.2.3. Data types</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#constants">5.2.4. Constants</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#function-like-macros">5.2.5. Function-like macros</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#functions">5.2.6. Functions</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#error-handling">5.3. Error handling</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#return-status">5.3.1. Return status</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#behavior-on-error">5.3.2. Behavior on error</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#parameter-conventions">5.4. Parameter conventions</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#pointer-conventions">5.4.1. Pointer conventions</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#input-buffer-sizes">5.4.2. Input buffer sizes</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#output-buffer-sizes">5.4.3. Output buffer sizes</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#overlap-between-parameters">5.4.4. Overlap between parameters</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#stability-of-parameters">5.4.5. Stability of parameters</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#key-types-and-algorithms">5.5. Key types and algorithms</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#structure-of-key-types-and-algorithms">5.5.1. Structure of key types and algorithms</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#concurrent-calls">5.6. Concurrent calls</a></li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/functionality.html b/docs/1.1.0/html/overview/functionality.html
new file mode 100644
index 0000000..0658fa6
--- /dev/null
+++ b/docs/1.1.0/html/overview/functionality.html
@@ -0,0 +1,397 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>3. Functionality overview &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="4. Sample architectures" href="sample-arch.html" />
+    <link rel="prev" title="2. Design goals" href="goals.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="functionality-overview">
+<span id="id1"></span><h1>3. Functionality overview</h1>
+<p>This section provides a high-level overview of the functionality provided by the
+interface defined in this specification. Refer to the
+API definition for a detailed description, which begins with <a class="reference internal" href="../api/library/index.html#library-management"><span class="secref">Library management reference</span></a>.</p>
+<p><a class="reference internal" href="../appendix/history.html#future"><span class="secref">Future additions</span></a> describes features that might be included in future versions of this
+specification.</p>
+<p>Due to the modularity of the interface, almost every part of the library is
+optional. The only mandatory function is <a class="reference internal" href="../api/library/library.html#c.psa_crypto_init" title="psa_crypto_init"><code class="xref any c c-func docutils literal"><span class="pre">psa_crypto_init()</span></code></a>.</p>
+<div class="section" id="library-management">
+<h2>3.1. Library management</h2>
+<p>Applications must call <a class="reference internal" href="../api/library/library.html#c.psa_crypto_init" title="psa_crypto_init"><code class="xref any c c-func docutils literal"><span class="pre">psa_crypto_init()</span></code></a> to initialize the library before
+using any other function.</p>
+</div>
+<div class="section" id="key-management">
+<span id="key-overview"></span><h2>3.2. Key management</h2>
+<p>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 <em>non-extractable</em>, 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.</p>
+<p>Each key has a set of attributes that describe the key and the policy for using
+the key. A <a class="reference internal" href="../api/keys/attributes.html#c.psa_key_attributes_t" title="psa_key_attributes_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_key_attributes_t</span></code></a> object contains all of the attributes, which
+is used when creating a key and when querying key attributes.</p>
+<p>The key attributes include:</p>
+<ul class="simple">
+<li>A type and size that describe the key material. See <a class="reference internal" href="#key-types-intro"><span class="secref">Key types</span></a>.</li>
+<li>The key identifier that the application uses to refer to the key. See <a class="reference internal" href="#key-ids"><span class="secref">Key identifiers</span></a>.</li>
+<li>A lifetime that determines when the key material is destroyed, and where it is stored. See <a class="reference internal" href="#key-life"><span class="secref">Key lifetimes</span></a>.</li>
+<li>A policy that determines how the key can be used. See <a class="reference internal" href="#key-usage-policies"><span class="secref">Key policies</span></a>.</li>
+</ul>
+<p>Keys are created using one of the <em>key creation functions</em>:</p>
+<ul class="simple">
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_import_key" title="psa_import_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_import_key()</span></code></a></li>
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_generate_key" title="psa_generate_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_generate_key()</span></code></a></li>
+<li><a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_output_key" title="psa_key_derivation_output_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_output_key()</span></code></a></li>
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_copy_key" title="psa_copy_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_copy_key()</span></code></a></li>
+</ul>
+<p>These output the key identifier, that is used to access the key in all other parts of the API.</p>
+<p>All of the key attributes 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 or restricted policy for the
+copy of the key.</p>
+<p>A call to <a class="reference internal" href="../api/keys/management.html#c.psa_destroy_key" title="psa_destroy_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_destroy_key()</span></code></a> 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.</p>
+<div class="section" id="key-types">
+<span id="key-types-intro"></span><h3>3.2.1. Key types</h3>
+<p>Each cryptographic algorithm requires a key that has the right form, in terms of the size of the key material and its numerical properties. The key type and key size encode that information about a key, and determine whether the key is compatible with a cryptographic algorithm.</p>
+<p>Additional non-cryptographic key types enable applications to store other secret values in the keystore.</p>
+<p>See <a class="reference internal" href="../api/keys/types.html#key-types"><span class="secref">Key types</span></a>.</p>
+</div>
+<div class="section" id="key-identifiers">
+<span id="key-ids"></span><h3>3.2.2. Key identifiers</h3>
+<p>Key identifiers are integral values that act as permanent names for persistent keys, or as transient references to volatile keys. Key identifiers are defined by the application for persistent keys, and by the implementation for volatile keys and for built-in keys.</p>
+<p>Key identifiers are output from a successful call to one of the key creation functions.</p>
+<p>Valid key identifiers must have distinct values within the same application. If
+the implementation provides <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">caller isolation</span></a>, then key
+identifiers are local to each application.</p>
+<p>See <a class="reference internal" href="../api/keys/ids.html#key-identifiers"><span class="secref">Key identifiers</span></a>.</p>
+</div>
+<div class="section" id="key-lifetimes">
+<span id="key-life"></span><h3>3.2.3. Key lifetimes</h3>
+<p>The lifetime of a key indicates where it is stored and which application and system actions will create and destroy it.</p>
+<p>There are two main types of lifetimes: <em>volatile</em> and <em>persistent</em>.</p>
+<p>Volatile keys are automatically destroyed when the application instance terminates or on a power reset of the device. Volatile key identifiers are allocated by the implementation when the key is created. Volatile keys can be explicitly destroyed with a call to <a class="reference internal" href="../api/keys/management.html#c.psa_destroy_key" title="psa_destroy_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_destroy_key()</span></code></a>.</p>
+<p>Persistent keys are preserved until the application explicitly destroys them or until an implementation-specific device management event occurs, for example, a factory reset. The key identifier for a persistent key is set by the application when creating the key, and remains valid throughout the lifetime of the key, even if the application instance that created the key terminates.</p>
+<p>See <a class="reference internal" href="../api/keys/lifetimes.html#key-lifetimes"><span class="secref">Key lifetimes</span></a>.</p>
+</div>
+<div class="section" id="key-policies">
+<span id="key-usage-policies"></span><h3>3.2.4. Key policies</h3>
+<p>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. See <a class="reference internal" href="../api/keys/policy.html#key-policy"><span class="secref">Key policies</span></a>.</p>
+</div>
+<div class="section" id="recommendations-of-minimum-standards-for-key-management">
+<h3>3.2.5. Recommendations of minimum standards for key management</h3>
+<p>Most implementations provide the following functions:</p>
+<ul class="simple">
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_import_key" title="psa_import_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_import_key()</span></code></a>. 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.</li>
+<li><a class="reference internal" href="../api/keys/attributes.html#c.psa_get_key_attributes" title="psa_get_key_attributes"><code class="xref any c c-func docutils literal"><span class="pre">psa_get_key_attributes()</span></code></a> and the <code class="docutils literal"><span class="pre">psa_get_key_xxx()</span></code> 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.</li>
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_export_public_key" title="psa_export_public_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_export_public_key()</span></code></a>. 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.</li>
+<li><a class="reference internal" href="../api/keys/management.html#c.psa_export_key" title="psa_export_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_export_key()</span></code></a>. 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.</li>
+</ul>
+</div>
+</div>
+<div class="section" id="symmetric-cryptography">
+<h2>3.3. Symmetric cryptography</h2>
+<p>This specification defines interfaces for the following types of symmetric
+cryptographic operation:</p>
+<ul class="simple">
+<li>Message digests, commonly known as hash functions. See <a class="reference internal" href="../api/ops/hashes.html#hashes"><span class="secref">Message digests (Hashes)</span></a>.</li>
+<li>Message authentication codes (MAC). See <a class="reference internal" href="../api/ops/macs.html#macs"><span class="secref">Message authentication codes (MAC)</span></a>.</li>
+<li>Symmetric ciphers. See <a class="reference internal" href="../api/ops/ciphers.html#ciphers"><span class="secref">Unauthenticated ciphers</span></a>.</li>
+<li>Authenticated encryption with associated data (AEAD). See <a class="reference internal" href="../api/ops/aead.html#aead"><span class="secref">Authenticated encryption with associated data (AEAD)</span></a>.</li>
+<li>Key derivation. See <a class="reference internal" href="../api/ops/kdf.html#kdf"><span class="secref">Key derivation</span></a>.</li>
+</ul>
+<p>For each type of symmetric cryptographic operation, the API can include:</p>
+<ul class="simple">
+<li>A pair of <em>single-part</em> functions. For example, compute and verify, or
+encrypt and decrypt.</li>
+<li>A series of functions that permit <em>multi-part operations</em>.</li>
+</ul>
+<p>Key derivation only provides multi-part operation, to support the flexibility required by these type of algorithms.</p>
+<div class="section" id="single-part-functions">
+<h3>3.3.1. Single-part Functions</h3>
+<p>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.</p>
+<p>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 <a class="reference internal" href="#multi-part-operations"><span class="std std-ref">multi-part operation</span></a>.</p>
+</div>
+<div class="section" id="multi-part-operations">
+<span id="id2"></span><h3>3.3.2. Multi-part operations</h3>
+<p>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:</p>
+<ul class="simple">
+<li>Processing messages that cannot be assembled in memory.</li>
+<li>Using a deterministic IV for unauthenticated encryption.</li>
+<li>Providing the IV separately for unauthenticated encryption or decryption.</li>
+<li>Separating the AEAD authentication tag from the cipher text.</li>
+</ul>
+<p>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:</p>
+<ol class="arabic">
+<li><p class="first"><strong>Allocate:</strong> Allocate memory for an operation object of the appropriate
+type. The application can use any allocation strategy: stack, heap, static, etc.</p>
+</li>
+<li><p class="first"><strong>Initialize:</strong> Initialize or assign the operation object by one of the
+following methods:</p>
+<ul class="simple">
+<li>Set it to logical zero. This is automatic for static and global
+variables. Explicit initialization must use the associated
+<code class="docutils literal"><span class="pre">PSA_xxx_INIT</span></code> macro as the type is implementation-defined.</li>
+<li>Set it to all-bits zero. This is automatic if the object was
+allocated with <code class="docutils literal"><span class="pre">calloc()</span></code>.</li>
+<li>Assign the value of the associated macro <code class="docutils literal"><span class="pre">PSA_xxx_INIT</span></code>.</li>
+<li>Assign the result of calling the associated function
+<code class="docutils literal"><span class="pre">psa_xxx_init()</span></code>.</li>
+</ul>
+<p>The resulting object is now <em>inactive</em>.</p>
+<p>It is an error to initialize an operation object that is in <em>active</em> or
+<em>error</em> states. This can leak memory or other resources.</p>
+</li>
+<li><p class="first"><strong>Setup:</strong> Start a new multi-part operation on an <em>inactive</em> operation
+object. Each operation object will define one or more setup functions to
+start a specific operation.</p>
+<p>On success, a setup function will put an operation object into an <em>active</em>
+state. On failure, the operation object will remain <em>inactive</em>.</p>
+</li>
+<li><p class="first"><strong>Update:</strong> Update an <em>active</em> operation object. The update function can
+provide additional parameters, supply data for processing or generate
+outputs.</p>
+<p>On success, the operation object remains <em>active</em>. On failure, the
+operation object will enter an <em>error</em> state.</p>
+</li>
+<li><p class="first"><strong>Finish:</strong> 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.</p>
+<p>On success, the operation object returns to the <em>inactive</em> state. On
+failure, the operation object will enter an <em>error</em> state.</p>
+</li>
+</ol>
+<p>An operation can be aborted at any stage during its use by calling the
+associated <code class="docutils literal"><span class="pre">psa_xxx_abort()</span></code> function. This will release any resources
+associated with the operation and return the operation object to the <em>inactive</em>
+state.</p>
+<p>Any error that occurs to an operation while it is in an <em>active</em> state will
+result in the operation entering an <em>error</em> state. The application must call the
+associated <code class="docutils literal"><span class="pre">psa_xxx_abort()</span></code> function to release the operation resources and
+return the object to the <em>inactive</em> state.</p>
+<p>Once an operation object is returned to the <em>inactive</em> state, it can be reused
+by calling one of the applicable setup functions again.</p>
+<p>If a multi-part operation object is not initialized before use, the behavior is
+undefined.</p>
+<p>If a multi-part operation function determines that the operation object is not in
+any valid state, it can return <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_CORRUPTION_DETECTED" title="PSA_ERROR_CORRUPTION_DETECTED"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_CORRUPTION_DETECTED</span></code></a>.</p>
+<p>If a multi-part operation function is called with an operation object in the
+wrong state, the function will return <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_BAD_STATE" title="PSA_ERROR_BAD_STATE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_BAD_STATE</span></code></a> and the operation
+object will enter the <em>error</em> state.</p>
+<p>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:</p>
+<ul class="simple">
+<li>Moving the object while a function is being called on the object. This is
+not safe. See also <a class="reference internal" href="conventions.html#concurrency"><span class="secref">Concurrent calls</span></a>.</li>
+<li>Working with both the original and the copied operation objects. This
+requires cloning the operation, which is only available for hash operations
+using <a class="reference internal" href="../api/ops/hashes.html#c.psa_hash_clone" title="psa_hash_clone"><code class="xref any c c-func docutils literal"><span class="pre">psa_hash_clone()</span></code></a>.</li>
+</ul>
+<p>Each type of multi-part operation can have multiple <em>active</em> states.
+Documentation for the specific operation describes the configuration and update
+functions, and any requirements about their usage and ordering.</p>
+</div>
+<div class="section" id="example-of-the-symmetric-cryptography-api">
+<span id="symmetric-crypto-example"></span><h3>3.3.3. Example of the symmetric cryptography API</h3>
+<p>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.</p>
+<ol class="arabic simple">
+<li>Derive the message encryption material from the master key.<ol class="loweralpha">
+<li>Initialize a <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_operation_t" title="psa_key_derivation_operation_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_key_derivation_operation_t</span></code></a> object to zero or to
+<a class="reference internal" href="../api/ops/kdf.html#c.PSA_KEY_DERIVATION_OPERATION_INIT" title="PSA_KEY_DERIVATION_OPERATION_INIT"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_DERIVATION_OPERATION_INIT</span></code></a>.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_setup" title="psa_key_derivation_setup"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_setup()</span></code></a> with <a class="reference internal" href="../api/ops/kdf.html#c.PSA_ALG_HKDF" title="PSA_ALG_HKDF"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ALG_HKDF</span></code></a> as the algorithm.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_input_key" title="psa_key_derivation_input_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_input_key()</span></code></a> with the step
+<a class="reference internal" href="../api/ops/kdf.html#c.PSA_KEY_DERIVATION_INPUT_SECRET" title="PSA_KEY_DERIVATION_INPUT_SECRET"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_DERIVATION_INPUT_SECRET</span></code></a> and the master key.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_input_bytes" title="psa_key_derivation_input_bytes"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_input_bytes()</span></code></a> with the step
+<a class="reference internal" href="../api/ops/kdf.html#c.PSA_KEY_DERIVATION_INPUT_INFO" title="PSA_KEY_DERIVATION_INPUT_INFO"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_DERIVATION_INPUT_INFO</span></code></a> and a public value that uniquely
+identifies the message.</li>
+<li>Populate a <a class="reference internal" href="../api/keys/attributes.html#c.psa_key_attributes_t" title="psa_key_attributes_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_key_attributes_t</span></code></a> object with the derived message
+encryption key’s attributes.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_output_key" title="psa_key_derivation_output_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_output_key()</span></code></a> to create the derived message key.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_output_bytes" title="psa_key_derivation_output_bytes"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_output_bytes()</span></code></a> to generate the derived IV.</li>
+<li>Call <a class="reference internal" href="../api/ops/kdf.html#c.psa_key_derivation_abort" title="psa_key_derivation_abort"><code class="xref any c c-func docutils literal"><span class="pre">psa_key_derivation_abort()</span></code></a> to release the key derivation operation
+memory.</li>
+</ol>
+</li>
+<li>Encrypt the message with the derived material.<ol class="loweralpha">
+<li>Initialize a <a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_operation_t" title="psa_cipher_operation_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_cipher_operation_t</span></code></a> object to zero or to
+<a class="reference internal" href="../api/ops/ciphers.html#c.PSA_CIPHER_OPERATION_INIT" title="PSA_CIPHER_OPERATION_INIT"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_CIPHER_OPERATION_INIT</span></code></a>.</li>
+<li>Call <a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_encrypt_setup" title="psa_cipher_encrypt_setup"><code class="xref any c c-func docutils literal"><span class="pre">psa_cipher_encrypt_setup()</span></code></a> with the derived message encryption key.</li>
+<li>Call <a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_set_iv" title="psa_cipher_set_iv"><code class="xref any c c-func docutils literal"><span class="pre">psa_cipher_set_iv()</span></code></a> using the derived IV retrieved above.</li>
+<li>Call <a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_update" title="psa_cipher_update"><code class="xref any c c-func docutils literal"><span class="pre">psa_cipher_update()</span></code></a> one or more times to encrypt the message.</li>
+<li>Call <a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_finish" title="psa_cipher_finish"><code class="xref any c c-func docutils literal"><span class="pre">psa_cipher_finish()</span></code></a> at the end of the message.</li>
+</ol>
+</li>
+<li>Call <a class="reference internal" href="../api/keys/management.html#c.psa_destroy_key" title="psa_destroy_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_destroy_key()</span></code></a> to clear the generated key.</li>
+</ol>
+</div>
+</div>
+<div class="section" id="asymmetric-cryptography">
+<h2>3.4. Asymmetric cryptography</h2>
+<p>This specification defines interfaces for the following types of asymmetric cryptographic operation:</p>
+<ul class="simple">
+<li>Asymmetric encryption (also known as public key encryption). See <a class="reference internal" href="../api/ops/pke.html#pke"><span class="secref">Asymmetric encryption</span></a>.</li>
+<li>Asymmetric signature. See <a class="reference internal" href="../api/ops/sign.html#sign"><span class="secref">Asymmetric signature</span></a>.</li>
+<li>Two-way key agreement (also known as key establishment). See <a class="reference internal" href="../api/ops/ka.html#key-agreement"><span class="secref">Key agreement</span></a>.</li>
+</ul>
+<p>For asymmetric encryption and signature, the API provides <em>single-part</em> functions. For key agreement, the API provides a single-part function and an additional input method for a key derivation operation.</p>
+</div>
+<div class="section" id="randomness-and-key-generation">
+<h2>3.5. Randomness and key generation</h2>
+<p>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.</p>
+<p>It is recommended that applications use <a class="reference internal" href="../api/keys/management.html#c.psa_generate_key" title="psa_generate_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_generate_key()</span></code></a>,
+<a class="reference internal" href="../api/ops/ciphers.html#c.psa_cipher_generate_iv" title="psa_cipher_generate_iv"><code class="xref any c c-func docutils literal"><span class="pre">psa_cipher_generate_iv()</span></code></a> or <a class="reference internal" href="../api/ops/aead.html#c.psa_aead_generate_nonce" title="psa_aead_generate_nonce"><code class="xref any c c-func docutils literal"><span class="pre">psa_aead_generate_nonce()</span></code></a> to generate
+suitably-formatted random data, as applicable. In addition, the API includes a
+function <a class="reference internal" href="../api/ops/rng.html#c.psa_generate_random" title="psa_generate_random"><code class="xref any c c-func docutils literal"><span class="pre">psa_generate_random()</span></code></a> to generate and extract arbitrary random data.</p>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">3. Functionality overview</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#library-management">3.1. Library management</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#key-management">3.2. Key management</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#key-types">3.2.1. Key types</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#key-identifiers">3.2.2. Key identifiers</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#key-lifetimes">3.2.3. Key lifetimes</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#key-policies">3.2.4. Key policies</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#recommendations-of-minimum-standards-for-key-management">3.2.5. Recommendations of minimum standards for key management</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#symmetric-cryptography">3.3. Symmetric cryptography</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#single-part-functions">3.3.1. Single-part Functions</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#multi-part-operations">3.3.2. Multi-part operations</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#example-of-the-symmetric-cryptography-api">3.3.3. Example of the symmetric cryptography API</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#asymmetric-cryptography">3.4. Asymmetric cryptography</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#randomness-and-key-generation">3.5. Randomness and key generation</a></li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/goals.html b/docs/1.1.0/html/overview/goals.html
new file mode 100644
index 0000000..67fb281
--- /dev/null
+++ b/docs/1.1.0/html/overview/goals.html
@@ -0,0 +1,295 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>2. Design goals &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="3. Functionality overview" href="functionality.html" />
+    <link rel="prev" title="1. Introduction" href="intro.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="design-goals">
+<span id="id1"></span><h1>2. Design goals</h1>
+<div class="section" id="suitable-for-constrained-devices">
+<span id="scalable"></span><h2>2.1. Suitable for constrained devices</h2>
+<p>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.</p>
+<ul class="simple">
+<li><em>Scalable</em>: devices only need to implement the functionality that they will
+use.</li>
+<li><em>Modular</em>: larger devices implement larger subsets of the same interface,
+rather than different interfaces.</li>
+</ul>
+<p>In this interface, all operations on unbounded amounts of data
+allow <em>multi-part</em> 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.</p>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="a-keystore-interface">
+<span id="keystore"></span><h2>2.2. A keystore interface</h2>
+<p>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.</p>
+</div>
+<div class="section" id="optional-isolation">
+<span id="isolation"></span><h2>2.3. Optional isolation</h2>
+<p>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:</p>
+<ul class="simple">
+<li>Process isolation in an operating system.</li>
+<li>Partition isolation, either with a virtual machine or a partition manager.</li>
+<li>Physical separation between devices.</li>
+</ul>
+<p>Communication between the frontend and backend is beyond the scope of this
+specification.</p>
+<p>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 <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">caller isolation</span></a>:
+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 caller isolation must
+document any implementation-specific extension of the API that enables frontend
+instances to share data in any form.</p>
+<p>An isolated implementation that only has a single frontend provides <a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">cryptoprocessor isolation</span></a>.</p>
+<p>In summary, there are three types of implementation:</p>
+<ul class="simple">
+<li><a class="reference internal" href="../about.html#term-no-isolation"><span class="term">No isolation</span></a>: 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.</li>
+<li><a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">Cryptoprocessor isolation</span></a>: 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.</li>
+<li><a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">Caller isolation</span></a>: 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.</li>
+</ul>
+</div>
+<div class="section" id="choice-of-algorithms">
+<span id="algorithm-agility"></span><h2>2.4. Choice of algorithms</h2>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="ease-of-use">
+<span id="usability"></span><h2>2.5. Ease of use</h2>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="example-use-cases">
+<h2>2.6. Example use cases</h2>
+<p>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.</p>
+<div class="section" id="network-security-tls">
+<h3>2.6.1. Network Security (TLS)</h3>
+<p>The API provides all of the cryptographic primitives needed to establish TLS
+connections.</p>
+</div>
+<div class="section" id="secure-storage">
+<h3>2.6.2. Secure Storage</h3>
+<p>The API provides all primitives related to storage encryption, block or
+file-based, with master encryption keys stored inside a key store.</p>
+</div>
+<div class="section" id="network-credentials">
+<h3>2.6.3. Network Credentials</h3>
+<p>The API provides network credential management inside a key store, for example,
+for X.509-based authentication or pre-shared keys on enterprise networks.</p>
+</div>
+<div class="section" id="device-pairing">
+<h3>2.6.4. Device Pairing</h3>
+<p>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.</p>
+</div>
+<div class="section" id="secure-boot">
+<h3>2.6.5. Secure Boot</h3>
+<p>The API provides primitives for use during firmware integrity and authenticity
+validation, during a secure or trusted boot process.</p>
+</div>
+<div class="section" id="attestation">
+<h3>2.6.6. Attestation</h3>
+<p>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.</p>
+</div>
+<div class="section" id="factory-provisioning">
+<h3>2.6.7. Factory Provisioning</h3>
+<p>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.</p>
+</div>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">2. Design goals</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#suitable-for-constrained-devices">2.1. Suitable for constrained devices</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#a-keystore-interface">2.2. A keystore interface</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#optional-isolation">2.3. Optional isolation</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#choice-of-algorithms">2.4. Choice of algorithms</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#ease-of-use">2.5. Ease of use</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#example-use-cases">2.6. Example use cases</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#network-security-tls">2.6.1. Network Security (TLS)</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#secure-storage">2.6.2. Secure Storage</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#network-credentials">2.6.3. Network Credentials</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#device-pairing">2.6.4. Device Pairing</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#secure-boot">2.6.5. Secure Boot</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#attestation">2.6.6. Attestation</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#factory-provisioning">2.6.7. Factory Provisioning</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/implementation.html b/docs/1.1.0/html/overview/implementation.html
new file mode 100644
index 0000000..61d40b1
--- /dev/null
+++ b/docs/1.1.0/html/overview/implementation.html
@@ -0,0 +1,376 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>6. Implementation considerations &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="7. Usage considerations" href="usage.html" />
+    <link rel="prev" title="5. Library conventions" href="conventions.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="implementation-considerations">
+<span id="id1"></span><h1>6. Implementation considerations</h1>
+<div class="section" id="implementation-specific-aspects-of-the-interface">
+<h2>6.1. Implementation-specific aspects of the interface</h2>
+<div class="section" id="implementation-profile">
+<h3>6.1.1. Implementation profile</h3>
+<p>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.</p>
+</div>
+<div class="section" id="implementation-specific-types">
+<span id="implementation-defined-type"></span><h3>6.1.2. Implementation-specific types</h3>
+<p>This specification defines a number of implementation-specific types, which
+represent objects whose content depends on the implementation. These are defined
+as C <code class="docutils literal"><span class="pre">typedef</span></code> types in this specification, with a comment
+<em><a class="reference internal" href="#implementation-defined-type"><span class="std std-ref">/* implementation-defined type */</span></a></em> in place of the underlying type
+definition. For some types the specification constrains the type, for example,
+by requiring that the type is a <code class="docutils literal"><span class="pre">struct</span></code>, or that it is convertible to and
+from an unsigned integer. In the implementation’s version of <code class="file docutils literal"><span class="pre">psa/crypto.h</span></code>,
+these types need to be defined as complete C types so that objects of these
+types can be instantiated by application code.</p>
+<p>Applications that rely on the implementation specific definition of any of these
+types might not be portable to other implementations of this specification.</p>
+</div>
+<div class="section" id="implementation-specific-macros">
+<span id="implementation-specific-macro"></span><h3>6.1.3. Implementation-specific macros</h3>
+<p>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.</p>
+<p>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:</p>
+<ul class="simple">
+<li>Input domains: the macro must be valid for arguments within the input domain.</li>
+<li>A return type: the macro result must be compatible with this type.</li>
+<li>Output range: the macro result must lie in the output range.</li>
+<li>Computed value: A precise mapping of valid input to output values.</li>
+</ul>
+<p>Each implementation-specific macro is in one of following categories:</p>
+<dl class="docutils" id="specification-defined-value">
+<dt><em>Specification-defined value</em></dt>
+<dd><p class="first">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.</p>
+<p>These macros are indicated in this specification using the comment
+<em><a class="reference internal" href="#specification-defined-value"><span class="std std-ref">/* specification-defined value */</span></a></em>.</p>
+<p>For function-like macros with specification-defined values:</p>
+<ul class="last simple">
+<li>Example implementations are provided in an appendix to this specification.
+See <a class="reference internal" href="../appendix/specdef_values.html#appendix-specdef-values"><span class="secref">Example macro implementations</span></a>.</li>
+<li>The expected computation for valid and supported input arguments will be
+defined as pseudo-code in a future version of this specification.</li>
+</ul>
+</dd>
+</dl>
+<dl class="docutils" id="implementation-defined-value">
+<dt><em>Implementation-defined value</em></dt>
+<dd><p class="first">The value of the macro expression is implementation-defined.</p>
+<p>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.</p>
+<p class="last">These macros are indicated in this specification using the comment
+<em><a class="reference internal" href="#implementation-defined-value"><span class="std std-ref">/* implementation-defined value */</span></a></em>.</p>
+</dd>
+</dl>
+<p>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.</p>
+<p>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.</p>
+</div>
+</div>
+<div class="section" id="porting-to-a-platform">
+<h2>6.2. Porting to a platform</h2>
+<div class="section" id="platform-assumptions">
+<h3>6.2.1. Platform assumptions</h3>
+<p>This specification is designed for a C99 platform. The interface is defined in
+terms of C macros, functions and objects.</p>
+<p>The specification assumes 8-bit bytes, and “byte” and “octet” are used
+synonymously.</p>
+</div>
+<div class="section" id="platform-specific-types">
+<h3>6.2.2. Platform-specific types</h3>
+<p>The specification makes use of some types defined in C99. These types must be
+defined in the implementation version of <code class="file docutils literal"><span class="pre">psa/crypto.h</span></code> or by a header
+included in this file. The following C99 types are used:</p>
+<dl class="docutils">
+<dt><code class="docutils literal"><span class="pre">uint8_t</span></code>, <code class="docutils literal"><span class="pre">uint16_t</span></code>, <code class="docutils literal"><span class="pre">uint32_t</span></code></dt>
+<dd>Unsigned integer types with 8, 16 and 32 value bits respectively.
+These types are defined by the C99 header <code class="file docutils literal"><span class="pre">stdint.h</span></code>.</dd>
+</dl>
+</div>
+<div class="section" id="cryptographic-hardware-support">
+<h3>6.2.3. Cryptographic hardware support</h3>
+<p>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.</p>
+</div>
+</div>
+<div class="section" id="security-requirements-and-recommendations">
+<h2>6.3. Security requirements and recommendations</h2>
+<div class="section" id="error-detection">
+<h3>6.3.1. Error detection</h3>
+<p>Implementations that provide <a class="reference internal" href="../about.html#term-isolation"><span class="term">isolation</span></a> 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.</p>
+<p>Even implementations that do not provide isolation are recommended to detect bad
+parameters and fail-safe where possible.</p>
+</div>
+<div class="section" id="indirect-object-references">
+<h3>6.3.2. Indirect object references</h3>
+<p>Implementations can use different strategies for allocating key identifiers,
+and other types of indirect object reference.</p>
+<p>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.</p>
+<p>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:</p>
+<ul class="simple">
+<li>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.</li>
+<li>Each client has an independent identifier namespace, and the implementation
+uses a client specific identifier-to-key mapping when looking up the key.</li>
+</ul>
+<p>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.</p>
+</div>
+<div class="section" id="memory-cleanup">
+<span id="id2"></span><h3>6.3.3. Memory cleanup</h3>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="managing-key-material">
+<span id="key-material"></span><h3>6.3.4. Managing key material</h3>
+<p>In implementations that have limited volatile memory for keys, the
+implementation is permitted to store a <a class="reference internal" href="../about.html#term-volatile-key"><span class="term">volatile key</span></a> to a
+temporary location in non-volatile memory. The implementation must delete any
+non-volatile 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.</p>
+<p>Implementing the memory cleanup rule (see <a class="reference internal" href="#memory-cleanup"><span class="secref">Memory cleanup</span></a>) for a <a class="reference internal" href="../about.html#term-persistent-key"><span class="term">persistent key</span></a>
+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 <a class="reference internal" href="../api/keys/policy.html#c.PSA_KEY_USAGE_CACHE" title="PSA_KEY_USAGE_CACHE"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_KEY_USAGE_CACHE</span></code></a>
+usage flag in a key 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:</p>
+<ul class="simple">
+<li>For volatile keys or keys in a secure element with no open/close mechanism,
+this is likely to have no effect.</li>
+<li>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.</li>
+<li>For keys in a secure element with an open/close mechanism, this is a hint to
+keep the key open in the secure element.</li>
+</ul>
+<p>The application can indicate when it has finished using the key by calling
+<a class="reference internal" href="../api/keys/management.html#c.psa_purge_key" title="psa_purge_key"><code class="xref any c c-func docutils literal"><span class="pre">psa_purge_key()</span></code></a>, to request that the key material is cleaned from memory.</p>
+</div>
+<div class="section" id="safe-outputs-on-error">
+<h3>6.3.5. Safe outputs on error</h3>
+<p>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
+<a class="reference internal" href="conventions.html#stability-of-parameters"><span class="secref">Stability of parameters</span></a>.</p>
+<p>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.</p>
+</div>
+<div class="section" id="attack-resistance">
+<h3>6.3.6. Attack resistance</h3>
+<p>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.</p>
+<p>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.</p>
+</div>
+</div>
+<div class="section" id="other-implementation-considerations">
+<h2>6.4. Other implementation considerations</h2>
+<div class="section" id="philosophy-of-resource-management">
+<h3>6.4.1. Philosophy of resource management</h3>
+<p>The specification allows most functions to return
+<a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_INSUFFICIENT_MEMORY" title="PSA_ERROR_INSUFFICIENT_MEMORY"><code class="xref any c c-macro docutils literal"><span class="pre">PSA_ERROR_INSUFFICIENT_MEMORY</span></code></a>. This gives implementations the freedom to
+manage memory as they please.</p>
+<p>Alternatively, the interface is also designed for conservative strategies of
+memory management. An implementation can avoid dynamic memory allocation
+altogether by obeying certain restrictions:</p>
+<ul class="simple">
+<li>Pre-allocate memory for a predefined number of keys, each with sufficient
+memory for all key types that can be stored.</li>
+<li>For multi-part operations, in an implementation with <a class="reference internal" href="../about.html#term-no-isolation"><span class="term">no isolation</span></a>, 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.</li>
+<li>In an implementation with <a class="reference internal" href="../about.html#term-isolation"><span class="term">isolation</span></a>, pre-allocate memory for a predefined
+number of operations inside the cryptoprocessor.</li>
+</ul>
+</div>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">6. Implementation considerations</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#implementation-specific-aspects-of-the-interface">6.1. Implementation-specific aspects of the interface</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#implementation-profile">6.1.1. Implementation profile</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#implementation-specific-types">6.1.2. Implementation-specific types</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#implementation-specific-macros">6.1.3. Implementation-specific macros</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#porting-to-a-platform">6.2. Porting to a platform</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#platform-assumptions">6.2.1. Platform assumptions</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#platform-specific-types">6.2.2. Platform-specific types</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#cryptographic-hardware-support">6.2.3. Cryptographic hardware support</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#security-requirements-and-recommendations">6.3. Security requirements and recommendations</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#error-detection">6.3.1. Error detection</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#indirect-object-references">6.3.2. Indirect object references</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#memory-cleanup">6.3.3. Memory cleanup</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#managing-key-material">6.3.4. Managing key material</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#safe-outputs-on-error">6.3.5. Safe outputs on error</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#attack-resistance">6.3.6. Attack resistance</a></li>
+</ul>
+</li>
+<li class="toctree-l2"><a class="reference internal" href="#other-implementation-considerations">6.4. Other implementation considerations</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#philosophy-of-resource-management">6.4.1. Philosophy of resource management</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/intro.html b/docs/1.1.0/html/overview/intro.html
new file mode 100644
index 0000000..59fbe08
--- /dev/null
+++ b/docs/1.1.0/html/overview/intro.html
@@ -0,0 +1,136 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>1. Introduction &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="2. Design goals" href="goals.html" />
+    <link rel="prev" title="About this document" href="../about.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="introduction">
+<h1>1. Introduction</h1>
+<p>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.</p>
+<p>The PSA Cryptographic API (Crypto API) described in this document is an
+important PSA component that provides a portable interface to cryptographic operations
+on a wide range of hardware. 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.</p>
+<p>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.</p>
+<p>This document includes:</p>
+<ul class="simple">
+<li>A rationale for the design. See <a class="reference internal" href="goals.html#design-goals"><span class="secref">Design goals</span></a>.</li>
+<li>A high-level overview of the functionality provided by the interface. See <a class="reference internal" href="functionality.html#functionality-overview"><span class="secref">Functionality overview</span></a>.</li>
+<li>A description of typical architectures of implementations for this specification. See <a class="reference internal" href="sample-arch.html#architectures"><span class="secref">Sample architectures</span></a>.</li>
+<li>General considerations for implementers of this specification, and for applications that use the interface defined in this specification. See <a class="reference internal" href="implementation.html#implementation-considerations"><span class="secref">Implementation considerations</span></a> and <a class="reference internal" href="usage.html#usage-considerations"><span class="secref">Usage considerations</span></a>.</li>
+<li>A detailed definition of the API. See <a class="reference internal" href="../api/library/index.html#library-management"><span class="secref">Library management reference</span></a>, <a class="reference internal" href="../api/keys/index.html#key-management"><span class="secref">Key management reference</span></a>, and <a class="reference internal" href="../api/ops/index.html#crypto-operations"><span class="secref">Cryptographic operation reference</span></a>.</li>
+</ul>
+<p><span><em>PSA Cryptographic API 1.1 PAKE Extension</em> <a class="reference internal" href="../about.html#citation-psa-pake"><span class="cite">[PSA-PAKE]</span></a></span> is a companion document for version 1.1 of this specification. <a class="reference internal" href="../about.html#citation-psa-pake"><span class="cite">[PSA-PAKE]</span></a> defines a new API for Password Authenticated Key Establishment (PAKE) algorithms. The PAKE API is an initial proposal at BETA status. The API defined by <a class="reference internal" href="../about.html#citation-psa-pake"><span class="cite">[PSA-PAKE]</span></a> is provided in a separate specification to reflect the different status of this API, and indicate that a future version can include incompatible changes to the PAKE API. When the PAKE API is stable, it will be included in a future version of the PSA Cryptographic API specification.</p>
+<p>In future, other companion documents will define <em>profiles</em> for this specification. A profile is
+a minimum mandatory subset of the interface that a compliant implementation must
+provide.</p>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1 current"><a class="current reference internal" href="#">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/sample-arch.html b/docs/1.1.0/html/overview/sample-arch.html
new file mode 100644
index 0000000..68b4971
--- /dev/null
+++ b/docs/1.1.0/html/overview/sample-arch.html
@@ -0,0 +1,218 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>4. Sample architectures &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="5. Library conventions" href="conventions.html" />
+    <link rel="prev" title="3. Functionality overview" href="functionality.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="sample-architectures">
+<span id="architectures"></span><h1>4. Sample architectures</h1>
+<p>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.</p>
+<div class="section" id="single-partition-architecture">
+<h2>4.1. Single-partition architecture</h2>
+<p>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 <a class="reference internal" href="../about.html#term-no-isolation"><span class="term">no isolation</span></a>.</p>
+<p>This architecture does not conform to the Arm <em>Platform Security Architecture
+Security Model</em>. 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.</p>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="cryptographic-token-and-single-application-processor">
+<span id="isolated-cryptoprocessor"></span><h2>4.2. Cryptographic token and single-application processor</h2>
+<p>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
+<a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">cryptoprocessor isolation</span></a>. The cryptoprocessor has
+some non-volatile storage, a TRNG, and possibly, some cryptographic accelerators.</p>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="cryptoprocessor-with-no-key-storage">
+<h2>4.3. Cryptoprocessor with no key storage</h2>
+<p>As in the <a class="reference internal" href="#isolated-cryptoprocessor"><span class="secref">Cryptographic token and single-application processor</span></a> architecture, this system
+is also composed of two partitions separated by a security boundary and also
+provides <a class="reference internal" href="../about.html#term-cryptoprocessor-isolation"><span class="term">cryptoprocessor isolation</span></a>.
+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.</p>
+<p>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.</p>
+<p>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:</p>
+<ul class="simple">
+<li>Encrypt and authenticate data stored in the application processor.</li>
+<li>Communicate with a paired device.</li>
+<li>Allow the application to perform operations with keys that are derived from
+the hardware unique key.</li>
+</ul>
+</div>
+<div class="section" id="multi-client-cryptoprocessor">
+<h2>4.4. Multi-client cryptoprocessor</h2>
+<p>This is an expanded variant of
+<a class="reference internal" href="#isolated-cryptoprocessor"><span class="secref">Cryptographic token and single-application processor</span></a>. In this
+variant, the cryptoprocessor serves multiple applications that are mutually
+untrustworthy. This architecture provides <a class="reference internal" href="../about.html#term-caller-isolation"><span class="term">caller isolation</span></a>.</p>
+<p>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.</p>
+</div>
+<div class="section" id="multi-cryptoprocessor-architecture">
+<h2>4.5. Multi-cryptoprocessor architecture</h2>
+<p>This system includes multiple cryptoprocessors. There are several reasons to
+have multiple cryptoprocessors:</p>
+<ul class="simple">
+<li>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.</li>
+<li>Independent provisioning of certain secrets.</li>
+<li>A combination of a non-removable cryptoprocessor and removable ones, for
+example, a smartcard or HSM.</li>
+<li>Cryptoprocessors managed by different stakeholders who do not trust each
+other.</li>
+</ul>
+<p>The keystore implementation needs to dispatch each request to the correct
+processor. For example:</p>
+<ul class="simple">
+<li>All requests involving a non-extractable key must be processed in the
+cryptoprocessor that holds that key.</li>
+<li>Requests involving a persistent key must be processed in the cryptoprocessor
+that corresponds to the key’s lifetime value.</li>
+<li>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.</li>
+</ul>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">4. Sample architectures</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#single-partition-architecture">4.1. Single-partition architecture</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#cryptographic-token-and-single-application-processor">4.2. Cryptographic token and single-application processor</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#cryptoprocessor-with-no-key-storage">4.3. Cryptoprocessor with no key storage</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#multi-client-cryptoprocessor">4.4. Multi-client cryptoprocessor</a></li>
+<li class="toctree-l2"><a class="reference internal" href="#multi-cryptoprocessor-architecture">4.5. Multi-cryptoprocessor architecture</a></li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file
diff --git a/docs/1.1.0/html/overview/usage.html b/docs/1.1.0/html/overview/usage.html
new file mode 100644
index 0000000..f2d8d5b
--- /dev/null
+++ b/docs/1.1.0/html/overview/usage.html
@@ -0,0 +1,177 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+  <head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>7. Usage considerations &#8212; PSA Crypto API 1.1.0 documentation</title>
+    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
+    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
+    <script type="text/javascript">
+      var DOCUMENTATION_OPTIONS = {
+        URL_ROOT:    '../',
+        VERSION:     '1.1.0',
+        COLLAPSE_INDEX: false,
+        FILE_SUFFIX: '.html',
+        HAS_SOURCE:  false,
+        SOURCELINK_SUFFIX: '.txt'
+      };
+    </script>
+    <script type="text/javascript" src="../_static/jquery.js"></script>
+    <script type="text/javascript" src="../_static/underscore.js"></script>
+    <script type="text/javascript" src="../_static/doctools.js"></script>
+    <link rel="author" title="About these documents" href="../about.html" />
+    <link rel="index" title="Index" href="../genindex.html" />
+    <link rel="search" title="Search" href="../search.html" />
+    <link rel="next" title="8. Library management reference" href="../api/library/index.html" />
+    <link rel="prev" title="6. Implementation considerations" href="implementation.html" />
+   
+  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
+  
+  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
+
+  </head>
+  <body>
+  
+
+    <div class="document">
+      <div class="documentwrapper">
+        <div class="bodywrapper">
+          <div class="body" role="main">
+            
+  <div class="section" id="usage-considerations">
+<span id="id1"></span><h1>7. Usage considerations</h1>
+<div class="section" id="security-recommendations">
+<h2>7.1. Security recommendations</h2>
+<div class="section" id="always-check-for-errors">
+<h3>7.1.1. Always check for errors</h3>
+<p>Most functions in this API can return errors. All functions that can fail have
+the return type <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal"><span class="pre">psa_status_t</span></code></a>. A few functions cannot fail, and thus, return
+<code class="docutils literal"><span class="pre">void</span></code> or some other type.</p>
+<p>If an error occurs, unless otherwise specified, the content of the output
+parameters is undefined and must not be used.</p>
+<p>Some common causes of errors include:</p>
+<ul class="simple">
+<li>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.</li>
+<li>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.</li>
+<li>Most functions might fail due to a lack of resources. However, some
+implementations guarantee that certain functions always have sufficient
+memory.</li>
+<li>All functions that access persistent keys might fail due to a storage failure.</li>
+<li>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 <a class="reference internal" href="../api/library/library.html#c.psa_crypto_init" title="psa_crypto_init"><code class="xref any c c-func docutils literal"><span class="pre">psa_crypto_init()</span></code></a>. However, some security
+standards require periodic reseeding from a hardware random generator, which
+can fail.</li>
+</ul>
+</div>
+<div class="section" id="shared-memory-and-concurrency">
+<h3>7.1.2. Shared memory and concurrency</h3>
+<p>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.</p>
+<p>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 <a class="reference internal" href="conventions.html#concurrency"><span class="secref">Concurrent calls</span></a>.</p>
+<p>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 <a class="reference internal" href="conventions.html#stability-of-parameters"><span class="secref">Stability of parameters</span></a>.</p>
+</div>
+<div class="section" id="cleaning-up-after-use">
+<h3>7.1.3. Cleaning up after use</h3>
+<p>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.</p>
+<p>Wiping sensitive data includes:</p>
+<ul class="simple">
+<li>Clearing temporary buffers in the stack or on the heap.</li>
+<li>Aborting operations if they will not be finished.</li>
+<li>Destroying keys that are no longer used.</li>
+</ul>
+</div>
+</div>
+</div>
+
+
+          </div>
+        </div>
+      </div>
+      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
+        <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
+IHI 0086<br/>
+Non-confidential<br/>
+Version 1.1.0
+<span style="color: red; font-weight: bold;"></span>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
+</ul>
+<ul class="current">
+<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
+<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
+<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
+<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
+<li class="toctree-l1"><a class="reference internal" href="conventions.html">5. Library conventions</a></li>
+<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
+<li class="toctree-l1 current"><a class="current reference internal" href="#">7. Usage considerations</a><ul>
+<li class="toctree-l2"><a class="reference internal" href="#security-recommendations">7.1. Security recommendations</a><ul>
+<li class="toctree-l3"><a class="reference internal" href="#always-check-for-errors">7.1.1. Always check for errors</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#shared-memory-and-concurrency">7.1.2. Shared memory and concurrency</a></li>
+<li class="toctree-l3"><a class="reference internal" href="#cleaning-up-after-use">7.1.3. Cleaning up after use</a></li>
+</ul>
+</li>
+</ul>
+</li>
+<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/encodings.html">Algorithm and key type encoding</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/sra.html">Security Risk Assessment</a></li>
+<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
+</ul>
+<ul>
+<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
+</ul>
+<div id="searchbox" style="display: none" role="search">
+  <h3>Quick search</h3>
+    <form class="search" action="../search.html" method="get">
+      <div><input type="text" name="q" /></div>
+      <div><input type="submit" value="Go" /></div>
+      <input type="hidden" name="check_keywords" value="yes" />
+      <input type="hidden" name="area" value="default" />
+    </form>
+</div>
+<script type="text/javascript">$('#searchbox').show(0);</script>
+        </div>
+      </div>
+      <div class="clearer"></div>
+    </div>
+    <div class="footer">
+      &copy; 2018-2022, Arm Limited or its affiliates. All rights reserved.
+      
+      |
+      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.6.7</a>
+      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.8</a>
+      
+    </div>
+
+    
+
+    
+  </body>
+</html>
\ No newline at end of file