CCM requires one of the 128-bit-block block ciphers to be useful, just like GCM.
GCM and CCM need the cipher module.
ChaChaPoly needs ChaCha20 and Poly1305.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This was already documented for mbedtls_md_info_t. Also document it for
mbedtls_pk_info_t (where it's fairly obvious since the structure is not
defined in a public header) and for mbedtls_cipher_info_t (where it's not
obvious since the structure is defined in a public header).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The structures mbedtls_x509_time, mbedtls_x509_crl_entry, mbedtls_x509_crl,
mbedtls_x509_crt, mbedtls_x509_san_other_name,
mbedtls_x509_subject_alternative_name, mbedtls_x509_csr are designed to
expose the result of parsing X.509 data. Document many of their fields as
being publicly readable.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The structures mbedtls_asn1_buf, mbedtls_asn1_bitstring,
mbedtls_asn1_sequence and mbedtls_asn1_named_data are designed to allow
access to data after parsing. Make their fields public.
Document that chaining fields are essentially read-only.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
On platforms with BSD-like sockets, it is useful for applications to have
access to the underlying file descriptor so that they can use functions like
select() and poll().
Do not promise that the field will exist on other platforms such as
Windows (where the type and name of the field are technically wrong because
Windows socket handles are actually not file descriptors).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add functions to read the type, mode, name and key_bitlen fields from
mbedtls_cipher_info_t. These are the fields that applications are most
likely to care about.
TLS code also uses iv_size and block_size, which it might make sense to
expose, but most applications shouldn't need those, so I'm not exposing them
for now.
Call the new functions in unit tests, so they're at least smoke-tested.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The whole point of this structure is to provide information, both for the
library's own sake and to applications.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Conflicts:
library/ccm.c
Conflict resolved by re-applying the MBEDTLS_BYTE_0 macro.
Conflict resolved by ignoring the MBEDTLS_PUT_UINT16_BE macro
used in development branch on the 'b' buffer, because the 'b'
buffer is removed in current branch.
The numerical identifier of the CID extension hasn't been settled yet
and different implementations use values from different drafts. Allow
configuring the value at compile time.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move logic to ccm_starts, ccm_set_lengths, ccm_update_ad,
ccm_update and ccm_finish
Use separate variable to track context state.
Encode first block only if both mbedtls_ccm_starts() and
mbedtls_ccm_set_lengths() were called.
Signed-off-by: Mateusz Starzyk <mateusz.starzyk@mobica.com>
Now that descriptions of error codes no longer have to be on the same line
for the sake of generate_errors.pl, move them to their own line before the
definition. This aligns them with what we do for other definitions, and
means that we no longer need to have very long lines containing both the C
definition and the comment.
```
perl -i -pe 's~^(#define +MBEDTLS_ERR_\w+ +-\w+) */\*[*!]<(.*)\*/~/**$2*/\n$1~' include/mbedtls/*.h
```
This commit does not change the output of generate_errors.pl.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instances of `mbedtls_ssl_session` represent data enabling session resumption.
With the introduction of TLS 1.3, the format of this data changes. We therefore
need TLS-version field as part of `mbedtlsl_ssl_session` which allows distinguish
1.2 and 1.3 sessions.
This commit introduces such a TLS-version field to mbedtls_ssl_session.
The change has a few ramifications:
- Session serialization/deserialization routines need to be adjusted.
This is achieved by adding the TLS-version after the header of
Mbed TLS version+config, and by having the subsequent structure
of the serialized data depend on the value of this field.
The details are described in terms of the RFC 8446 presentation language.
The 1.2 session (de)serialization are moved into static helper functions,
while the top-level session (de)serialization only parses the Mbed TLS
version+config header and the TLS-version field, and dispatches according
to the found version.
This way, it will be easy to add support for TLS 1.3 sessions in the future.
- Tests for session serialization need to be adjusted
- Once we add support for TLS 1.3, with runtime negotiation of 1.2 vs. 1.3,
we will need to have some logic comparing the TLS version of the proposed session
to the negotiated TLS version. For now, however, we only support TLS 1.2,
and no such logic is needed. Instead, we just store the TLS version in the
session structure at the same point when we populate mbedtls_ssl_context.minor_ver.
The change introduces some overlap between `mbedtls_ssl_session.minor_ver` and
`mbedtls_ssl_context.minor_ver`, which should be studied and potentially resolved.
However, with both fields being private and explicitly marked so, this can happen
in a later change.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Although checking if the key was symmetric was correct, its easier to
read if we just check the block length is not zero before we use it in a
division.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Enable Curve448 support
Add test vectors to evaluate
* RFC 7748
* a known-answer public key export test.
* a known-answer ECDH (X448) test.
Signed-off-by: Archana <archana.madhavan@silabs.com>
If PSA_CIPHER_ENCRYPT_OUTPUT_SIZE was called on a non symmetric key,
then a divide by zero could happen, as PSA_CIPHER_BLOCK_LENGTH will
return 0 for such a key, and PSA_ROUND_UP_TO_MULTIPLE will divide by the
block length.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Fix initialization of mbedtls_psa_cipher_operation_t by not initializing the mbedtls_cipher_context_t typed field completely.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
According to the PSA specification the PSA_USAGE_SIGN_HASH has the
permission to sign a message as PSA_USAGE_SIGN_MESSAGE. Similarly the
PSA_USAGE_VERIFY_HASH has the permission to verify a message as
PSA_USAGE_VERIFY_MESSAGE. These permission will also be present when
the application queries the usage flags of the key.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Introduce new codes:
* MBEDTLS_ERR_SSL_UNSUPPORTED_EXTENSION
* MBEDTLS_ERR_SSL_NO_APPLICATION_PROTOCOL
These are returned when the corresponding alert is raised.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
This symbol is not declared in our code, so trying to explicitly
link to it causes a doxygen error.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
New name MBEDTLS_ERR_SSL_BAD_CERTIFICATE
Also, replace some instances of MBEDTLS_ERR_SSL_BAD_HS_CERTIFICATE
by MBEDTLS_ERR_SSL_DECODE_ERROR and MBEDTLS_ERR_SSL_ILLEGAL_PARAMETER
as fit.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Any config with a version older than 3.0.0 or newer than
MBETLS_VERSION_NUMBER will be rejected.
This does mean that the current development version doesn'T accept *any*
value of MBETLS_CONFIG_VERSION, but this will be fixed when we bump the
version during our normal release process.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Also remove preprocessor logic for MBEDTLS_CONFIG_FILE, since
build_info.h alreadyy handles it.
This commit was generated using the following script:
# ========================
#!/bin/sh
git ls-files | grep -v '^include/mbedtls/build_info\.h$' | xargs sed -b -E -i '
/^#if !?defined\(MBEDTLS_CONFIG_FILE\)/i#include "mbedtls/build_info.h"
//,/^#endif/d
'
# ========================
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Create a separate header file (mbedtls/build_info.h) to use when
depending on the config options defined in config.h.
Also copy the handling of the MBEDTLS_CONFIG_FILE macro into the new
header, so that the next commit can remove this code from every other
place where config.h used to be included.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
The functions mbedtls_pk_sign(), mbedtls_pk_sign_restartable(),
mbedtls_ecdsa_write_signature() and mbedtls_ecdsa_write_signature_restartable()
now take an extra parameter indicating the size of the output buffer for the
signature.
No change to RSA because for RSA, the output size is trivial to calculate.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix typos in the PBKDF2 documentation
Correct the constraints on PSA_KEY_USAGE_DERIVE and PSA_KEY_USAGE_VERIFY_DERIVATION, aligning them with the note against psa_key_derivation_input_key(). All key inputs must have the required usage flag to permit output or verification.
Correct the constraints on PSA_KEY_DERIVATION_INPUT_SECRET and PSA_KEY_DERIVATION_INPUT_PASSWORD, aligning them with 4feb611. psa_key_derivation_verify_key() does not require the secret/password input to be a key.
Signed-off-by: Andrew Thoelke <andrew.thoelke@arm.com>
Without this parameter, it would be hard for callers to know how many bytes
of output the function wrote into the output buffer. It would be possible,
since the cumulated output must have the same length as the cumulated input,
but it would be cumbersome for the caller to keep track.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Hashes used in RSA-PSS encoding (EMSA-PSS-ENCODE, see §9.1.1 in RFC
8017):
- H1: Hashing the message (step 2)
- H2: Hashing in the salt (step 6)
- H3: Mask generation function (step 9)
According to the standard:
- H1 and H2 MUST be done by the same hash function
- H3 is RECOMMENDED to be the same as the hash used for H1 and H2.
According to the implementation:
- H1 happens outside of the function call. It might or might not happen
and the implementation might or might not be aware of the hash used.
- H2 happens inside the function call, consistency with H1 is not
enforced and might not even be possible to detect.
- H3 is done with the same hash as H2 (with the exception of
mbedtls_rsassa_pss_verify_ext(), which takes a dedicated parameter for
the hash used in the MGF).
Issues with the documentation:
- The comments weren't always clear about the three hashes involved and
often only mentioned two of them (which two varied from function to
function).
- The documentation was giving the impression that the standard
recommends aligning H2 and H1 (which is not a recommendation but a
must).
Signed-off-by: Janos Follath <janos.follath@arm.com>
This saves some code when compiling for Thumb, where access to
fields with offset index > 127 requires intermediate address
computations. Frequently used fields should therefore be located
at the top of the structure, while less frequently used ones --
such as the export callback -- can be moved to the back.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Reverting some deleted tests and changing the deprecated algo
Deleting deprecated headers from /alt-dummy dir
Corrections to the comments
Removal of deleted functions from compat-2.x.h
Corrections to tests/data_files/Makefile
Signed-off-by: TRodziewicz <tomasz.rodziewicz@mobica.com>
For TLS, secp256k1 is deprecated by RFC 8422 §5.1.1. For X.509,
secp256k1 is not deprecated, but it isn't used in practice, especially
in the context of TLS where there isn't much point in having an X.509
certificate which most peers do not support. So remove it from the
default profile. We can add it back later if there is demand.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
TLS used to prefer larger curves, under the idea that a larger curve has a
higher security strength and is therefore harder to attack. However, brute
force attacks are not a practical concern, so this was not particularly
meaningful. If a curve is considered secure enough to be allowed, then we
might as well use it.
So order curves by resource usage. The exact definition of what this means
is purposefully left open. It may include criteria such as performance and
memory usage. Risk of side channels could be a factor as well, although it
didn't affect the current choice.
The current list happens to exactly correspond to the numbers reported by
one run of the benchmark program for "full handshake/s" on my machine.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We stated that curves were listed "in order of preference", but we never
explained what the preference was, so this was not meaningful.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
MBEDTLS_ECP_WINDOW_SIZE is a compromise between memory usage (growing based
on the value) and performance (faster with larger values). There are
disminishing returns as the value grows larger. Based on Manuel's benchmarks
recorded in https://github.com/ARMmbed/mbedtls/issues/4127, 4 is a good
compromise point, with larger values bringing little advantage. So reduce
the default from 6 to 4.
Document the default value as in optimized for performance mostly, but don't
document the specific value, so we may change it later or make it
platform-dependent.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Upgrade the default list of hashes and curves allowed for TLS. The list is
now aligned with X.509 certificate verification: hashes and curves with at
least 255 bits (Curve25519 included), and RSA 2048 and above.
Remove MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_KEY_EXCHANGE which would no
longer do anything.
Document more precisely what is allowed by default.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Upgrade the default X.509 certificate verification profile
mbedtls_x509_crt_profile_default to the former value of
mbedtls_x509_crt_profile_next, which is hashes and curves with at least 255
bits (Curve25519 included), and RSA 2048 and above.
Document more precisely what goes into the default profile.
Keep the "next" profile unchanged for now.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This makes it easier to ensure that crypto_spe.h is included everywhere it
needs to be, and that it's included early enough to do its job (it must be
included before any mention of psa_xxx() functions with external linkage,
because it defines macros to rename these functions).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These fields are supposed to be manipulated directly, that's how people
create custom profiles.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It was used to remove the code used when mbedtls_ecp_mul() received a
NULL RNG parameter. This code is no longer relevant (as the RNG may no
longer be NULL) and will be unconditionally removed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is necessary for the case where the public part of an EC keypair
needs to be computed from the private part - either because it was not
included (it's an optional component) or because it was compressed (a
format we can't parse).
This changes the API of two public functions: mbedtls_pk_parse_key() and
mbedtls_pk_parse_keyfile().
Tests and programs have been adapted. Some programs use a non-secure RNG
(from the test library) just to get things to compile and run; in a
future commit this should be improved in order to demonstrate best
practice.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- mbedtls_ecp_check_pub_priv() because it calls ecp_mul()
- mbedtls_pk_check_pair() because it calls the former
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Fix trivial faulty calls in ECP test suite and ECP/ECJPAKE self-tests (by
adding a dummy RNG).
Several tests suites are not passing yet, as a couple of library
function do call ecp_mul() with a NULL RNG. The complexity of the fixes
range from "simple refactoring" to "requires API changes", so these will
be addressed in separate commits.
This makes the option MBEDTLS_ECP_NO_INTERNAL_RNG, as well as the whole
"internal RNG" code, obsolete. This will be addressed in a future
commit, after getting the test suites to pass again.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Not adding a check in the code here, as this will be checked by the
lower-level modules.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
No change here, these were already mandatory, it just wasn't explicit in
the documentation.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Commit removes the
MBEDTLS_SSL_TRUNCATED_HMAC config option from config.h
and places a check that it is unset in check_config.h.
Signed-off-by: Thomas Daubney <thomas.daubney@arm.com>
mbedtls_dhm_get_value can be seen as either a copy function or a getter
function. Given the name and the semantics, it's more of a getter, even if
it "gets" by doing a copy. Therefore, put the context first, and the
selector next, leaving the output for last.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The Mbed TLS code relies heavily on reading certain fields of
mbedtls_ecp_group directly. Make these fields public. Require
that MBEDTLS_ECP_ALT alternative implementations have them.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add two functions mbedtls_dhm_get_len() and mbedtls_dhm_get_bitlen() to
query the length of the modulus in bytes or bits.
Remove the len field: the cost of calling mbedtls_dhm_get_len() each time
it's needed is negligible, and this improves the abstraction of the DHM
module.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
MBEDTLS_ECP_MAX_BITS doesn't make sense as a configuration option: it
must not be smaller than the largest supported curve, and it's useless
to set it to a larger value. So unconditionally set it to the size of
the largest supported curve. Remove it from the build configuration.
Alternative implementations must no longer need define this macro.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Conflicts:
include/mbedtls/ssl.h
include/psa/crypto_struct.h
Conflicts fixed by using the code from development branch
and manually re-applying the MBEDTLS_PRIVATE wrapping.
Mbed OS now provides POSIX-like time functions, although not alarm() nor
signal(). It is possible to implement MBEDTLS_TIMING_ALT on Mbed OS, so
we should not artificially prevent this in check-config. Remove the the
check that prevents implementing MBEDTLS_TIMING_ALT on Mbed OS.
Note that this limitation originally was added in the following commit,
although there isn't much context around why the restriction was
imposed: 63e7ebaaa1 ("Add material for generating yotta module"). In
2015, Mbed OS was quite a different thing: no RTOS, no threads, just an
asynchronous event loop model. I'd suppose the asynchronous event loop
model made it difficult before to implement MBEDTLS_TIMING_C on Mbed OS,
but that is no longer the case.
Fixes#4633
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
Removing reference to RFC 7748 as it is more confusing than helpful. (It
decodes the scalars after masking which is not part of the encoding we
want to specify. Also, it has the explanation what it means by little
endian in a preceding section that is not trivial to find.)
We also explicitly specify constraint on leading zeroes.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The expression "the masking is omitted" assumes familiarity with
Montgomery curve private key format and even then can be confusing and
ambiguous or confusing.
Describe directly what format we mean and add some more background
information and reference to the standard as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
4-space indent is only guaranteed to result in a code block if there's a
blank line just before (details vary depending on the markdown
implementation, and doxygen isn't exactly markdown anyway). In a bullet
list, you need 8 spaces since the list itself is a nested construct
which takes a 4-space indent (even though you don't have to indent
continuation lines inside a bullet point by 4 spaces, 1 is enough).
Using \code...\encode which is rendering as intended.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This level of detail can be confusing and could require even more detail
to clear it up. Simplifying it instead in alignment wiht the
documentation of existing setup functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This reverts commit 03a5fd7780026b2ca0b4728352ded930f5a7cff9.
We're already calling the output of a PAKE a "shared secret". The
password is a shared secret (for PAKE where the verifier knows a
password-equivalent secret), but calling it "shared secret" or even just
"secret" would be confusing.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Technically this function takes a low entropy secret as an input which
might or might not be the password. Using the term "secret" in the
function name is less misleading.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The password stretching (using slow and/or memory hard hashes) in PAKEs
usually serves two purposes:
- Defending against server compromise impersonation attacks. J-PAKE is an
augmented PAKE and as such, stores a password-equivalent and defending
against this class of attacks is out of scope.
- Preventing offline dictionary attacks. J-PAKE is proven to be zero
knowledge and leaks no information beyond the fact if the passwords
matched and offline dictionary attack is not possible.
In summary: J-PAKE does not benefit from pasword stretching and is
unlikely to be an input. This part of the API is not necessary at this
point and can be added later.
Signed-off-by: Janos Follath <janos.follath@arm.com>
We are not confident about the stability of the PAKE interface (it is
just a proposal, not part of the standard yet). So we should explicitly
document it as experimental, subject to change.
Signed-off-by: Janos Follath <janos.follath@arm.com>
At this point this is a proposed PAKE interface for the PSA Crypto API
and not part of the official standard. Place the interface in
crypto_extra.h to make this clear.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The API has PSA_ALG_GCM and not PSA_ALG_AEAD_GCM, PSA_ALG_MD5 and not
PSA_ALG_HASH_MD5, etc., so PSA_ALG_PAKE_JPAKE should be PSA_ALG_JPAKE as
well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The caller is likely to receive the inputs on the wire, and having a
known size for which they can confidently reject longer inputs would be
helpful in cases where the application can't just use the input in
place.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Define the size macros to 0 rather than empty. That will lead to fewer
weird errors when we start implementing.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Remove padding parameters as mbedtls_rsa_init()
cannot return an error code when padding
parameters are invalid.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
mbedtls_rsa_set_padding() now returns the error
code MBEDTLS_ERR_RSA_INVALID_PADDING when
padding parameters are invalid.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
ssl_server2 had a check that we never try to use a minor version lower
than 2 with DTLS, but that check is no longer needed, as there's no way
that would happen now that MBEDTLS_SSL_MINOR_VERSION_1 is no longer
public.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This commit removes the API
```
mbedtls_ssl_conf_ciphersuites_for_version()
```
which allows to configure lists of acceptable ciphersuites
for each supported version of SSL/TLS: SSL3, TLS 1.{0,1,2}.
With Mbed TLS 3.0, support for SSL3, TLS 1.0 and TLS 1.1
is dropped. Moreover, upcoming TLS 1.3 support has a different
notion of cipher suite and will require a different API.
This means that it's only for TLS 1.2 that we require
a ciphersuite configuration API, and
```
mbedtls_ssl_conf_ciphersuites()
```
can be used for that. The version-specific ciphersuite
configuration API `mbedtls_ssl_conf_ciphersuites_for_version()`,
in turn, is no longer needed.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note that this error has a negligible probability with a "crypto-sized"
bound, but macroscopic probability with a small bound.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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>
