Manuel Pégourié-Gonnard

Note: if we want to remove `aes.h` and `cipher.h` from the public API in 4.0, we'll want to address this first, in order to avoid a feature regression.

For reference, there was some earlier work in this area: https://github.com/Mbed-TLS/mbedtls/pull/1549 (a continuation of https://github.com/Mbed-TLS/mbedtls/pull/479). We're closing the previous PRs and keeping this one as it's fresh and active while...

> review after release of 3.6 LTS for any other deprecations not mentioned above Note: some functions* use `MBEDTLS_DEPRECATED` but not `\deprecated` (and perhaps the other way round happens as...

The pre-.0 part has been done, and I've filed separate issues for the post-.0 parts: https://github.com/Mbed-TLS/mbedtls/issues/10429 and https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/486

Thanks for the suggestion, but I'm not sure this is a good idea, unfortunately the C type system is not really our friend here: `char **` and `const char **`...

Ok, thanks for your reply. I'm closing this, then.

@gilles-peskine-arm That's an excellent point. My point was that either way, there are situations where you'll need a cast (or a second reference with a new type); the essential difference...

Thanks for your report, and sorry for the time you lost because of this. Would you be interested in contributing a PR to fix this?

I re-discovered this semi-independently (that is, working on the same thing), and my first reaction is we should have a check in `check_config.h`. After a bit more thinking, that's still...

Well actually I think I've made up my mind about 3.6: we already have dependencies for HKDF and hashes there, and as I was saying above, ciphersuites are just as...