Dual-API hash dispatch strategy by gilles-peskine-arm · Pull Request #6549 · Mbed-TLS/mbedtls

gilles-peskine-arm · 2022-11-07T21:30:59Z

Architecture document for dispatching hash operations to the optimal backend: legacy or PSA.

To be extended to ciphers later. That can follow the same principle, but there will be extra complications. I think we should implement hash first and work out any snags before we go further with the design of cipher.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

docs/architecture/psa-migration/md-cipher-dispatch.md

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

docs/architecture/psa-migration/md-cipher-dispatch.md

gilles-peskine-arm · 2022-11-12T16:23:01Z

docs/architecture/psa-migration/md-cipher-dispatch.md

+
+#### Compile-time availability determination
+
+Can we determine how to dispatch at compile time?


This is the wrong question, or at least, it's being asked too early. The important question is: what does code calling existing APIs expect?

Code in the legacy domain expects that all legacy mechanisms are available at all times.

Code in the PSA domain expect that all PSA mechanisms are available after psa_crypto_init, and (sometimes) that mechanisms not indicated as available through PSA_WANT_xxx are rejected.

Code in the mixed domain needs to conform to the expectations of its callers.

A useful conclusion is that the union of PSA and legacy is always correct for the hybrid domain, regardless of the details of how it's done under the hood:

When the union is called by legacy code, mechanisms that have a legacy implementation are available, regardless of the PSA state.

When the union is called by PSA code, PSA is guaranteed to have been initialized, and mechanisms that have a PSA implementation are available.

Backward compatibility does not require making any promises regarding the runtime availability of PSA-only mechanisms when the union is called by legacy code, provided that legacy code does not care about negative availability.

Finish working out the RSA-PSS example in terms of what it implies about the interface. The key takeaway is that a mixed-domain module must support algorithms if they are available through either interface, and that's all there is to it. The details of how dispatch is done don't matter, what matters is only the availability, and it's just the disjunction of availabilities. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

docs/architecture/psa-migration/md-cipher-dispatch.md

gilles-peskine-arm · 2022-12-10T13:42:47Z

docs/architecture/psa-migration/md-cipher-dispatch.md

+
+#### Get rid of the hash_info module
+
+The hash_info module is redundant with MD light. Move `mbedtls_md_error_from_psa` to `md.c`, defined only when `MBEDTLS_MD_SOME_PSA` is defined. The rest is no longer used.


Actually the function mbedtls_hash_info_md_from_psa is also used inside PSA code when it's calling legacy interfaces (RSA, ECDSA). It's the dual of psa_alg_of_md_info and we need both functions in our code base at least until 4.0.

Fortunately, if we optimize type conversions as above, this function will be quite trivial as well.

mpg

I haven't finished reviewing, but I'm still releasing my comments so far. I'll start again with line 404.

docs/architecture/psa-migration/md-cipher-dispatch.md

No intended meaning change. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

It's a rare scenario, but it's currently possible: if you use mbedtls_cipher_xxx() to encrypt the communication between the application and the crypto service, changing those functions to call PSA will break your system. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

It seems that it won't be necessary anyway. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

mpg

Only two points left:

I think support for PSA_CRYPTO_CLIENT is out of scope for now, let's focus on drivers and keep depending on PSA_CRYPTO_C for everything PSA.
We need to record somewhere our decision to require that every hash that's available on the legacy side will be available on the PSA side as well (that is, MBEDTLS_SHA256_C implies PSA_WANT_ALG_SHA_256 etc).

docs/architecture/psa-migration/md-cipher-dispatch.md

This is not strictly mandatory, but it helps. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm · 2023-02-07T19:40:58Z

I've added the legacy-implies-PSA requirement. I don't think I should remove any MBEDTLS_PSA_CRYPTO_CLIENT considerations from the document. We aren't aiming to make it all work, just to preserve the current functional behavior.

docs/architecture/psa-migration/md-cipher-dispatch.md

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

mpg · 2023-02-08T11:17:25Z

I've added the legacy-implies-PSA requirement.

Thanks.

I don't think I should remove any MBEDTLS_PSA_CRYPTO_CLIENT considerations from the document. We aren't aiming to make it all work, just to preserve the current functional behavior.

I've added the legacy-implies-PSA requirement.

Thanks.

I don't think I should remove any MBEDTLS_PSA_CRYPTO_CLIENT considerations from the document. We aren't aiming to make it all work, just to preserve the current functional behavior.

Points of agreement:

I'm OK with keeping MBEDTLS_PSA_CRYPTO_CLIENT in the analysis sections of the document.
Obviously anything that already works needs to keep working.
We aren't aiming to make it all work.

Point of disagreement or misunderstanding: I don't think we should add any support for MBEDTLS_PSA_CRYPTO_CLIENT in the new MD (light): ie, we should only dispatch to PSA when MBEDTLS_PSA_CRYPTO_C is defined (and the hash is accelerated). Looking at the document, I think that's what it currently says, but the comments paint a different picture, specifically https://github.com/Mbed-TLS/mbedtls/pull/6549/files#r1032788788, https://github.com/Mbed-TLS/mbedtls/pull/6549/files#r1047051934 and https://github.com/Mbed-TLS/mbedtls/pull/6549/files#r1054190582 (some of them by me, some by you). So basically what I'm saying now is I think we should disregard those comments and keep the document as it is.

So, I'm going to go ahead and mark those discussions as resolved, and then approve the PR, because I'm OK with the document as it is, just not with the modifications suggested by those comments.

mpg

LGTM

gilles-peskine-arm · 2023-02-08T11:26:26Z

I don't think we should add any support for MBEDTLS_PSA_CRYPTO_CLIENT in the new MD (light): ie, we should only dispatch to PSA when MBEDTLS_PSA_CRYPTO_C is defined (and the hash is accelerated)

I think we should do that eventually but not part of the first batch of work.

Looking at the document, I think that's what it currently says

Indeed. But I think it should capture at least the gist of what should happen with client-only builds in the future. So I'll add that, but as a separate section.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm · 2023-02-08T11:36:26Z

I'm removing “needs design approval” since this has Manuel's approval.

mpg

LGTM

AndrzejKurek

Looks good, I only have minor questions. I think that the #6977 prototype should show any loose ends.

AndrzejKurek · 2023-02-10T10:11:26Z

docs/architecture/psa-migration/md-cipher-dispatch.md

+
+In this work, we want two things:
+
+* Make non-covered modules call PSA, but only [when this will actually work](#why-psa-is-not-always-possible). This effectively brings those modules to a partial use-PSA behavior regardless of whether the option is enabled.


This sounds a bit strange, since it means that even if we disable MBEDTLS_USE_PSA_CRYPTO, we still aim to use it (so it's useless);
If what you mean is that if MBEDTLS_USE_PSA_CRYPTO is disabled, hence it will not actually work, it's not that transparent here.

Yes, PSA will be used in some places even if MBEDTLS_USE_PSA_CRYPTO is disabled. I agree that's a bit unintuitive so perhaps we can update the documentation of that macro:

when it is enabled, the modules that obey it (PK, X.509, TLS 1.2/shared) will use PSA Crypto whenever they can and more importantly, the user promises to call psa_crypto_init() before calling any function from those modules;

when it is disabled, any module may or may not use PSA Crypto at their discretion, but since the user has made no promise to call psa_crypto_init() before calling functions from legacy modules, it's up to these modules to check whether calling PSA crypto is safe or not.

docs/architecture/psa-migration/md-cipher-dispatch.md

AndrzejKurek · 2023-02-10T11:11:54Z

docs/architecture/psa-migration/md-cipher-dispatch.md

+
+There is no strong reason to allow mechanisms available through legacy but not PSA when `MBEDTLS_PSA_CRYPTO_C` is enabled. This would only save at best a very small amount of code size in the PSA dispatch code. This may be more desirable when `MBEDTLS_PSA_CRYPTO_CLIENT` is enabled (having a mechanism available only locally and not in the crypto service), but we do not have an explicit request for this and it would be entirely reasonable to forbid it.
+
+In this analysis, we have not found a compelling reason to require all legacy mechanisms to also be available through PSA. However, this can simplify both the implementation and the use of dispatch code thanks to some simplifying properties:


Do we also want to differentiate between PSA->drivers, and PSA->software, when both are present? Again, probably irrelevant for hashes, but I would assume that key location will handle that?

Even with keys, legacy interfaces are always passing keys in plaintext, so all that matters is volatile, transparent keys (lifetime=0).

docs/architecture/psa-migration/md-cipher-dispatch.md

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

New strategy: start the analysis

d47ba71

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm added needs-work needs-design-approval component-crypto Crypto primitives and low-level interfaces labels Nov 7, 2022

gilles-peskine-arm requested a review from mpg November 7, 2022 21:31

gilles-peskine-arm marked this pull request as draft November 7, 2022 21:31

gilles-peskine-arm commented Nov 7, 2022

View reviewed changes

docs/architecture/psa-migration/md-cipher-dispatch.md Show resolved Hide resolved

Starting to work out the RSA-PSS example

c82050e

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm commented Nov 10, 2022

View reviewed changes

docs/architecture/psa-migration/md-cipher-dispatch.md Show resolved Hide resolved

gilles-peskine-arm commented Nov 12, 2022

View reviewed changes

gilles-peskine-arm added 4 commits November 25, 2022 22:57

Specify MD light based on the interface requirements

188e900

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Sketch the work to migrate to MD light

f634fe1

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Sketch some optimizations relevant to MD light

4eefade

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm marked this pull request as ready for review November 25, 2022 22:05

gilles-peskine-arm added needs-review Every commit must be reviewed by at least two team members, needs-reviewer This PR needs someone to pick it up for review and removed needs-work labels Nov 25, 2022

gilles-peskine-arm changed the title ~~Dual-API hash and cipher dispatch strategy~~ Dual-API hash dispatch strategy Nov 25, 2022

gilles-peskine-arm commented Nov 26, 2022

View reviewed changes

docs/architecture/psa-migration/md-cipher-dispatch.md Show resolved Hide resolved

mpg linked an issue Dec 1, 2022 that may be closed by this pull request

Architecture: simplify dual-API hash dispatch #6471

Closed

gilles-peskine-arm commented Dec 10, 2022

View reviewed changes

mpg reviewed Dec 13, 2022

View reviewed changes

gilles-peskine-arm mentioned this pull request Dec 13, 2022

Allow PSA hash operations without psa_crypto_init #6470

Draft

gilles-peskine-arm added 6 commits December 13, 2022 20:29

Wording clarifications and typo fixes

d167f16

No intended meaning change. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Note that we can tweak the meaning of MBEDTLS_PSA_CRYPTO_CONFIG too

cb93ac9

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

PKCS#1v1.5 sign/verify uses hash metadata

143ebcc

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

The PSA cipher/AEAD API requires an initialized keystore

22db991

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

We haven't actually made hash accelerators initless in 3.3

3e30e1f

It seems that it won't be necessary anyway. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

mpg requested changes Feb 7, 2023

View reviewed changes

Support all legacy algorithms in PSA

fad34a4

This is not strictly mandatory, but it helps. Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

AndrzejKurek self-requested a review February 7, 2023 19:41

mpg reviewed Feb 8, 2023

View reviewed changes

docs/architecture/psa-migration/md-cipher-dispatch.md Outdated Show resolved Hide resolved

add a missing

58e935f

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

mpg previously approved these changes Feb 8, 2023

View reviewed changes

Summarize how to improve MBEDTLS_PSA_CRYPTO_CLIENT

199ee45

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm dismissed mpg’s stale review via 199ee45 February 8, 2023 11:35

gilles-peskine-arm requested a review from mpg February 8, 2023 11:35

gilles-peskine-arm added priority-high High priority - will be reviewed soon and removed needs-design-approval needs-reviewer This PR needs someone to pick it up for review labels Feb 8, 2023

mpg previously approved these changes Feb 8, 2023

View reviewed changes

mpg mentioned this pull request Feb 8, 2023

Add test for PK parsing of keys using compressed points #6937

Merged

3 tasks

AndrzejKurek previously approved these changes Feb 10, 2023

View reviewed changes

gilles-peskine-arm added 2 commits February 10, 2023 14:31

Typos

ff674d4

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

Minor clarifications

91af0f9

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>

gilles-peskine-arm dismissed stale reviews from AndrzejKurek and mpg via 91af0f9 February 10, 2023 13:31

gilles-peskine-arm requested review from AndrzejKurek and mpg February 10, 2023 13:31

AndrzejKurek approved these changes Feb 10, 2023

View reviewed changes

mpg approved these changes Feb 15, 2023

View reviewed changes

mpg added approved Design and code approved - may be waiting for CI or backports and removed needs-review Every commit must be reviewed by at least two team members, labels Feb 15, 2023

mpg merged commit 6778ddf into Mbed-TLS:development Feb 15, 2023


		#### Compile-time availability determination

		Can we determine how to dispatch at compile time?


		#### Get rid of the hash_info module

		The hash_info module is redundant with MD light. Move `mbedtls_md_error_from_psa` to `md.c`, defined only when `MBEDTLS_MD_SOME_PSA` is defined. The rest is no longer used.


		In this work, we want two things:

		* Make non-covered modules call PSA, but only [when this will actually work](#why-psa-is-not-always-possible). This effectively brings those modules to a partial use-PSA behavior regardless of whether the option is enabled.


		There is no strong reason to allow mechanisms available through legacy but not PSA when `MBEDTLS_PSA_CRYPTO_C` is enabled. This would only save at best a very small amount of code size in the PSA dispatch code. This may be more desirable when `MBEDTLS_PSA_CRYPTO_CLIENT` is enabled (having a mechanism available only locally and not in the crypto service), but we do not have an explicit request for this and it would be entirely reasonable to forbid it.

		In this analysis, we have not found a compelling reason to require all legacy mechanisms to also be available through PSA. However, this can simplify both the implementation and the use of dispatch code thanks to some simplifying properties:

Conversation

gilles-peskine-arm commented Nov 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gilles-peskine-arm Nov 12, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gilles-peskine-arm Dec 10, 2022

Choose a reason for hiding this comment

Uh oh!

mpg Dec 15, 2022

Choose a reason for hiding this comment

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gilles-peskine-arm commented Feb 7, 2023

Uh oh!

Uh oh!

mpg commented Feb 8, 2023

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

gilles-peskine-arm commented Feb 8, 2023

Uh oh!

gilles-peskine-arm commented Feb 8, 2023

Uh oh!

mpg left a comment

Choose a reason for hiding this comment

Uh oh!

AndrzejKurek left a comment

Choose a reason for hiding this comment

Uh oh!

AndrzejKurek Feb 10, 2023

Choose a reason for hiding this comment

Uh oh!

mpg Feb 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AndrzejKurek Feb 10, 2023

Choose a reason for hiding this comment

Uh oh!

gilles-peskine-arm Feb 10, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

gilles-peskine-arm commented Nov 7, 2022 •

edited

Loading

mpg Feb 10, 2023 •

edited

Loading