Move the inclusion of crypto_sizes.h and crypto_struct.h in crypto.h

[ronald-cron-arm]

Description

Move the inclusion of crypto_sizes.h and crypto_struct.h in crypto.h
That way when API are declared, the types they used are defined.
This should resolve the issues related to psa_xyz_init functions returning a structure described in Mbed-TLS/mbedtls#7087.

PR checklist

• changelog provided
• framework PR not required
• mbedtls development PR not required because: crypto-only change not affecting mbedtls
• mbedtls 3.6 PR provided [Backport 3.6] Move the inclusion of crypto_sizes.h and crypto_struct.h in crypto.h mbedtls#10196
• tests not required because: the change is validated by the current tests. We can't afford the effort required for non-regression testing right now. Covered by Add test to validate that headers can be used in C++ with Visual Studio mbedtls#1767.

[gilles-peskine-arm]

crypto_sizes.h uses macros from crypto_values.h, so it would make more sense to include crypto_values.h first. I don't think it actually matters for the sake of the C language, because crypto_sizes.h itself only defines macros, it doesn't expand them. But then crypto_struct.h does expand macros from crypto_sizes.h, and that can result in expanding macros from crypto_values.h. It works because crypto_struct.h (indirectly) includes crypto_driver_common.h which includes crypto_values.h. But it would make more sense to include crypto_values.h at the logical place in crypto.h.

[ronald-cron-arm]

Right, I missed that, thanks. I've changed it and while at it I've tried to fix the similar issues in crypto_extra.h pointed to by #7087.

[gilles-peskine-arm]

LGTM for the code change. I don't know if it actually fixes Mbed-TLS/mbedtls#7087, but at worst it's harmless.

If this does fix Mbed-TLS/mbedtls#7087 then we need a changelog entry, and preferably a non-regression test (which would resolve Mbed-TLS/mbedtls#1767).

[gilles-peskine-arm]

We have a report that this does fix 7087. Can you please add a changelog entry and make a backport to 3.6?

[aslze]

We have a report that this does fix 7087. Can you please add a changelog entry and make a backport to 3.6?

Can confirm. I had the same issue and just replacing "crypto_extra.h" and "crypto.h" in version 3.6.3 fixed it.

[irwir]

@ronald-cron-arm
Since you already rearranging declarations, would it be possible to improve consistency as requested in the issue #7841?

[irwir]

Rolling back changes in crypto_extra.h gives errors at the lines:

static psa_pake_cipher_suite_t psa_pake_cipher_suite_init(void);
static psa_pake_operation_t psa_pake_operation_init(void);

No other lines in the file are using these forward declarations; hence both lines could be safely deleted.
The corresponding definitions at the bottom of the file could be changed as suggested in my previous message:

/** Return an initial value for a PAKE cipher suite object.
 */
static inline psa_pake_cipher_suite_t psa_pake_cipher_suite_init(void)
{
    const psa_pake_cipher_suite_t v = PSA_PAKE_CIPHER_SUITE_INIT;
    return v;
}

/** Return an initial value for a PAKE operation object.
 */
static inline psa_pake_operation_t psa_pake_operation_init(void)
{
    const psa_pake_operation_t v = PSA_PAKE_OPERATION_INIT;
    return v;
}

This compiles and builds successfully.

[ronald-cron-arm]

I've removed the changes related to crypto_extra.h as they are going to be done in #258.

[irwir]

Apparentely, there is no need for any extensive changes; deleting the declarations already resolves the issue.

[ronald-cron-arm]

Apparentely, there is no need for any extensive changes; deleting the declarations already resolves the issue.

I've added a comment in #258, thanks.

[gilles-peskine-arm]

LGTM

[davidhorstmann-arm]

LGTM, thanks!