Hello François,
The following is my understanding, I am not a maintainer but a user of mbedtls. My response below only addresses a few of your questions.
PSA appears to be bound to what mbedtls currently supports, this does not include Ed25519 or Ed448 at this time. A pull request is currently open for this feature development https://github.com/ARMmbed/mbedtls/pull/3245 Further development may be necessary to include those in PSA.
The only implementation of PSA that I know of is one that wraps around mbedtls.
Best, Levi
On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls < mbed-tls@lists.trustedfirmware.org> 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 ?
A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ?
How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ?
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() ?
Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ?
In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ?
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 ?
Thank you for your attention,
François.
-- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Levi,
Thanks for answering some of the questions. From your answers, PSA Crypto API looks more like a wrapper around mbedtls. Isn't it intended to become a bit more than that ?
Best,
François.
On 10/28/20 3:42 PM, Levi Schuck wrote:
Hello François,
The following is my understanding, I am not a maintainer but a user of mbedtls. My response below only addresses a few of your questions.
PSA appears to be bound to what mbedtls currently supports, this does not include Ed25519 or Ed448 at this time. A pull request is currently open for this feature development https://github.com/ARMmbed/mbedtls/pull/3245 Further development may be necessary to include those in PSA.
The only implementation of PSA that I know of is one that wraps around mbedtls.
Best, Levi
On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls <mbed-tls@lists.trustedfirmware.org mailto:mbed-tls@lists.trustedfirmware.org> 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 ? A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ? How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ? 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() ? Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ? In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ? 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 ? Thank you for your attention, François. -- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org <mailto:mbed-tls@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi François,
PSA's documentation proposes it as an interface ideal for constrained environments that is resistant to common threat models. It's just that the only implementation I am aware of is embedded into and wraps around components of mbedtls.
Best, Levi
On Thu, Oct 29, 2020 at 8:20 AM François Beerten < francois.beerten@b10eng.com> wrote:
Hi Levi,
Thanks for answering some of the questions. From your answers, PSA Crypto API looks more like a wrapper around mbedtls. Isn't it intended to become a bit more than that ?
Best,
François. On 10/28/20 3:42 PM, Levi Schuck wrote:
Hello François,
The following is my understanding, I am not a maintainer but a user of mbedtls. My response below only addresses a few of your questions.
PSA appears to be bound to what mbedtls currently supports, this does not include Ed25519 or Ed448 at this time. A pull request is currently open for this feature development https://github.com/ARMmbed/mbedtls/pull/3245 Further development may be necessary to include those in PSA.
The only implementation of PSA that I know of is one that wraps around mbedtls.
Best, Levi
On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls < mbed-tls@lists.trustedfirmware.org> 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 ?
A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ?
How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ?
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() ?
Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ?
In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ?
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 ?
Thank you for your attention,
François.
-- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
mbed-tls@lists.trustedfirmware.org
-
François Beerten -
Levi Schuck