Hi,

Thank you Gilles for the detailed reply.

Do you prefer that discussion about PSA Crypto API spec go on mailing list instead of here ? Is there some room for evolution or is the spec already in a frozen released state ?

For new algorithms, it's of course preferable that they're defined in the spec itself. But does the mbedtls project want to supports all algorithms that will be used with PSA Crypto API ?

For pure ED25519 and ED448 with scattered data, there's one big gotcha. You need to generate twice a hash that includes the message. Thus the implementation needs to be able to access the buffers of the message twice. With a piece of the message given only once as in the init-update-finish scheme, that does not work well.

From reading the document on the PSA Crypto driver API, a transparent driver benefits from the management of keys done by the mbedtls implementation. But what benefit is there for a driver working with opaque keys which has to fully handle the protections and restrictions of keys internally ?

Best,

François.

On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote:

Hello,

Thank you for your interest in the PSA crypto API.

On 28/10/2020 15:20, François Beerten via mbed-tls wrote:

...

Hi everybody,

After reading the PSA Crypto API specs (as on https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) and looking at the mbed TLS library, a few questions came up.

Is there some repository with the sources of the PSA Crypto API specs where one can follow the evolution and eventually send proposals and patches ?

The PSA specification drafts are not public. You can send feedback about the PSA Crypto application and driver interfaces on the psa-crypto mailing list (psa-crypto@lists.trustedfirmware.org, https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you prefer to send confidential feedback, you can email mbed-crypto@arm.com (feedback at this address will only be discussed inside Arm). An issue in the Mbed TLS repository will also reach PSA Crypto architects.

...

A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ?

The hash suspend/resume operations marshall the internal state of the hash operation. They mimic an existing JavaCard API (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMess...)). There is a de facto standard representation of the internal state for common Merkle-Damgård constructions, which covers all the currently defined hash algorithms except SHA3. If there's interest in this functionality, we could standardize a representation for SHA3.

...

How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ?

Answer from a PSA Crypto architect: preferably by requesting an encoding for this KDF as a PSA_ALG_xxx value (as well as new PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do that, use an encoding in the vendor range (most significant bit set).

The world of key derivation functions is unfortunately messy: there are many similar, but not functionally equivalent constructions (such as hashing a secret together with a nonce, formatted in all kinds of different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set required for the TLS protocol. We expect 1.0.x updates to define more KDF algorithms.

Answer from an Mbed TLS maintainer: contributing an implementation would be appreciated (but not required).

...

In multipart operations, can the user reuse the input buffers immediately after doing an 'update' (for example after psa_hash_update()) ? And can he reuse the input buffers immediately after some "setup" functions like psa_cipher_set_iv() or psa_aead_set_nonce() ?

Yes. PSA crypto API functions that take a buffer as a parameter never take ownership of that buffer. Once the function returns, you can do whatever you want with the buffer.

The PSA specification even guarantees that you can use the same buffer, or overlapping buffers, as inputs and outputs to the same function call. However beware that the Mbed TLS implementation does not always support such overlap (https://github.com/ARMmbed/mbedtls/issues/3266).

...

Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ?

We plan to add a multi-part message signature interface, both for the sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I expect the design to be “what you'd expect” but I haven't yet verified that there aren't any gotchas.

...

In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ?

Some applications use a fixed or deterministic salt which they check on decryption. Note that this parameter is what PKCS#1 calls “label”.

...

With PSA Crypto API, you define a flexible API for cryptographic operations. Apparently, other providers could make their own implementation of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA Crypto API implementations ? How would that work practically ?

The X.509 and TLS layer of Mbed TLS are currently designed to use the mbedtls_xxx crypto API. We have already added partial support for the psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto implementation. (I think this is already possible for a small set of cipher suites, but it isn't something that we've tried or currently actively support.) Before this can happen, some Mbed TLS APIs need to change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan to decouple the PSA crypto reference implementation (Mbed TLS's current crypto implementation) from the X.509/TLS layer (which will remain “Mbed TLS”). Our plans (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far into the future are still vague and may change.

Note that for the most common case of wanting a different implementation of cryptography, which is to leverage hardware such as accelerators and secure elements, PSA is defining a driver interface which is currently being implemented in Mbed TLS (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver...). The driver interface lets you combine mechanisms supported by your hardware with Mbed TLS's implementation for mechanisms without hardware support.