By the way, I have a similar question regarding mbedtls_ctr_drbg_random. I assume that I should use psa_generate_random instead, but I do not see the PSA equivalents of mbedtls_ctr_drbg_seed or mbedtls_entropy_func. Is it correct to assume that these are handled "under the hood", for example by psa_crypto_init?
-- Christian Huitema
On 9/12/2023 8:05 AM, Christian Huitema via mbed-tls wrote:
Thanks, Janos. It does help. I approached this by looking at the code, and I was confused by the presence of these three classes of API. I would obviously go for the generic API rather than the low level API, and I had no problem doing that for AEAD algorithms following the examples in `aead_demo.c`. But for the key exchange algorithm I stumbled onto `ecdh_curve25519.c`, which uses your class 2 algorithms.
I will move to the PSA Crypto API.
On 9/12/2023 1:05 AM, Janos Follath wrote:
Hi Christian,
There are three ECDH APIs in Mbed TLS:
1. One of them is using low level data structures like `mbedtls_ecp_point`, `mbedtls_mpi` and `mbedtls_ecp_group` 2. The other is operating on `mbedtls_ecdh_context` and buffers 3. The last one implements PSA Crypto API https://armmbed.github.io/mbed-crypto/html/api/ops/ka.html In Mbed TLS only the TLS 1.2 implementation uses the second option and that is why it is geared towards that. The TLS 1.3 implementation in Mbed TLS uses the PSA Crypto API and in general that is the recommended/future proof option.
I hope that helps.
Best wishes,
Janos
(Mbed TLS developer)
*From: *Christian Huitema via mbed-tls mbed-tls@lists.trustedfirmware.org *Date: *Tuesday, 12 September 2023 at 04:50 *To: *mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org *Subject: *[mbed-tls] Output format of mbedtls_ecdh_make_params does not play well with TLS 1.3
In TLS 1.3, one half of an ECDH exchange is defined as a "key entry", coded as:
struct { NamedGroup group; opaque key_exchange<1..2^16-1>; } KeyShareEntry;
The opaque data is typically encoded as a one byte format (e.g., 0x04, no compression), and then the encoding of either one or two points: 32 bytes for one point with CURVE25519, 64 bytes for two points with SECP256R1.
The encoding for the "public key" output of mbedtls_ecdh_make_params is different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points. The related encoding of the server public key output of mbedtls_ecdh_make_public is also different: 1 byte of length, followed by 2 bytes of curve ID, followed by the raw encoding of the point or points.
To make that work, I need some reformatting: strip out 3 bytes for the client public key, write a single 0x04 byte instead; strip out one byte from the key-exchange data received at the server and write 3 bytes of length and curve ID instead. Also, make sure to reset the strings to the unmodified value before calling mbedtls_ecdh_calc_secret, which probably means maintaining two copies, thus twice the memory.
This is a bit messy, and probably unnecessary. The extra parameters "length" is already passed through the API (the &olen argument) and the "group_id" could easily be passed as well.
Or maybe I am looking at the wrong API...
-- Christian Huitema
mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org