Add new initializers for key policies and use them in our docs, example
programs, tests, and library code. Prefer using the macro initializers
due to their straightforwardness.
Some parts of the library, and crypto drivers, need to see key types,
algorithms, policies, etc. but not API functions. Move portable
integral types and macros to build and analyze values of these types
to a separate headers crypto_types.h and crypto_values.h.
No functional changes, code was only moved from crypto.h to the new headers.
GCC 4.8 warns that some variables may be used without having been
initialized. They aren't, but determining that takes nontrivial
analysis, so initialize them at the point of definition.
The previous prototype gave warnings are the strings produced by #cond and
__FILE__ are const, so we shouldn't implicitly cast them to non-const.
While at it modifying most example programs:
- include the header that has the function declaration, so that the definition
can be checked to match by the compiler
- fix whitespace
- make it work even if PLATFORM_C is not defined:
- CHECK_PARAMS is not documented as depending on PLATFORM_C and there is
no reason why it should
- so, remove the corresponding #if defined in each program...
- and add missing #defines for mbedtls_exit when needed
The result has been tested (make all test with -Werror) with the following
configurations:
- full with CHECK_PARAMS with PLATFORM_C
- full with CHECK_PARAMS without PLATFORM_C
- full without CHECK_PARAMS without PLATFORM_C
- full without CHECK_PARAMS with PLATFORM_C
Additionally, it has been manually tested that adding
mbedtls_aes_init( NULL );
near the normal call to mbedtls_aes_init() in programs/aes/aescrypt2.c has the
expected effect when running the program.
The sample programs require an additional handler function of
mbedtls_param_failed() to handle any failed parameter validation checks enabled
by the MBEDTLS_CHECK_PARAMS config.h option.
Some sample programs access structure fields directly. Making these work is
desirable in the long term, but these are not essential for the core
functionality in non-legacy mode.
Programs and tests need to be able to use PSA header files when
USE_CRYPTO_SUBMODULE and MBEDTLS_USE_PSA_CRYPTO are set. Add the crypto
submodule include folder, which contains psa headers, after the main
include folder so that psa headers can be found and crypto submodule
headers don't take precedence over mbedtls headers.
Otherwise, if `mbedtls_psa_get_free_key_slot()` fails to find a fresh
key slot, the slot value will be undefined, and the call to
`psa_destroy_key()` at the end of `main()` is undefined behavior.
Previously, command line arguments `psk_slot` and `psk_list_slot`
could be used to indicate the PSA key slots that the example
applications should use to store the PSK(s) provided.
This commit changes this approach to use the utility function
`mbedtls_psa_get_free_key_slot()` to obtain free key slots from
the PSA Crypto implementation automatically, so that users only
need to pass boolean flags `psk_opaque` and `psk_list_opaque`
on the command line to enable / disable PSA-based opaque PSKs.
This commit adds command line parameters `psk_slot` and `psk_list_slot`
to the example application `programs/ssl/ssl_server2`. These have the
following semantics:
- `psk_slot`: The same semantics as for the `ssl_client2` example
application. That is, if a PSK is configured through the use
of the command line parameters `psk` and `psk_identity`, then
`psk_slot=X` can be used to import the PSK into PSA key slot X
and registering it statically with the SSL configuration through
the new API call mbedtls_ssl_conf_hs_opaque().
- `psk_list_slot`: In addition to the static PSK registered in the
the SSL configuration, servers can register a callback for picking
the PSK corresponding to the PSK identity that the client chose.
The `ssl_server2` example application uses such a callback to select
the PSK from a list of PSKs + Identities provided through the
command line parameter `psk_list`, and to register the selected
PSK via `mbedtls_ssl_set_hs_psk()`. In this case, the new parameter
`psk_list_slot=X` has the effect of registering all PSKs provided in
in `psk_list` as PSA keys in the key slots starting from slot `X`,
and having the PSK selection callback register the chosen PSK
through the new API function `mbedtls_ssl_set_hs_psk_opaque()`.
This commit adds support for the use of PSA-based opaque PSKs
in the TLS client example application programs/ssl/ssl_client2.
Specifically, a numerical command line option `psk_slot` with
the following constraints and semantics is added:
- It can only be used alongside the provisioning of a raw PSK
through the preexisting `psk` command line option.
- It can only be used if both TLS 1.2 and a PSK-only ciphersuite
are enforced through the appropriate use of the `min_version`
and `force_ciphersuite` command line options.
- If the previous conditions are met, setting `psk_slot=d` will
result in the PSA key slot with identifier `d` being populated
with the raw PSK data specified through the `psk` parameter
and passed to Mbed TLS via `mbedtls_ssl_conf_psk_opaque()`
prior to the handshake.
Enforcing the TLS version and ciphersuite is necessary to determine
the exact KDF algorithm the PSK will be used for. This is required
as it is currently not possible to set up a key without specifying
exactly one algorithm the key may be used with.
Otherwise, if `mbedtls_psa_get_free_key_slot()` fails to find a fresh
key slot, the slot value will be undefined, and the call to
`psa_destroy_key()` at the end of `main()` is undefined behavior.
Previously, command line arguments `psk_slot` and `psk_list_slot`
could be used to indicate the PSA key slots that the example
applications should use to store the PSK(s) provided.
This commit changes this approach to use the utility function
`mbedtls_psa_get_free_key_slot()` to obtain free key slots from
the PSA Crypto implementation automatically, so that users only
need to pass boolean flags `psk_opaque` and `psk_list_opaque`
on the command line to enable / disable PSA-based opaque PSKs.
This commit adds command line parameters `psk_slot` and `psk_list_slot`
to the example application `programs/ssl/ssl_server2`. These have the
following semantics:
- `psk_slot`: The same semantics as for the `ssl_client2` example
application. That is, if a PSK is configured through the use
of the command line parameters `psk` and `psk_identity`, then
`psk_slot=X` can be used to import the PSK into PSA key slot X
and registering it statically with the SSL configuration through
the new API call mbedtls_ssl_conf_hs_opaque().
- `psk_list_slot`: In addition to the static PSK registered in the
the SSL configuration, servers can register a callback for picking
the PSK corresponding to the PSK identity that the client chose.
The `ssl_server2` example application uses such a callback to select
the PSK from a list of PSKs + Identities provided through the
command line parameter `psk_list`, and to register the selected
PSK via `mbedtls_ssl_set_hs_psk()`. In this case, the new parameter
`psk_list_slot=X` has the effect of registering all PSKs provided in
in `psk_list` as PSA keys in the key slots starting from slot `X`,
and having the PSK selection callback register the chosen PSK
through the new API function `mbedtls_ssl_set_hs_psk_opaque()`.
This commit adds support for the use of PSA-based opaque PSKs
in the TLS client example application programs/ssl/ssl_client2.
Specifically, a numerical command line option `psk_slot` with
the following constraints and semantics is added:
- It can only be used alongside the provisioning of a raw PSK
through the preexisting `psk` command line option.
- It can only be used if both TLS 1.2 and a PSK-only ciphersuite
are enforced through the appropriate use of the `min_version`
and `force_ciphersuite` command line options.
- If the previous conditions are met, setting `psk_slot=d` will
result in the PSA key slot with identifier `d` being populated
with the raw PSK data specified through the `psk` parameter
and passed to Mbed TLS via `mbedtls_ssl_conf_psk_opaque()`
prior to the handshake.
Enforcing the TLS version and ciphersuite is necessary to determine
the exact KDF algorithm the PSK will be used for. This is required
as it is currently not possible to set up a key without specifying
exactly one algorithm the key may be used with.
Mbed TLS version 2.14.0
Resolved conflicts in include/mbedtls/config.h,
tests/scripts/check-files.py, and yotta/create-module.sh by removing yotta.
Resolved conflicts in tests/.jenkins/Jenkinsfile by continuing to run
mbedtls-psa job.
This commit adds a command line option `md` to the example application
`programs/x509/cert_req` allowing to specify the hash algorithm to use
when signing the CSR.
snprintf was only added in Visual Studio 2015. This adds support
for building using Visual Studio versions prior to 2015.
This implementation of snprintf has been taken from platform.c
* development:
ssl-opt.sh: change expected output for large srv packet test with SSLv3
Adapt ChangeLog
Fix bug in SSL ticket implementation removing keys of age < 1s
ssl-opt.sh: Add DTLS session resumption tests
Add ChangeLog entry
Fix typo
Fix hmac_drbg failure in benchmark, with threading
Remove trailing whitespace
Remove trailing whitespace
ssl_server2: add buffer overhead for a termination character
Add missing large and small packet tests for ssl_server2
Added buffer_size and response_size options for ssl-server2. Added appropriate tests.
Solving a conflict in tests/ssl-opt.sh: two set of tests were added at the
same place (just after large packets):
- restartable ECC tests (in this branch)
- server-side large packets (in development)
Resolution was to move the ECC tests after the newly added server large packet
ones.
This commit replaces multiple `memset()` calls in the example
programs aes/aescrypt2.c and aes/crypt_and_hash.c by calls to
the reliable zeroization function `mbedtls_zeroize()`.
While not a security issue because the code is in the example
programs, it's bad practice and should be fixed.
When using a primality testing function the tolerable error rate depends
on the scheme in question, the required security strength and wether it
is used for key generation or parameter validation. To support all use
cases we need more flexibility than what the old API provides.
If `MBEDTLS_MEMORY_BUFFER_ALLOC_C` is configured and Mbed TLS'
custom buffer allocator is used for calloc() and free(), the
read buffer used by the server example application is allocated
from the buffer allocator, but freed after the buffer allocator
has been destroyed. If memory backtracing is enabled, this leaves
a memory leak in the backtracing structure allocated for the buffer,
as found by valgrind.
Fixes#2069.
* The variables `csr` and `issuer_crt` are initialized but not freed.
* The variable `entropy` is unconditionally freed in the cleanup section
but there's a conditional jump to that section before its initialization.
This cmmot Moves it to the other initializations happening before the
first conditional jump to the cleanup section.
Fixes#1422.
OFB and CFB are streaming modes. XTS is a not a cipher mode but it
doesn't use a separate padding step. This leaves only CBC as a block
cipher mode that needs a padding step.
Since CBC is the only mode that uses a separate padding step, and is
likely to remain the only mode in the future, encode the padding mode
directly in the algorithm constant, rather than building up an
algorithm value from a chaining mode and a padding mode. This greatly
simplifies the interface as well as some parts of the implementation.
Print the symbolic name corresponding to a numerical value.
Supported types: status values, algorithms, elliptic curves,
key types, key usage masks.
The program is partly generated from parsing psa/crypto.h with a few
hard-coded assumptions. This isn't ideal but it works and requires
little machinery.
* development-restricted: (578 commits)
Update library version number to 2.13.1
Don't define _POSIX_C_SOURCE in header file
Don't declare and define gmtime()-mutex on Windows platforms
Correct preprocessor guards determining use of gmtime()
Correct documentation of mbedtls_platform_gmtime_r()
Correct typo in documentation of mbedtls_platform_gmtime_r()
Correct POSIX version check to determine presence of gmtime_r()
Improve documentation of mbedtls_platform_gmtime_r()
platform_utils.{c/h} -> platform_util.{c/h}
Don't include platform_time.h if !MBEDTLS_HAVE_TIME
Improve wording of documentation of MBEDTLS_PLATFORM_GMTIME_R_ALT
Fix typo in documentation of MBEDTLS_PLATFORM_GMTIME_R_ALT
Replace 'thread safe' by 'thread-safe' in the documentation
Improve documentation of MBEDTLS_HAVE_TIME_DATE
ChangeLog: Add missing renamings gmtime -> gmtime_r
Improve documentation of MBEDTLS_HAVE_TIME_DATE
Minor documentation improvements
Style: Add missing period in documentation in threading.h
Rename mbedtls_platform_gmtime() to mbedtls_platform_gmtime_r()
Guard decl and use of gmtime mutex by HAVE_TIME_DATE and !GMTIME_ALT
...
Previously, the UDP proxy could only remember one delayed message
for future transmission; if two messages were delayed in succession,
without another one being normally forwarded in between,
the message that got delayed first would be dropped.
This commit enhances the UDP proxy to allow to delay an arbitrary
(compile-time fixed) number of messages in succession.
This setting belongs to the individual connection, not to a configuration
shared by many connections. (If a default value is desired, that can be handled
by the application code that calls mbedtls_ssl_set_mtu().)
There are at least two ways in which this matters:
- per-connection settings can be adjusted if MTU estimates become available
during the lifetime of the connection
- it is at least conceivable that a server might recognize restricted clients
based on range of IPs and immediately set a lower MTU for them. This is much
easier to do with a per-connection setting than by maintaining multiple
near-duplicated ssl_config objects that differ only by the MTU setting.
