ECC: add rationale
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
parent
c74712f12d
commit
7df7d1eb57
1 changed files with 4 additions and 2 deletions
|
@ -84,10 +84,12 @@ For each constant or constructor macro of the form `PSA_KEY_TYPE_xxx`, the symbo
|
|||
|
||||
For asymmetric cryptography, `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` determines whether private-key operations are desired, and `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY` determines whether public-key operations are desired. `PSA_WANT_KEY_TYPE_xxx_KEY_PAIR` implicitly enables `PSA_WANT_KEY_TYPE_xxx_PUBLIC_KEY`: there is no way to only include private-key operations (which typically saves little code).
|
||||
|
||||
#### Configuration symbols for curves
|
||||
#### Configuration symbols for elliptic curves
|
||||
|
||||
For elliptic curve key types, only the specified curves are included. To include a curve, include a symbol of the form **`PSA_WANT_ECC_family_size`**. For example: `PSA_WANT_ECC_SECP_R1_256` for secp256r1, `PSA_WANT_ECC_MONTGOMERY_255` for Curve25519. It is an error to require an ECC key type but no curve, and Mbed TLS will reject this at compile time.
|
||||
|
||||
Rationale: this is a deviation of the general principle that `PSA_ECC_FAMILY_xxx` would have a corresponding symbol `PSA_WANT_ECC_FAMILY_xxx`. This deviation is justified by the fact that it is very common to wish to include only certain curves in a family, and that can lead to a significant gain in code size.
|
||||
|
||||
#### Configuration symbols for algorithms
|
||||
|
||||
For each constant or constructor macro of the form `PSA_ALG_xxx`, the symbol **`PSA_WANT_ALG_xxx`** indicates that support for this algorithm is desired.
|
||||
|
@ -193,7 +195,7 @@ The boolean symbol mechanism proposed here can be translated to a list of JSON c
|
|||
|
||||
#### Naming of symbols
|
||||
|
||||
The names of [elliptic curve symbols](#configuration-symbols-for-curves) are a bit weird: `SECP_R1_256` instead of `SECP256R1`. Should we make them more classical, but less systematic?
|
||||
The names of [elliptic curve symbols](#configuration-symbols-for-elliptic-curves) are a bit weird: `SECP_R1_256` instead of `SECP256R1`, `MONTGOMERY_255` instead of `CURVE25519`. Should we make them more classical, but less systematic?
|
||||
|
||||
#### Impossible combinations
|
||||
|
||||
|
|
Loading…
Reference in a new issue