Since mbedtls_mpi_random() is not specific to ECC code, move it from
the ECP module to the bignum module.
This increases the code size in builds without short Weierstrass
curves (including builds without ECC at all) that do not optimize out
unused functions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make input/output format documentation easier to find:
- Add direct reference to the steps from the input/output functions
- Move the format description directly to the step constants
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Transformed setup description to a more explicit pseudocode based
approach.
- Explained implicit vs explicit key confirmation
Signed-off-by: Janos Follath <janos.follath@arm.com>
This step is not necessarily a memory-hard function. Memory-hard
functions are the best of the breed at the moment, but that's due to
current hardware designs, and CPU-hard-but-not-memory-hard functions
like PBKDF2 are acceptable as well. We're using “key stretching” as the
generic term for such functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The key derivation operation passed to psa_pake_set_password_mhf() might
enter an error state before the function returns. If this happens, the
user needs to know about it so that they can properly abort it.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The type of the key derivation operation was incorrect.
Also neither the PAKE nor key_derivation algorithm knows how many bytes
to transfer at this stage.
There is no optimal or recommended size, PAKEs don't mandate it either
(with the exception of OPAQUE, but that uses it internally and won't be
using this interface).
Adding an input length parameter to allow the application to control how
many bytes the PAKE takes from the key derivation.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Using memory hard functions with PAKEs is the more secure option. It
should be as convenient and efficient to use as less secure options, but
so far it required creating an additional temporary key object.
With psa_pake_set_password_mhf() this eliminates the need for this.
Similarly we could add a convenience function to supply the password
directly from character strings, but that would make the less secure
option more convenient again and therfore we are not doing it now.
Signed-off-by: Janos Follath <janos.follath@arm.com>
PAKE constructions that have multiple key shares will always consume and
produce the key shares in numerical order. So using PSA_PAKE_DATA_XXX_X
would demand step-sequence validation, and provides no functional
utility over having only PSA_PAKE_DATA_XXX.
Signed-off-by: Janos Follath <janos.follath@arm.com>
If PSA_PAKE_OUTPUT_SIZE takes cipher_suite as a parameter and it is a
structure it can't be a compile-time constant anymore.
Reintroducing psa_pake_primitive_t, because it can be constructed as an
integral type and holds enough information to allow PSA_PAKE_OUTPUT_SIZE
calculating accurate estimates on the output size in compile time.
Signed-off-by: Janos Follath <janos.follath@arm.com>
There are too many parameters to the setup function. This makes it hard
to figure out how to call the function and read code that calls the
function. This also opens the suspicion that there's yet another
parameter that we're missing.
Signed-off-by: Janos Follath <janos.follath@arm.com>
"Data" is too vague, renaming it to psa_pake_step_t. It is still
somewhat vague, but at least consistent with the naming used in key
derivation.
Signed-off-by: Janos Follath <janos.follath@arm.com>
__DOXYGEN_ONLY__ blocks were only used to typeset the PSA specification
back when it was extracted from Mbed TLS headers. They are no longer
used and should be removed.
The PSA Crypto Driver API is still under development and might be
extracted from Mbed TLS headers, leaving them there for now.
Signed-off-by: Janos Follath <janos.follath@arm.com>
It is the size of something that has no a priori reason to consist of 8
bits. This should be psa_pake_family_t, both for documentation (and
possibly static analysis) and in case 8 bits turn out not to be enough.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Identifier value was not consistent with PSA conventions (last byte is
reserved for hash algorithms or used in algorithms parametrized by
a hash).
Signed-off-by: Janos Follath <janos.follath@arm.com>
The cipher suite now defines the algorithm itself as well. Passing the
algorithm separately is redundant and error prone.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Making the cipher suite struct internal made a number of types and
macros in the interface unused.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Hiding the structure of the cipher suite implementation allows for
greater flexibility.
To preserve maximum flexibility, the constructor is replaced by
individual setter/getter functions.
Convenience macros and or functions can be added later.
Signed-off-by: Janos Follath <janos.follath@arm.com>
In the key types API, PSA Crypto uses ECC to denote Elliptic curve
cryptography and DH to denote Finite Field Diffie-Hellman.
Change PSA_PAKE_PRIMITIVE_TYPE_XXX macros to be aligned.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The macro PSA_PAKE_KEY_SHARE_SIZE has been removed, we need to remove
references to it from the documentation as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
There were remnants of the PSA specification wording in the
documentation that can be confusing in Mbed TLS.
We need to make it clear what the consequences of being implementation
defined are in Mbed TLS.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The main purpose of psa_pake_get_key_share() is to provide a more
straightforward and convenient call flow for regular PAKEs. Most PAKEs
have a single key share and need a flow like this:
op=PSA_PAKE_OPERATION_INIT;
psa_pake_setup();
psa_pake_get_key_share();
psa_pake_set_key_share();
psa_pake_get_implicit_key();
Adding psa_pake_get/set_key_share() functions cuts out the
psa_pake_data_t constants from the users vision, hiding complexity that
exists only for unrelated PAKEs that aren't relevant for the user.
This comes with the cost of the two additional API functions that we need
to maintain.
Since the current stream of work focuses on enabling J-PAKE, there are
no benefits to these functions for now.
Once algorithms that can benefit from this simplification are added,
adding back these functions can be reconsidered.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The documentation is calling PAKEs protocols but it has an
psa_algorithm_t identifier. To align the terminology, the documentation
should call them algorithms as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Fix the typo in the macro definition and more specific parameter names
allow for future scripts to check validity of arguments.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The PSA_KEY_TYPE_PASSWORD key type to which this documentation change
refers to is not yet present in the code and will be introduced by a
parallel line of work.
Signed-off-by: Janos Follath <janos.follath@arm.com>
PAKE protocols make use of a range of cryptographic schemes and
primitives. Standards allow for several options to use for each of them.
They call the combination of specific algorithms cipher suites,
configurations or options.
Cipher suites are represented by a separate data type for several
reasons:
1. To allow for individual PAKE protocols to provide pre-defined cipher
suites.
2. To organise cipher suites into a unit that can be handled separately
from the operation context. The PAKE operation flow is already
complex, will be even more so when key confirmation is added.
Handling them separately should reduce the surface of the interface
the application developer needs to pay attention at any given time.
Signed-off-by: Janos Follath <janos.follath@arm.com>
In most of the PAKEs the primitives are prime order groups, but some of
them might need the ring structure or just are using completely different
algebraic structures (eg. SRP or PQC schemes).
Signed-off-by: Janos Follath <janos.follath@arm.com>
Commit adds the conditional definition of
MBEDTLS_ECDH_LEGACY_CONTEXT to ecdh.h.
MBEDTLS_ECDH_LEGACY_CONTEXT is only defined
if MBEDTLS_ECP_RESTARTABLE is definied.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes the definition of
MBEDTLS_ECDH_LEGACY_CONTEXT from config.h.
Additionally removes the unset calls to
MBEDTLS_ECDH_LEGACY_CONTEXT in all.sh.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Split operation start and the declaration of data lengths
to better align with the PSA Cryptography multipart AEAD
APIs.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
MBEDTLS_ECP_FIXED_POINT_OPTIM aims to speed up ecc multiplication performance.
We compute the comb table in runtime now. It is a costly operation.
This patch add a pre-computed table to initialize well-known curves. It speed up ECDSA signature verify process in runtime by using more ROM size.
Signed-off-by: kXuan <kxuanobj@gmail.com>
- the \internal note said that calling cipher_init() first would be made
mandatory later, but the documention of the ctx parameter already said
the context had to be initialized...
- the documentation was using the word initialize for two different
meanings (calling setup() vs calling init()), making the documentation
of the ctx parameter quite confusing (you must initialize before you can
initialize...)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Improve some length parameter descriptions, aligning
them with the descriptions for the one-shot
functions.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Change from `body` to `input` to refer to the input data.
Add prefix total_ to the new length parameters
to ease refering to them in the documentation of
the other multi-part APIs.
Add error code documentation.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define the dependency symbols PSA_WANT_ALG_ECDSA_ANY and
PSA_WANT_ALG_RSA_PKCS1V15_SIGN_RAW as de facto synonyms of
PSA_WANT_ALG_ECDSA and PSA_WANT_ALG_RSA_PKCS1V15_SIGN respectively: if
either one is requested, the other is set.
This makes it easier to systematically determine the dependencies of
an algorithm.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define CCM multi-part API along the lines of the
GCM multi-part API. The two APIs are not exactly
the same as, contrary to GCM, CCM needs the size
of the additional data and plaintext/ciphertext
from the start.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The previous documentation could be read as exhaustively listing
the factors that go into computing the maximum outgoing record
plaintext size -- we should give examples, but allow ourselves
to add more factors in the future.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
This commit makes the API
- mbedtls_ssl_get_output_max_frag_len()
- mbedtls_ssl_get_input_max_frag_len()
- mbedtls_ssl_get__max_frag_len()
for querying the state of the Maximum Fragment Length
extension internal.
Rationale: The value those APIs provide to the user is in
upper bounds for the size of incoming and outgoing records,
which can be used to size application data buffers apporpriately
before passing them to mbedtls_ssl_{read,write}(). However,
there are other factors which influence such upper bounds,
such as the MTU or other extensions (specifically, the
record_size_limit extension which is still to be implemented)
which should be taken into account.
There should be more general APIs for querying the maximum
size of incoming and outgoing records.
For the maximum size of outgoing records, we already have such,
namely mbedtls_ssl_get_max_out_record_payload().
For the maximum size of incoming records, a new API will be
added in a subsequent commit.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Public structs members are considered private and should not
be used by users application.
MBEDTLS_PRIVATE(member) macro is intended to clearly indicate
which members are private.
Signed-off-by: Mateusz Starzyk <mateusz.starzyk@mobica.com>
Some documentation in rsa.h was
still incorrect regarding f_rng
being mandatory. This has now
been corrected.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Conflicts:
library/version_features.c
programs/test/query_config.c
Files were removed in development branch and modified by current branch.
Conflicts fixes by removing them.
This commit removes the RSA
constants MBEDTLS_RSA_PUBLIC
and MBEDTLS_RSA_PRIVATE because
they are now superfluous given
that the mode parameter has been
removed.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes the mode parameter
from the mbedtls_rsa_rsassa_pss_verify_ext
function. This change is propagated
throughout the codebase.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes the f_rng parameter from
the mbedtls_rsa_rsassa_pss_verify_ext
function. This is in preparation for
the removal of the mode parameter.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes p_rng parameter from the
mbedtls_rsa_rsassa_pss_verify_ext function
in preparation for removal of the mode
parameter.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes the mode parameter
from the mbedtls_rsa_rsassa_pss_verify
function and propagates the change
throughout the process.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes f_rng parameter from
mbedtls_rsa_rsassa_pss_verify function in
preparation of mode parameter removal.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes p_rng parameter from
mbedtls_rsa_rsassa_pss_verify function
as preparation for removing the mode
parameter.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes mode parameter from
mbedtls_rsa_rsassa_pkcs1_v15_verify and
propagates the change throughout the
codebase.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit performs removal of f_rng parameter
from mbedtls_rsa_rsassa_pkcs1_v15_verify
function in preparation for removal of mode
parameter.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes p_rng from
mbedtls_rsa_rsassa_pkcs1_v15_verify function in
preparation of removal of mode parameter.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Conflicts:
* configs/config-psa-crypto.h: modified here, removed in development
* tests/suites/test_suite_x509parse.data: all conflicts are in depends_on
lines where development made a change unrelated to MBEDTLS_SHAxxx and our
branch either changed `MBEDTLS_SHA256_C` to `MBEDTLS_SHA224_C` or
`MBEDTLS_SHA512_C:!MBEDTLS_SHA512_NO_SHA384` to ``MBEDTLS_SHA384_C`, with
no change to what the test does. Pick the other branch's dependency
changes then apply our SHA dpeendency change.
To simplify the documentation, and because there are only two realistic
behaviors in practice, only allow two behaviors for multipart output:
immediate output, or buffering of the last partial block.
State some simple rules that applications can follow if they don't care about
the details.
Explicitly state how much output is needed for finish(). Only require the
buffer size to be the size of the actual output, not the size of the potential
output in the worst case. Rename the parameter from output_len to output_size
since it's a buffer size and not necessarily the length of the data.
No longer guarantee that the built-in implementation produces immediate
output.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Commit removes mode parameter from
mbedtls_rsa_pkcs1_verify and propagates the
change throughout the codebase.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes p_rng from mbedtls_rsa_pkcs1_verify
since p_rng has no relevance following the removal
of f_rng from this function.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
Commit removes f_rng parameter from
mbedtls_rsa_pkcs1_verify as a prerequisite
to removing the mode parameter. f_rng no
longer has relevance in this function if
mode is removed.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
