gh-Mbed-TLS/TF-PSA-Crypto

Watch

Fork 0

Expose blob size helper for `psa_format_key_data_for_storage` #792

New issue

Open

opened 2026-05-14 03:56:32 -05:00 by Harshal5 · 4 comments

Harshal5 commented

2026-05-14 03:56:32 -05:00

(Migrated from github.com)

Suggested enhancement

psa_format_key_data_for_storage() is declared in psa_crypto_storage.h and is reachable from external code, but callers can't determine the size of the output buffer to allocate. The size is data_length + sizeof(psa_persistent_key_storage_format), where the latter struct is static to psa_crypto_storage.c.

Proposed addition

/* psa_crypto_storage.h */
size_t psa_persistent_key_storage_blob_size(size_t key_data_length);

/* psa_crypto_storage.c */
size_t psa_persistent_key_storage_blob_size(size_t key_data_length)
{
    return sizeof(psa_persistent_key_storage_format) + key_data_length;
}

Alternative considered

Moving the struct definition itself to the header would also work but exposes more surface than necessary; the function form keeps the layout fully encapsulated and lets future evolution stay binary-compatible.

Happy to send the PR; patch is trivial. Wanted to gauge appetite first so I don't burn cycles if a different shape is preferred.

### Suggested enhancement `psa_format_key_data_for_storage()` is declared in `psa_crypto_storage.h` and is reachable from external code, but callers can't determine the size of the output buffer to allocate. The size is `data_length + sizeof(psa_persistent_key_storage_format)`, where the latter struct is **static** to `psa_crypto_storage.c`. #### Proposed addition ``` /* psa_crypto_storage.h */ size_t psa_persistent_key_storage_blob_size(size_t key_data_length); /* psa_crypto_storage.c */ size_t psa_persistent_key_storage_blob_size(size_t key_data_length) { return sizeof(psa_persistent_key_storage_format) + key_data_length; } ``` #### Alternative considered Moving the struct definition itself to the header would also work but exposes more surface than necessary; the function form keeps the layout fully encapsulated and lets future evolution stay binary-compatible. Happy to send the PR; patch is trivial. Wanted to gauge appetite first so I don't burn cycles if a different shape is preferred.

Harshal5 commented

2026-05-14 04:05:05 -05:00

(Migrated from github.com)

@gilles-peskine-arm Do you think this request is viable?

gilles-peskine-arm commented

2026-05-18 03:27:57 -05:00

(Migrated from github.com)

It's trivial to implement this function, but I don't understand what it would be used for. psa_format_key_data_for_storage() is not exposed to either applications or drivers, it's purely an internal function. What use would the new function be? What would be its contract in future versions of the library?

It's trivial to implement this function, but I don't understand what it would be used for. `psa_format_key_data_for_storage()` is not exposed to either applications or drivers, it's purely an internal function. What use would the new function be? What would be its contract in future versions of the library?

Harshal5 commented

2026-05-20 00:57:15 -05:00

(Migrated from github.com)

Hi @gilles-peskine-arm,

The use case is PSA ITS backend implementations that synthesise the persistent-key blob on read rather than persisting it through psa_its_set().
The backend has to hand back something that psa_parse_key_data_from_storage() will accept, so it ends up calling psa_format_key_data_for_storage(), and at that point it needs to know how big the output buffer is.

Exact use case:

Pre-provisioned keys. Existing systems that have keys provisioned during manufacturing. They didn't enter ITS via psa_its_set(), but PSA Crypto still needs to see them as persistent keys, so the ITS backend has to generate the blob on the way out of psa_its_get(). As the keys are only the raw key bytes (without the PSA storage header), it saves space and keeps the storage readable by the non-PSA tooling that wrote it. The header is reconstructed on read.

Related: #714

Hi @gilles-peskine-arm, The use case is PSA ITS backend implementations that synthesise the persistent-key blob on read rather than persisting it through `psa_its_set()`. The backend has to hand back something that `psa_parse_key_data_from_storage()` will accept, so it ends up calling `psa_format_key_data_for_storage()`, and at that point it needs to know how big the output buffer is. Exact use case: - Pre-provisioned keys. Existing systems that have keys provisioned during manufacturing. They didn't enter ITS via `psa_its_set()`, but PSA Crypto still needs to see them as persistent keys, so the ITS backend has to generate the blob on the way out of `psa_its_get()`. As the keys are only the raw key bytes (without the PSA storage header), it saves space and keeps the storage readable by the non-PSA tooling that wrote it. The header is reconstructed on read. Related: #714

gilles-peskine-arm commented

2026-05-20 13:53:03 -05:00

(Migrated from github.com)

Thanks for explaining the use case.

To construct a key file to inject into PSA storage, there are two reliable ways:

You can create the file in your provisioning environment, then copy the data to the device storage. This works because the file format is platform-independent. Note that if the provisioning environment uses our ITS-over-stdio implementation, the stdio file has an 8-byte header which is not part of the ITS file, as documented in the Mbed Crypto storage specification.
You can construct the file representation using your own tooling, following the format described in the Mbed Crypto storage specification.

Our code base provides other ways to construct key files: there are internal functions like psa_format_key_data_for_storage() in the library, and there is also some Python code in our test scripts. However, neither of these is a stable interface. Generally speaking, a function that is not declared in a public header (copied by make install) may change or be removed at any time. So calling psa_persistent_key_storage_blob_size() from your code would be less stable than hard-coding the numerical value.

We could define a public interface for creating key files, but that would require some work on designing the interface, starting with a broader analysis of requirements.

Thanks for explaining the use case. To construct a key file to inject into PSA storage, there are two reliable ways: * You can create the file in your provisioning environment, then copy the data to the device storage. This works because the file format is platform-independent. Note that if the provisioning environment uses our ITS-over-stdio implementation, the stdio file has an 8-byte header which is not part of the ITS file, as documented in the [Mbed Crypto storage specification](https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/tf-psa-crypto-1.1.0/docs/architecture/mbed-crypto-storage-specification.md#file-namespace-on-stdio-for-mbed-tls-2250). * You can construct the file representation using your own tooling, following the format described in the [Mbed Crypto storage specification](https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/tf-psa-crypto-1.1.0/docs/architecture/mbed-crypto-storage-specification.md#key-file-format-for-mbed-tls-2250). Our code base provides other ways to construct key files: there are internal functions like `psa_format_key_data_for_storage()` in the library, and there is also some Python code in our test scripts. However, neither of these is a stable interface. Generally speaking, a function that is not declared in a public header (copied by `make install`) may change or be removed at any time. So calling `psa_persistent_key_storage_blob_size()` from your code would be less stable than hard-coding the numerical value. We could define a public interface for creating key files, but that would require some work on designing the interface, starting with a broader analysis of requirements.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#792

No description provided.

Rows
Columns

Expose blob size helper for psa_format_key_data_for_storage #792

Suggested enhancement

Proposed addition

Alternative considered

Expose blob size helper for `psa_format_key_data_for_storage` #792