AES-XTS support in PSA

[dbuenzli]

Suggested enhancement

I tried to use the PSA_ALG_XTS cipher with the psa library and ran into two issues:

1. I was not able to generate a PSA_KEY_TYPE_AES key for AES-256-XTS (bits = 512), psa_generate_key returns PSA_INVALID_ARGUMENT. It works with bits = 256 though i.e. AES-128-XTS.

2. Trying to encrypt with PSA_ALG_XTS and a 256 bit AES key returns PSA_NOT_SUPPORTED. And indeed the switch statement here doesn't seem to mention PSA_ALG_XTS or MBEDTLS_MODE_XTS.

Justification

Mbed TLS needs this because it already seems to have support for it.

Edit (mpg): we might need this for 4.0

[gilles-peskine-arm]

There's unfortunately a design flaw in the PSA API when it comes to XTS: it's specified as using an ordinary block cipher key, but XTS actually needs two keys or a double-size key. I wanted to specify a double-size key but never got around to adding this to the specification.

How urgently do you need this? Would you be willing to contribute the code if I publish a specification draft?

[gilles-peskine-arm]

Oh, actually, no, we actually did fix the API specification and allow double-size keys (it's done for each block cipher key type, e.g. AES). Which means generating a 512-bit AES key (or even a 384-bit key, but AFAIR XTS isn't supposed to use 192-bit keys) is supposed to be supported. That's a bit weird, but it does keep the API specification simple.

So we don't need to extend the API. This is just on the back burner because so far nobody had asked for it.

[dbuenzli]

Thanks for your answers.

How urgently do you need this?

Urgently as in not now, later :-) Just planning and considering to use PSA for a project.

Which means generating a 512-bit AES key (or even a 384-bit key, but AFAIR XTS isn't supposed to use 192-bit keys) is supposed to be supported.

At least it would be better to return PSA_NOT_SUPPORTED rather than PSA_INVALID_ARGUMENT.

Btw. regarding PSA, unless I missed something, I think it would be nice to have a function and/or a scheme to determine which algorithms are supported by a given implementation, so that it can be discovered before one starts processing.

This could perhaps be defined as a validation function on psa_key_attributes_t since they do define operations via usages and should have all the data (algorithm, key type and key size) to determine this. Something like:

psa_status_t psa_key_usage_supported (const psa_key_attributes_t *attributes);

Would you be willing to contribute the code if I publish a specification draft?

If it's a matter of plugging the right existing bits at the right place. I could certainly give a hand with some guidance.

[mpg]

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.

[gilles-peskine-arm]

In Mbed TLS 4.0, we will remove the cipher.h API, so the only way to keep AES-XTS as a feature is to implement it in the PSA API. Therefore I am classifying this as a MUST for TF-PSA-Crypto 1.0.