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>
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>
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.
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>
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>
