mbedtls/3rdparty/everest
Chris Kay d259e347e6 Add CMake package config file
This change enables automatic detection and consumption of Mbed TLS
library targets from within other CMake projects. By generating an
`MbedTLSConfig.cmake` file, consuming projects receive a more complete
view of these targets, allowing them to be used as dependencies which
properly inherit the transitive dependencies of the libraries.

This is fairly fragile, as it seems Mbed TLS's libraries do not appear
to properly model their dependencies on other targets, including
third-party dependencies. It is, however, sufficient for building and
linking the compiled Mbed TLS libraries when there are no third-party
dependencies involved. Further work is needed for more complex
use-cases, but this will likely meet the needs of most projects.

Resolves #298. Probably useful for #2857.

Signed-off-by: Chris Kay <chris.kay@arm.com>
2021-06-04 16:02:48 +01:00
..
include/everest 3rdparty: Pull Everest x25519 key size into macro 2019-08-19 13:37:46 +01:00
library Include common.h instead of config.h in library source files 2020-07-02 11:26:57 +02:00
.gitignore 3rdparty: Adjust .gitignore 2019-08-19 13:37:46 +01:00
CMakeLists.txt Add CMake package config file 2021-06-04 16:02:48 +01:00
Makefile.inc 3rdparty: Fix Everest build to not depend on build-time macros 2019-08-19 13:37:46 +01:00
README.md 3rdparty: don't claim armcc support in Everest Readme.md 2019-08-19 13:37:46 +01:00

The files in this directory stem from Project Everest and are distributed under the Apache 2.0 license.

This is a formally verified implementation of Curve25519-based handshakes. The C code is automatically derived from the (verified) original implementation in the F* language by KreMLin. In addition to the improved safety and security of the implementation, it is also significantly faster than the default implementation of Curve25519 in mbedTLS.

The caveat is that not all platforms are supported, although the version in everest/library/legacy should work on most systems. The main issue is that some platforms do not provide a 128-bit integer type and KreMLin therefore has to use additional (also verified) code to simulate them, resulting in less of a performance gain overall. Explictly supported platforms are currently x86 and x86_64 using gcc or clang, and Visual C (2010 and later).