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>
This was diversely interpreted as "compatibility in the period between
two major version changes" (as intended) or "compatibility between two
versions whose major version is different" (unintended).
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
