AuroraMiddleware/mbedtls
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #5522 from mpg/fixup-psa-migration

Browse Source 
Fixup psa migration documentation
This commit is contained in:
Manuel Pégourié-Gonnard 2022-02-10 13:41:56 +01:00 committed by GitHub
commit 574e538c75
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/architecture/psa-migration/psa-limitations.md
View File

@ -40,11 +40,11 @@ Arbitrary parameters for FFDH
(See also the first paragraph in the previous section.) (See also the first paragraph in the previous section.)
Currently, the PSA Crypto API can only perform FFDH with a limited set of Currently, the PSA Crypto API can only perform FFDH with a limited set of
well-know parameters (some of them defined in the spec, but implementations well-known parameters (some of them defined in the spec, but implementations
are free to extend that set). are free to extend that set).
TLS 1.2 (and earlier) on the other hand have the server send explicit TLS 1.2 (and earlier) on the other hand have the server send explicit
parameters (P and G) in is ServerKeyExchange message. This has been found to parameters (P and G) in its ServerKeyExchange message. This has been found to
be suboptimal for security, as it is prohibitively hard for the client to be suboptimal for security, as it is prohibitively hard for the client to
verify the strength of these parameters. This led to the development of RFC verify the strength of these parameters. This led to the development of RFC
7919 which allows use of named groups in TLS 1.2 - however as this is only an 7919 which allows use of named groups in TLS 1.2 - however as this is only an
@ -53,8 +53,8 @@ extension.
In TLS 1.3 the situation will be simpler: named groups are the only In TLS 1.3 the situation will be simpler: named groups are the only
option, so the current PSA Crypto API is a good match for that. (Not option, so the current PSA Crypto API is a good match for that. (Not
coincidentally, the groups used by RFC 7919 and TLS 1.3 are part those defined coincidentally, all the groups used by RFC 7919 and TLS 1.3 are included
in the specification.) in the PSA specification.)
There are several options here: There are several options here:
@ -83,7 +83,8 @@ the hash algorithm potentially used to hash the message being signed:
- a mask generation function - a mask generation function
- most commonly MGF1, which in turn is parametrized by a hash algorithm - most commonly MGF1, which in turn is parametrized by a hash algorithm
- a salt length - a salt length
- a trailer field - this is universally 0xBC as far as I've seen - a trailer field - the value is fixed to 0xBC by PKCS#1 v2.1, but was left
configurable in the original scheme; 0xBC is used everywhere in pratice.
Both the existing `mbedtls_` API and the PSA API support only MGF1 as the Both the existing `mbedtls_` API and the PSA API support only MGF1 as the
generation function (and only 0xBC as the trailer field), but there are generation function (and only 0xBC as the trailer field), but there are
@ -155,7 +156,7 @@ When it comes to cryptographic operations, only two things are supported:
The verification is done using `mbedtls_pk_verify_ext()`. The verification is done using `mbedtls_pk_verify_ext()`.
Note: since X.509 parsing ensures that message hash = encoding hash, and Note: since X.509 parsing ensures that message hash = encoding hash, and
`mbedtls_pk_verify_ext()` use encoding hash = mgf1 hash, it looks like all `mbedtls_pk_verify_ext()` uses encoding hash = mgf1 hash, it looks like all
three hash algorithms must be equal, which would be good news as it would three hash algorithms must be equal, which would be good news as it would
match a limitation of the PSA API. match a limitation of the PSA API.