Recall that in the default configuration, Mbed TLS provides access
digest implementations through two layers of indirection:
1) Call of MD API (e.g. mbedtls_md_update())
2) Call of function pointer from MD info structure
3) Actual digest implementation (e.g. mbedtls_sha256_update()).
Ideally, if only a single digest is enabled - say SHA-256 - then calling
mbedtls_md_update() should _directly_ jump to mbedtls_sha256_update(),
with both layers of indirection removed. So far, however, setting
MBEDTLS_MD_SINGLE_HASH will only remove the second - function pointer -
layer of indirection, while keeping the non-inlined stub implementations
of e.g. mbedtls_md_update() around.
This commit is a step towards allowing to define implementations of
the MD API as `static inline` in case we know that they are so small
that they should be defined in md.h and not in md.c.
In a nutshell, the approach is as follows: For an MD API function
mbedtls_md_xxx() that should be inlin-able, introduce its implementation
as a `static inline` wrapper `mbedtls_md_xxx_internal()` in md.h,
and then define mbedtls_md_xxx() either in md.h or in md.c, by just
calling mbedtls_md_xxx_internal().
Moving the implementations of those MD API functions that should be
inlinable to md.h requires the presence of both the MD info struct
and all specific digest wrapper functions in md.h, and this is what
this commit ensures, by moving them from md.c into a new internal
header file md_internal.h. Implementing the aforementioned wrappers for
those MD API that should be inlinable is left for subsequent commits.
ARMC5 appears to use the heuristic that as soon as a function's address
is taken, the function can no longer be removed from the resulting object
file (which is not necessarily true if all uses of the functions address
can be inlined).
Circumvent this lack of optimization by not returning function pointers.
This commit introduces the configuration option
MBEDTLS_MD_SINGLE_HASH
which can be used to hardcode support for a single digest algorithm
at compile-time, at the benefit of reduced code-size.
To use, it needs to be defined to evaluate to a macro of the form
MBEDTLS_MD_INFO_{DIGEST}, and macros MBEDTLS_MD_INFO_{DIGEST}_FIELD
must be defined, giving rise to the various aspects (name, type,
size, ...) of the chosen digest algorithm. MBEDTLS_MD_INFO_SHA256
provides an example, but other algorithms can be added if needed.
At the moment, the effect of using MBEDTLS_MD_SINGLE_HASH is that
the implementation of the MD API (e.g. mbedtls_md_update()) need no
longer to through the abstraction of the mbedtls_md_info structures
by calling their corresponding function pointers fields (akin to
virtual functions in C++), but the directly call the corresponding
core digest function (such as mbedtls_sha256_update()).
Therefore, MBEDTLS_MD_SINGLE_HASH so far removes the second layer
of indirection in the chain
User calls MD API -> MD API calls underlying digest impl'n
-> Core digest impl'n does the actual work,
but the first indirection remains, as the MD API remains untouched
and cannot yet be inlined. Studying to what extend inlining the
shortened MD API implementations would lead to further code-savings
is left for a later commit.
In builds enabling only a single MD digest, we want to be able to
implement the MD info getter functions by returning compile-time
constants matching the fields of the MD info structures used so far.
To avoid information duplication hardening maintainability, this
commit introduces the possibility of providing the various aspects
of a particular digest implementation by defining macros
MBEDTLS_MD_INFO_DIGEST_FIELD (e.g. MBEDTLS_MD_INFO_SHA256_SIZE)
and to generate the corresponding mbedtls_md_info instance from
this set of macros, via the new macro MBEDTLS_MD_INFO().
This way, we'll be able to switch between MD info based builds
and single-digest builds without information duplication.
This commit continues the introduction of the MD digest implementation
abstraction layer given by `mbedtls_md_handle_t` by adding getter
functions returning the various properties of an implementation
(e.g. name, digest type, digest size). For the existing implementation,
these are just structure field accesses; however, in configurations
hardcoding the choice of a fixed digest algorithm, we'll be able to
implement them as inline functions returning compile-time constants.
As has been previously done for ciphersuites, this commit introduces
a zero-cost abstraction layer around the type
mbedtls_md_info const *
whose valid values represent implementations of message digest algorithms.
Access to a particular digest implementation can be requested by name or
digest ID through the API mbedtls_md_info_from_xxx(), which either returns
a valid implementation or NULL, representing failure.
This commit replaces such uses of `mbedtls_md_info const *` by an abstract
type `mbedtls_md_handle_t` whose valid values represent digest implementations,
and which has a designated invalid value MBEDTLS_MD_INVALID_HANDLE.
The purpose of this abstraction layer is to pave the way for builds which
support precisely one digest algorithm. In this case, mbedtls_md_handle_t
can be implemented as a two-valued type, with one value representing the
invalid handle, and the unique valid value representing the unique enabled
digest.
Cookies are fully opaque so we can change the hash used at any time, it's not
part of the API.
The cookie module handles truncation, so it's simpler to always use SHA-256
rather than check if SHA-224 is available.
Moved some functions under defined to get rid of compiler warnings.
Functions moved under defines:
- mbedtls_x509_get_alg
- mbedtls_x509_get_alg_null
- mbedtls_x509_get_time
- mbedtls_x509_get_ext
- mbedtls_x509_sig_alg_gets
- mbedtls_x509_key_size_helper
Left one function (mbedtls_x509_write_names) as non static as it increased code size.
* origin/mbedtls-2.16:
Changelog entry
Check for zero length and NULL buffer pointer
ssl-opt.sh: wait for proxy to start before running the script further
Adapt ChangeLog
Fix mpi_bigendian_to_host() on bigendian systems
No need to play tricks with macros and functions depending on whether
SHA256_SMALLER is enabled or not, with a static inline function all common
compilers (tested with arm-gcc, armcc5, arm-clang) will Do The Right Thing
depending on whether we told them to optimize for size or speed.
The TinyCrypt PK signature wrapper uses ASN.1 writing functions
for length and tag, accounting for the only dependency of the
baremetal build on ASN.1 writing.
Since all lengths to be encoded are below 128 Bytes and are hence
ASN.1 encoded as single Bytes, the dependency on ASN.1 writing can
be removed at low complexity by writing the length and tags directly.
Extend scope of TC in ECDH-param extraction from CRT
Previously, TinyCrypt was only used for ECDHE-ECDSA/RSA ciphersuites.
This commit is a step towards using it for _all_ ciphersuites involving
ECDHE (specifically: ECDHE, ECDHE-PSK, static ECDH), extending the scope
of the use of TinyCrypt in the writing of the ClientKeyExchange message.
Extend scope of TC in ECDH-param extraction from CRT
Previously, TinyCrypt was only used for ECDHE-ECDSA/RSA ciphersuites.
This commit is a step towards using it for _all_ ciphersuites involving
ECDHE (specifically: ECDHE, ECDHE-PSK, static ECDH), extending the scope
of the use of TinyCrypt in the parsing of the ServerKeyExchange message.
Previously, TinyCrypt was only used for ECDHE-ECDSA/RSA ciphersuites.
This commit is a step towards using it for _all_ ciphersuites involving
ECDHE (specifically: ECDHE, ECDHE-PSK, static ECDH), extending the scope
of the use of TinyCrypt in the parsing of the ClientKeyExchange message.
Previously, TinyCrypt was only used for ECDHE-ECDSA/RSA ciphersuites.
This commit is a step towards using it for _all_ ciphersuites involving
ECDHE (specifically: ECDHE, ECDHE-PSK, static ECDH), extending the scope
of the use of TinyCrypt in the writing of the ServerKeyExchange message.
Extend scope of TC in ECDH-param extraction from CRT
Previously, TinyCrypt was only used for ECDHE-ECDSA/RSA ciphersuites.
This commit is a step towards using it for _all_ ciphersuites involving
ECDHE (specifically: ECDHE, ECDHE-PSK, static ECDH), extending the scope
of the use of TinyCrypt in the assembly of the PMS.
mbedtls/ecp.h defines constants
MBEDTLS_ECP_PF_UNCOMPRESSED
MBEDTLS_ECP_PF_COMPRESSED
MBEDTLS_ECP_TLS_NAMED_CURVE
which regard the encoding of elliptic curves and curve point formats in TLS.
As such, they should be defined in the SSL namespace. Asides, this will help
replacing the legacy ECC crypto by alternative ECC implementations.
PEM-encoded keys with PEM header
-----BEGIN EC PRIVATE KEY-----
...
-----END EC PRIVATE KEY-----
were previously not parsed in configurations using TinyCrypt
instead of legacy ECC crypto.
The PK type MBEDTLS_PK_ECDSA is never returned from
`mbedtls_pk_info_from_type()`. Instead, EC keys either
are identified as MBEDTLS_PK_ECKEY_DH (in case they
must only be used for ECDHE) or MBEDTLS_PK_ECKEY (in
case they can be used for any algorithm).
With TinyCrypt and legacy ECC mutually exclusive, we don't have
to use #if TINYCRYPT #else #if LEGACY #endif #endif anymore, but
can add the TC and legacy based ECC implementations independently.
- TinyCrypt uses `0` for errors.
- The first argument to uECC_verify() should be the public key,
but the previous code passed the beginning of the entire
private-public key structure.
The PK-type MBEDTLS_PK_ECDSA isn't really used by the library.
Especially, when parsing a generic EC key, a PK context of type
MBEDTLS_PK_ECKEY will be requested. Hence, to drop in TinyCrypt
for the legacy-ECC implementation, the PK type that TinyCrypt
implements must be MBEDTLS_PK_ECKEY.
The SSL context maintains a set of 'out pointers' indicating the
address at which to write the header fields of the next outgoing
record. Some of these addresses have a static offset from the
beginning of the record header, while other offsets can vary
depending on the active record encryption mechanism: For example,
if an explicit IV is in use, there's an offset between the end
of the record header and the beginning of the encrypted data to
allow the explicit IV to be placed in between; also, if the DTLS
Connection ID (CID) feature is in use, the CID is part of the
record header, shifting all subsequent information (length, IV, data)
to the back.
When setting up an SSL context, the out pointers are initialized
according to the identity transform + no CID, and it is important
to keep them up to date whenever the record encryption mechanism
changes, which is done by the helper function ssl_update_out_pointers().
During context deserialization, updating the out pointers according
to the deserialized record transform went missing, leaving the out
pointers the initial state. When attemping to encrypt a record in
this state, this lead to failure if either a CID or an explicit IV
was in use. This wasn't caught in the tests by the bad luck that
they didn't use CID, _and_ used the default ciphersuite based on
ChaChaPoly, which doesn't have an explicit IV. Changing either of
this would have made the existing tests fail.
This commit fixes the bug by adding a call to ssl_update_out_pointers()
to ssl_context_load() implementing context deserialization.
Extending test coverage is left for a separate commit.
This patch fixes an issue we encountered with more stringent compiler
warnings. The signature_is_good variable has a possibility of being
used uninitialized. This patch moves the use of the variable to a
place where it cannot be used while uninitialized.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
