I had a few questions about mbedtls ecdh parameter exchange between a client and server and was wondering if anyone can help me out. I was able to successfully run the example ecdh_curve25519.c on my system where it generates the shared secret.
The next step is to split the example which means exchanging public keys and the parameters and then generating the shared secret.
I’m running the mbedTLS lib on a Kinetis K24 ARM Cortex-M4 chip.
In my case my hardware which has the K24 micro-controller is the Server and my Android and iOS app that connects via BLE to my hardware would be the Client
My questions:
Now that I want to split the example, which parameters does my firmware (Server side) need to give the Client (iOS/android) to the client?
How do I get those parameters from mbedTLS ecdh library? Is there any example which I can refer to?
The iOS/android app might not use mbedTLS library for ecdh. In that case, how would the handshake work? And what parameters would be sufficient for the handshake?
For an example - I’ve seen that OpenSSL writes keys in .pem files and looks like it’s Base64 encoded whereas the mbedtls library ecdh_curve25519.c example has cli_to_srv and srv_to_cli 32-byte buffers which stores the client and server public keys.
The ecdh_curve25519 was written to show how to generate the secret in the curve 25519, as it is a bit different than how we generate the secret on other curves.
If you wish to use other curves, I would suggest you look at our test functions
In this test, you will see the two contexts srv and cli. Each one simulates what needs to be called in the server and client, respectively.
Mbed TLS implements ECDH algorithm, as defined in NIST SP 800-56A. .pem format indeed is Base64 encoded, however, ar ethe keys that were written were actually the shared secret?
The shared secret that is calculated is not an asymmetric key. It is some big number (size depends on the used curve), that should be used to derive a symmetric key.
Regards,
Mbed TLS Team member
Ron
Hello all, I now this is an old thread, and if it is truly “dead”, I will create a new thread, but thought it was worth a shot here first. I appreciate any help, I am new to all this and trying to navigate it.
I have found several threads/replies on on the ECDH exchange process, and all of them are effectively:
the 25519 curve example, to which follow ups say "well, that’s not how we do it for every other curve, it’s “special”. and invariably, “for a better example, look at the tests”
Problem, the tests fail to show the key part, the actual key exchange. In the tests, the mbedtls_ecdh_context for both server and client are resident in the same code space, so some other mbedtls functions are used to “read” the peer public data. What I am after is the actual Qp coming across the communications channel as binary data stream. Then taking that value and applying to the local group to generate the share secret. the 25519 example shows that with their cli_to_srv, and srv_to_cli buffers. what is the equivalent of “reading in” those buffers in the “non-25519” curves? is it still a call to: mbedtls_mpi_read_binary() with the cli_to_srv buffer (or equivalent) holding the Qp value, or is that also a 25519 special feature?
Additionally, what does the call to mbedtls_mpi_lset just prior do. the documentation for the function only says “Set value from integer” which is effectively not documented. And what is the impact of what the Z value chose is?
Thanks. I am half way there, just need to understand how to properly “exhange” the peer public key back and forth to have both sides calculate the same shared secret.
