Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EC J-PAKE driver dispatch implementation v.2 #6567

Merged
merged 75 commits into from
Mar 9, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
75 commits
Select commit Hold shift + click to select a range
56b8d23
Add mbedtls_ prefix to PSA PAKE over MbedTLS implementation
superna9999 Jun 1, 2022
7da8c56
Add PSA PAKE wrappers
superna9999 Jun 1, 2022
a7d08c3
Add PSA PAKE api calling the PAKE wrappers
superna9999 Jun 1, 2022
5ae6096
Move the common parameters check code out of the wrapper
superna9999 Sep 15, 2022
2e73649
Add pake psa crypto driver wrappers implementation
mprse Nov 22, 2022
d3da040
Add test driver impl for pake
mprse Nov 22, 2022
0379002
Add test components to test accelerated pake and fallback
mprse Nov 22, 2022
d91bcb7
Refactor structures for pake driver support
mprse Nov 22, 2022
6c76441
Adapt pake impl for driver dispatch
mprse Nov 22, 2022
6a9785f
Add pake.h to test driver header
mprse Nov 22, 2022
061a016
Add ALG_TLS12_PRF, TLS12_PSK_TO_MS, LG_TLS12_ECJPAKE_TO_PMS support t…
mprse Nov 22, 2022
7658a07
Add pake driver wrapper tests
mprse Nov 22, 2022
4f0035b
Add guards for buildin pake set_password function
mprse Nov 23, 2022
0c78180
mbedtls_psa_pake_get_implicit_key: move psa_key_derivation_input_byte…
mprse Nov 29, 2022
061f694
Make psa_get_and_lock_key_slot_with_policy() static function
mprse Nov 30, 2022
e5e41eb
Remove redundant line (fix rebase error)
mprse Dec 1, 2022
51eac53
Divide pake operation into two phases collecting inputs and computation.
mprse Dec 7, 2022
96ae8b9
Move pake definitions to headers for composite algorithms
mprse Dec 7, 2022
ca67483
psa_crypto_pake.h: adapt function descriptions
mprse Dec 7, 2022
c6b9546
Adapt test_suite_psa_crypto_pake test for the new design
mprse Dec 8, 2022
95629ab
Add forced status for pake setup
mprse Dec 14, 2022
3f9dbac
Adapt ake driver tests to the new design
mprse Dec 14, 2022
be5e27b
Remove redundant code
mprse Dec 14, 2022
e12ed36
Move JPAKE state machine logic from driver to core
mprse Dec 21, 2022
2797d37
Split handling of memory allocation for password between core and driver
mprse Dec 22, 2022
fcd70e2
Adapt pake driver wrapper tests for the new design
mprse Dec 22, 2022
9a5b812
Cleanup the code
mprse Dec 22, 2022
d6eb110
Add draft documentation for the PAKE driver dispatch logic
mprse Dec 29, 2022
5798003
Add enum that presents computation stage as single value
mprse Jan 9, 2023
d67a5b6
Update PAKE driver documentation (v.2)
mprse Jan 11, 2023
8c8ab26
Update documentation (handling inputs, function names)
mprse Jan 16, 2023
b09c487
Combine core pake computation stage(step,sequence,state) into single …
mprse Jan 17, 2023
7b73017
Simplify psa_pake_computation_stage_s structure
mprse Jan 17, 2023
0f50f68
Remove redundant dummy fields inside unions
mprse Jan 17, 2023
ca8d2b2
Add get-data functions for inputs + tests
mprse Jan 17, 2023
18620a3
Make copy of inputs on stack before passing to psa_driver_wrapper_pak…
mprse Jan 17, 2023
5cbca79
Make usage of pake input getters
mprse Jan 17, 2023
33ea63d
Minor updates of the documentation
mprse Jan 18, 2023
38b4e17
Remove typedef for enum
mprse Jan 18, 2023
27cd488
Update the documentation (v.3)
mprse Jan 25, 2023
dde6a91
Optimize out psa_pake_computation_stage_t
mprse Jan 26, 2023
ff01bc4
Remove j-pake specific checks from psa_pake_setup
mprse Jan 26, 2023
1c3cfb4
Introduce PSA_PAKE_OPERATION_STAGE_SETUP to optimize out alg checks
mprse Jan 26, 2023
d5d28a2
Use operation alg for locking key slot
mprse Jan 26, 2023
9dd2440
Change pake input: key_lifetime -> key attributes
mprse Jan 26, 2023
ac067d7
Fix PSA_PAKE_OPERATION_INIT macro
mprse Jan 26, 2023
f62b3bb
Optimization of pake core functions
mprse Jan 31, 2023
d69dca9
Rework psa_pake_abort
mprse Jan 31, 2023
a48cf50
mbedtls_test_transparent_pake_abort: call driver/build-in impl even w…
mprse Jan 31, 2023
3e784d8
PSA crypto pake: call abort on each failure
mprse Feb 8, 2023
e1d51bf
Optimieze psa_pake_complete_inputs()
mprse Feb 14, 2023
849c35f
Remove pake abort on failure from driver (handled by core)
mprse Feb 14, 2023
4fcc61e
Optimize psa_pake_ecjpake_setup()
mprse Feb 14, 2023
dff21d3
Move jpake role check to psa_pake_complete_inputs()
mprse Feb 14, 2023
6d77830
Remove redundant code
mprse Feb 14, 2023
b45b8ce
Disable MBEDTLS_PSA_CRYPTO_SE_C is hash psa builds
mprse Feb 15, 2023
251e86a
Adapt names to more suitable and fix conditional compilation flags
mprse Feb 17, 2023
6b64862
Documentation fixes and code adaptation
mprse Feb 19, 2023
a54dc69
mbedtls_psa_pake_setup: move driver password and alg init to the comm…
mprse Feb 20, 2023
80a8849
Adapt conditional compilation flags for jpake alg
mprse Feb 20, 2023
ce131bf
PAKE driver: fix password releasing
mprse Feb 21, 2023
51a677b
Remove support for pake opaque driver
mprse Feb 21, 2023
5eff103
Remove redundant checks for jpake alg
mprse Feb 21, 2023
d59d2a4
Optimize pake tests
mprse Feb 22, 2023
bdc21e6
Disable MBEDTLS_PSA_CRYPTO_SE_C is ecdsa psa builds
mprse Feb 23, 2023
083745e
Fix code style
mprse Feb 23, 2023
d93de32
Move to computation stage only on successfull setup
mprse Feb 24, 2023
6f2d1f4
Further pake tests optimizations
mprse Feb 24, 2023
f5dcb88
Rework pake input getters tests
mprse Feb 27, 2023
e3ef3a1
Further pake code optimizations
mprse Feb 27, 2023
4dc83d4
Add check for pake operation buffer overflow
mprse Feb 27, 2023
4aa9940
Fix configuration for accelerated jpake
mprse Feb 27, 2023
57580f2
Use proper enum types for pake state/sequence/step
mprse Mar 1, 2023
691e91a
Further pake code optimizations
mprse Mar 7, 2023
b8eaf63
Remove MBEDTLS_SHA256_C from PSA_WANT_ALG_JPAKE config and adapt test…
mprse Mar 8, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
153 changes: 153 additions & 0 deletions docs/proposed/psa-driver-interface.md
Original file line number Diff line number Diff line change
Expand Up @@ -321,6 +321,159 @@ TODO: key input and output for opaque drivers; deterministic key generation for

TODO

### Driver entry points for PAKE

A PAKE operation is divided into two stages: collecting inputs and computation. Core side is responsible for keeping inputs and core set-data functions do not have driver entry points. Collected inputs are available for drivers via get-data functions for `password`, `role` and `cipher_suite`.

### PAKE driver dispatch logic
The core decides whether to dispatch a PAKE operation to a driver based on the location of the provided password.
When all inputs are collected and `"psa_pake_output"` or `"psa_pake_input"` is called for the first time `"pake_setup"` driver entry point is invoked.

1. If the location of the `password` is the local storage
- if there is a transparent driver for the specified ciphersuite, the core calls that driver's `"pake_setup"` and subsequent entry points.
- otherwise, or on fallback, the core uses its built-in implementation.
2. If the location of the `password` is the location of a secure element
- the core calls the `"pake_setup"` entry point of the secure element driver and subsequent entry points.

### Summary of entry points for PAKE

A PAKE driver has the following entry points:
* `"pake_setup"` (mandatory): always the first entry point to be called. It is called when all inputs are collected and the computation stage starts.
* `"pake_output"` (mandatory): derive cryptographic material for the specified step and output it.
* `"pake_input"` (mandatory): provides cryptographic material in the format appropriate for the specified step.
* `"pake_get_implicit_key"` (mandatory): returns implicitly confirmed shared secret from a PAKE.
* `"pake_abort"` (mandatory): always the last entry point to be called.

For naming purposes, here and in the following subsection, this specification takes the example of a driver with the prefix `"acme"` that implements the PAKE entry point family with a capability that does not use the `"names"` property to declare different type and entry point names. Such a driver must implement the following type and functions, as well as the entry points listed above and described in the following subsections:
```
typedef ... acme_pake_operation_t;
psa_status_t acme_pake_abort( acme_pake_operation_t *operation );
```

#### PAKE driver inputs

The core conveys the initial inputs for a PAKE operation via an opaque data structure of type `psa_crypto_driver_pake_inputs_t`.

```
typedef ... psa_crypto_driver_pake_inputs_t; // implementation-specific type
```

A driver receiving an argument that points to a `psa_crypto_driver_pake_inputs_t` can retrieve its contents by calling one of the get-data functions below.

```
psa_status_t psa_crypto_driver_pake_get_password_len(
Copy link

@silabs-hannes silabs-hannes Jan 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's spelled out explicitly anywhere, but I'm assuming that it's allowed for an opaque driver to support multiple key locations (for example one location for volatile keys inside of the SE, and one location for wrapped keys). In that case, the driver needs to be able to figure out the location to use for the password. For other driver entry points, this is enabled by the key attributes passed alongside the key data. I'm thinking that we need to add something here such that the driver can figure out the location of the password (even though the driver likely can figure that out someway, but that feels like a less clean solution).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently core side takes only one password per operation and driver just gets key data via getter function. Probably I'm missing something, but as far as I understand for other key we need to use new operation.
If key location/lifetime of the password is really needed I can add getter function for this as core already have this information in inputs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same driver (as in, the same code) can support multiple locations, e.g. a phone with dual SIM with the driver supporting both SIM. A driver responsible for a given location is systematically responsible for multiple lifetimes, namely, all the persistence levels (e.g. volatile, stored, factory-set-and-immutable).

The generic way driver entry points for operations are formed is by taking API functions and replacing psa_key_id_t by attributes, key_buffer, key_buffer_size. So indeed psa_crypto_driver_pake_get_password should have an attributes parameter.

I made the same mistake as @mprse with psa_crypto_driver_key_derivation_get_input_keynoted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the details. Looking at location and lifetime there are the following main options:
Location: local storage/secure element
Lifetime: volatile/persistent

Now for example we have the following main combinations:

  • (local storage, volatile) indicates that the key is stored in our device volatile memory like RAM.
  • (local storage, persistent) indicates that the key is stored in our device non-volatile memory like Flash.
  • (secure element, volatile) indicates that the key is stored in external device volatile memory (not sure if this is possible).
  • (secure element, persistent) indicates that the key is stored in external device non-volatile memory.

We have separate drivers for different locations, but now information about key lifetime is missing. What I don't understand is why driver needs this information. It gets key data from core anyway and just need to use it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Secure element, volatile is possible. Not very common, but we have had requests for it. Mainly, secure elements are used to provide a higher level of security for long-term keys, and long-term keys are persistent. But using a volatile key with a secure element can be useful sometimes. In particular, it allows using the secure element as an accelerator, so the non-SE part doesn't need to support the algorithm at all. You could do the same with an accelerator driver, but if you already have the secure element driver and you're ok with tweaking your application code, you save code size by not defining an accelerator driver.

The driver needs to know the full lifetime information: the location in case the driver supports multiple location, and the persistence level so that it knows where to load/store the key data (RAM, or potentially multiple storage partitions with different persistence levels).

    const psa_crypto_driver_pake_inputs_t *inputs,
    size_t *password_len);

psa_status_t psa_crypto_driver_pake_get_password_bytes(
    const psa_crypto_driver_pake_inputs_t *inputs,
    uint8_t *buffer, size_t buffer_size, size_t *buffer_length);

psa_status_t psa_crypto_driver_pake_get_password_key(
    const psa_crypto_driver_pake_inputs_t *inputs,
    uint8_t** p_key_buffer, size_t *key_buffer_size,
const psa_key_attributes_t *attributes);

psa_status_t psa_crypto_driver_pake_get_role(
    const psa_crypto_driver_pake_inputs_t *inputs,
    psa_pake_role_t *role);

psa_status_t psa_crypto_driver_pake_get_cipher_suite(
    const psa_crypto_driver_pake_inputs_t *inputs,
    psa_pake_cipher_suite_t *cipher_suite);
```
The get-data functions take the following parameters:

The first parameter `inputs` must be a pointer passed by the core to a PAKE driver setup entry point.
Next parameters are return buffers (must not be null pointers).

These functions can return the following statuses:
* `PSA_SUCCESS`: value has been successfully obtained
* `PSA_ERROR_BAD_STATE`: the inputs are not ready
* `PSA_ERROR_BUFFER_TOO_SMALL` (`psa_crypto_driver_pake_get_password_bytes` and `psa_crypto_driver_pake_get_password_key` only): the output buffer is too small. This is not a fatal error and the driver can, for example, subsequently call the same function again with a larger buffer. Call `psa_crypto_driver_pake_get_password_len` to obtain the required size.

#### PAKE driver setup

```
psa_status_t acme_pake_setup( acme_pake_operation_t *operation,
                              const psa_crypto_driver_pake_inputs_t *inputs );
```

* `operation` is a zero-initialized operation object.
* `inputs` is an opaque pointer to the [inputs](#pake-driver-inputs) for the PAKE operation.

The setup driver function should preserve the inputs using get-data functions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather, something like:

The pointer output by psa_crypto_driver_pake_get_password_key is only valid until the "pake_setup" entry point returns. Opaque drivers must copy all relevant data from the key buffer during the "pake_setup" entry point and must not store the pointer itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this is only about password_key? All inputs need to be preserved and will be not available after return from "pake_setup" entry point.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For other inputs, the interface requires a data buffer belonging to the driver. But get_key passes a pointer to memory belonging to the core. The difference is because key data is typically small and in a format that the driver knows well, whereas byte data can be large and unformatted so may need to be copied or processed in chunks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From PSA drivers: specification for key derivation:

On a successful invocation of psa_crypto_driver_key_derivation_get_input_key, the core sets *key_buffer to a pointer to a buffer containing the key context and *key_buffer_size to the size of the key context in bytes. The key context buffer remains valid for the duration of the driver entry point. If the driver needs to access the key context after the current entry point returns, it must make a copy of the key context.

I think that both notes are needed.

  1. Pointer to inputs also points to memory belonging to the core and these inputs needs to be preserved.
  2. Additionally psa_crypto_driver_key_derivation_get_input_key returns pointer to key buffer on core side and key data also needs to be preserved for further usage.


The pointer output by `psa_crypto_driver_pake_get_password_key` is only valid until the "pake_setup" entry point returns. Opaque drivers must copy all relevant data from the key buffer during the "pake_setup" entry point and must not store the pointer itself.

#### PAKE driver output

```
psa_status_t acme_pake_output(acme_pake_operation_t *operation,
                              psa_crypto_driver_pake_step_t step,
                              uint8_t *output,
                              size_t output_size,
                              size_t *output_length);
```

* `operation` is an operation object.
* `step` computation step based on which driver should perform an action.
* `output` buffer where the output is to be written.
* `output_size` size of the output buffer in bytes.
* `output_length` the number of bytes of the returned output.

For `PSA_ALG_JPAKE` the following steps are available for output operation:
`step` can be one of the following values:
* `PSA_JPAKE_X1_STEP_KEY_SHARE`     Round 1: output our key share (for ephemeral private key X1)
* `PSA_JPAKE_X1_STEP_ZK_PUBLIC`     Round 1: output Schnorr NIZKP public key for the X1 key
* `PSA_JPAKE_X1_STEP_ZK_PROOF`      Round 1: output Schnorr NIZKP proof for the X1 key
* `PSA_JPAKE_X2_STEP_KEY_SHARE`     Round 1: output our key share (for ephemeral private key X2)
* `PSA_JPAKE_X2_STEP_ZK_PUBLIC`     Round 1: output Schnorr NIZKP public key for the X2 key
* `PSA_JPAKE_X2_STEP_ZK_PROOF`      Round 1: output Schnorr NIZKP proof for the X2 key
* `PSA_JPAKE_X2S_STEP_KEY_SHARE`    Round 2: output our X2S key
* `PSA_JPAKE_X2S_STEP_ZK_PUBLIC`    Round 2: output Schnorr NIZKP public key for the X2S key
* `PSA_JPAKE_X2S_STEP_ZK_PROOF`     Round 2: output Schnorr NIZKP proof for the X2S key

#### PAKE driver input
```
psa_status_t acme_pake_input(acme_pake_operation_t *operation,
                            psa_crypto_driver_pake_step_t step,
                             uint8_t *input,
                             size_t input_size);
```

* `operation` is an operation object.
* `step` computation step based on which driver should perform an action.
* `input` buffer containing the input.
* `input_length` length of the input in bytes.

For `PSA_ALG_JPAKE` the following steps are available for input operation:
* `PSA_JPAKE_X1_STEP_KEY_SHARE`     Round 1: input key share from peer (for ephemeral private key X1)
* `PSA_JPAKE_X1_STEP_ZK_PUBLIC`     Round 1: input Schnorr NIZKP public key for the X1 key
* `PSA_JPAKE_X1_STEP_ZK_PROOF`      Round 1: input Schnorr NIZKP proof for the X1 key
* `PSA_JPAKE_X2_STEP_KEY_SHARE`     Round 1: input key share from peer (for ephemeral private key X2)
* `PSA_JPAKE_X2_STEP_ZK_PUBLIC`     Round 1: input Schnorr NIZKP public key for the X2 key
* `PSA_JPAKE_X2_STEP_ZK_PROOF`      Round 1: input Schnorr NIZKP proof for the X2 key
* `PSA_JPAKE_X4S_STEP_KEY_SHARE`    Round 2: input X4S key from peer
* `PSA_JPAKE_X4S_STEP_ZK_PUBLIC`    Round 2: input Schnorr NIZKP public key for the X4S key
* `PSA_JPAKE_X4S_STEP_ZK_PROOF`     Round 2: input Schnorr NIZKP proof for the X4S key

The core checks that input_length is smaller than PSA_PAKE_INPUT_MAX_SIZE.

### PAKE driver get implicit key

```
psa_status_t acme_pake_get_implicit_key(
                            acme_pake_operation_t *operation,
                            uint8_t *output, size_t output_size,
size_t *output_length );
```

* `operation` The driver PAKE operation object to use.
* `output` Buffer where the implicit key is to be written.
* `output_size` Size of the output buffer in bytes.
* `output_length` On success, the number of bytes of the implicit key.

### Driver entry points for key management

The driver entry points for key management differ significantly between [transparent drivers](#key-management-with-transparent-drivers) and [opaque drivers](#key-management-with-opaque-drivers). This section describes common elements. Refer to the applicable section for each driver type for more information.
Expand Down
2 changes: 2 additions & 0 deletions include/mbedtls/config_psa.h
Original file line number Diff line number Diff line change
Expand Up @@ -147,12 +147,14 @@ extern "C" {
#endif

#if defined(PSA_WANT_ALG_JPAKE)
#if !defined(MBEDTLS_PSA_ACCEL_ALG_JPAKE)
#define MBEDTLS_PSA_BUILTIN_PAKE 1
#define MBEDTLS_PSA_BUILTIN_ALG_JPAKE 1
#define MBEDTLS_ECP_DP_SECP256R1_ENABLED
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_ECP_C
#define MBEDTLS_ECJPAKE_C
#endif /* MBEDTLS_PSA_ACCEL_ALG_JPAKE */
#endif /* PSA_WANT_ALG_JPAKE */

#if defined(PSA_WANT_ALG_RIPEMD160) && !defined(MBEDTLS_PSA_ACCEL_ALG_RIPEMD160)
Expand Down
35 changes: 35 additions & 0 deletions include/psa/crypto_builtin_composites.h
Original file line number Diff line number Diff line change
Expand Up @@ -180,5 +180,40 @@ typedef struct {
#endif


/* EC-JPAKE operation definitions */

#include "mbedtls/ecjpake.h"

#if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE)
#define MBEDTLS_PSA_BUILTIN_PAKE 1
#endif

/* Note: the format for mbedtls_ecjpake_read/write function has an extra
* length byte for each step, plus an extra 3 bytes for ECParameters in the
* server's 2nd round. */
#define MBEDTLS_PSA_JPAKE_BUFFER_SIZE ((3 + 1 + 65 + 1 + 65 + 1 + 32) * 2)

typedef struct {
psa_algorithm_t MBEDTLS_PRIVATE(alg);

uint8_t *MBEDTLS_PRIVATE(password);
size_t MBEDTLS_PRIVATE(password_len);
#if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE)
uint8_t MBEDTLS_PRIVATE(role);
uint8_t MBEDTLS_PRIVATE(buffer[MBEDTLS_PSA_JPAKE_BUFFER_SIZE]);
size_t MBEDTLS_PRIVATE(buffer_length);
size_t MBEDTLS_PRIVATE(buffer_offset);
#endif
/* Context structure for the Mbed TLS EC-JPAKE implementation. */
union {
unsigned int MBEDTLS_PRIVATE(dummy);
#if defined(MBEDTLS_PSA_BUILTIN_ALG_JPAKE)
mbedtls_ecjpake_context MBEDTLS_PRIVATE(jpake);
#endif
} MBEDTLS_PRIVATE(ctx);

} mbedtls_psa_pake_operation_t;

#define MBEDTLS_PSA_PAKE_OPERATION_INIT { { 0 } }

#endif /* PSA_CRYPTO_BUILTIN_COMPOSITES_H */
35 changes: 35 additions & 0 deletions include/psa/crypto_driver_contexts_composites.h
Original file line number Diff line number Diff line change
Expand Up @@ -88,6 +88,32 @@ typedef mbedtls_psa_aead_operation_t

#endif /* MBEDTLS_TEST_LIBTESTDRIVER1 && LIBTESTDRIVER1_MBEDTLS_PSA_BUILTIN_AEAD */

#if defined(MBEDTLS_TEST_LIBTESTDRIVER1) && \
defined(LIBTESTDRIVER1_MBEDTLS_PSA_BUILTIN_PAKE)

typedef libtestdriver1_mbedtls_psa_pake_operation_t
mbedtls_transparent_test_driver_pake_operation_t;
typedef libtestdriver1_mbedtls_psa_pake_operation_t
mbedtls_opaque_test_driver_pake_operation_t;

#define MBEDTLS_TRANSPARENT_TEST_DRIVER_PAKE_OPERATION_INIT \
LIBTESTDRIVER1_MBEDTLS_PSA_PAKE_OPERATION_INIT
#define MBEDTLS_OPAQUE_TEST_DRIVER_PAKE_OPERATION_INIT \
LIBTESTDRIVER1_MBEDTLS_PSA_PAKE_OPERATION_INIT

#else
typedef mbedtls_psa_pake_operation_t
mbedtls_transparent_test_driver_pake_operation_t;
typedef mbedtls_psa_pake_operation_t
mbedtls_opaque_test_driver_pake_operation_t;

#define MBEDTLS_TRANSPARENT_TEST_DRIVER_PAKE_OPERATION_INIT \
MBEDTLS_PSA_PAKE_OPERATION_INIT
#define MBEDTLS_OPAQUE_TEST_DRIVER_PAKE_OPERATION_INIT \
MBEDTLS_PSA_PAKE_OPERATION_INIT

#endif /* MBEDTLS_TEST_LIBTESTDRIVER1 && LIBTESTDRIVER1_MBEDTLS_PSA_BUILTIN_PAKE */

#endif /* PSA_CRYPTO_DRIVER_TEST */

/* Define the context to be used for an operation that is executed through the
Expand Down Expand Up @@ -124,5 +150,14 @@ typedef union {
mbedtls_psa_verify_hash_interruptible_operation_t mbedtls_ctx;
} psa_driver_verify_hash_interruptible_context_t;

typedef union {
unsigned dummy; /* Make sure this union is always non-empty */
mbedtls_psa_pake_operation_t mbedtls_ctx;
#if defined(PSA_CRYPTO_DRIVER_TEST)
mbedtls_transparent_test_driver_pake_operation_t transparent_test_driver_ctx;
mbedtls_opaque_test_driver_pake_operation_t opaque_test_driver_ctx;
#endif
} psa_driver_pake_context_t;

#endif /* PSA_CRYPTO_DRIVER_CONTEXTS_COMPOSITES_H */
/* End of automatically generated file. */
Loading