MBEDTLS_ECP_MAX_BITS macro

This macro is invoked by the library when an invalid parameter is detected that is only checked with MBEDTLS_CHECK_PARAMS (see the documentation of that option for context). When you leave this undefined here, a default definition is provided that invokes the function mbedtls_param_failed(), which is declared in platform_util.h for the benefit of the library, but that you need to define in your application. When you define this here, this replaces the default definition in platform_util.h (which no longer declares the function mbedtls_param_failed()) and it is your responsibility to make sure this macro expands to something suitable (in particular, that all the necessary declarations are visible from within the library - you can ensure that by providing them in this file next to the macro definition). Note that you may define this macro to expand to nothing, in which case you don't have to worry about declarations or definitions. However, you will then be notified about invalid parameters only in non-void functions, and void function will just silently return early on invalid parameters, which partially negates the benefits of enabling #MBEDTLS_CHECK_PARAMS in the first place, so is discouraged. \def MBEDTLS_SSL_MAX_CONTENT_LEN Maximum length (in bytes) of incoming and outgoing plaintext fragments. This determines the size of both the incoming and outgoing TLS I/O buffers in such a way that both are capable of holding the specified amount of plaintext data, regardless of the protection mechanism used. To configure incoming and outgoing I/O buffers separately, use #MBEDTLS_SSL_IN_CONTENT_LEN and #MBEDTLS_SSL_OUT_CONTENT_LEN, which overwrite the value set by this option. Uncomment to set the maximum plaintext size of both incoming and outgoing I/O buffers. \def MBEDTLS_SSL_IN_CONTENT_LEN Maximum length (in bytes) of incoming plaintext fragments. This determines the size of the incoming TLS I/O buffer in such a way that it is capable of holding the specified amount of plaintext data, regardless of the protection mechanism used. If this option is undefined, it inherits its value from #MBEDTLS_SSL_MAX_CONTENT_LEN. Uncomment to set the maximum plaintext size of the incoming I/O buffer independently of the outgoing I/O buffer. \def MBEDTLS_SSL_OUT_CONTENT_LEN Maximum length (in bytes) of outgoing plaintext fragments. This determines the size of the outgoing TLS I/O buffer in such a way that it is capable of holding the specified amount of plaintext data, regardless of the protection mechanism used. If this option undefined, it inherits its value from #MBEDTLS_SSL_MAX_CONTENT_LEN. It is possible to save RAM by setting a smaller outward buffer, while keeping the default inward 16384 byte buffer to conform to the TLS specification. The minimum required outward buffer size is determined by the handshake protocol's usage. Handshaking will fail if the outward buffer is too small. The specific size requirement depends on the configured ciphers and any certificate data which is sent during the handshake. Uncomment to set the maximum plaintext size of the outgoing I/O buffer independently of the incoming I/O buffer. \def MBEDTLS_SSL_DTLS_MAX_BUFFERING Maximum number of heap-allocated bytes for the purpose of DTLS handshake message reassembly and future message buffering. This should be at least 9/8 * MBEDTLSSL_IN_CONTENT_LEN to account for a reassembled handshake message of maximum size, together with its reassembly bitmap. A value of 2 * MBEDTLS_SSL_IN_CONTENT_LEN (32768 by default) should be sufficient for all practical situations as it allows to reassembly a large handshake message (such as a certificate) while buffering multiple smaller handshake messages. Complete list of ciphersuites to use, in order of preference. \warning No dependency checking is done on that field! This option can only be used to restrict the set of available ciphersuites. It is your responsibility to make sure the needed modules are active. Use this to save a few hundred bytes of ROM (default ordering of all available ciphersuites) and a few to a few hundred bytes of RAM. The value below is only an example, not the default. Allow SHA-1 in the default TLS configuration for certificate signing. Without this build-time option, SHA-1 support must be activated explicitly through mbedtls_ssl_conf_cert_profile. Turning on this option is not recommended because of it is possible to generate SHA-1 collisions, however this may be safe for legacy infrastructure where additional controls apply. \warning SHA-1 is considered a weak message digest and its use constitutes a security risk. If possible, we recommend avoiding dependencies on it, and considering stronger message digests instead. Allow SHA-1 in the default TLS configuration for TLS 1.2 handshake signature and ciphersuite selection. Without this build-time option, SHA-1 support must be activated explicitly through mbedtls_ssl_conf_sig_hashes. The use of SHA-1 in TLS <= 1.1 and in HMAC-SHA-1 is always allowed by default. At the time of writing, there is no practical attack on the use of SHA-1 in handshake signatures, hence this option is turned on by default to preserve compatibility with existing peers, but the general warning applies nonetheless: \warning SHA-1 is considered a weak message digest and its use constitutes a security risk. If possible, we recommend avoiding dependencies on it, and considering stronger message digests instead. Uncomment the macro to let mbed TLS use your alternate implementation of mbedtls_platform_zeroize(). This replaces the default implementation in platform_util.c. mbedtls_platform_zeroize() is a widely used function across the library to zero a block of memory. The implementation is expected to be secure in the sense that it has been written to prevent the compiler from removing calls to mbedtls_platform_zeroize() as part of redundant code elimination optimizations. However, it is difficult to guarantee that calls to mbedtls_platform_zeroize() will not be optimized by the compiler as older versions of the C language standards do not provide a secure implementation of memset(). Therefore, MBEDTLS_PLATFORM_ZEROIZE_ALT enables users to configure their own implementation of mbedtls_platform_zeroize(), for example by using directives specific to their compiler, features from newer C standards (e.g using memset_s() in C11) or calling a secure memset() from their system (e.g explicit_bzero() in BSD). Uncomment the macro to let Mbed TLS use your alternate implementation of mbedtls_platform_gmtime_r(). This replaces the default implementation in platform_util.c. gmtime() is not a thread-safe function as defined in the C standard. The library will try to use safer implementations of this function, such as gmtime_r() when available. However, if Mbed TLS cannot identify the target system, the implementation of mbedtls_platform_gmtime_r() will default to using the standard gmtime(). In this case, calls from the library to gmtime() will be guarded by the global mutex mbedtls_threading_gmtime_mutex if MBEDTLS_THREADING_C is enabled. We recommend that calls from outside the library are also guarded with this mutex to avoid race conditions. However, if the macro MBEDTLS_PLATFORM_GMTIME_R_ALT is defined, Mbed TLS will unconditionally use the implementation for mbedtls_platform_gmtime_r() supplied at compile time.