From 7ec367ffc169dc42b76f3f222c4f9f3842f5e1ed Mon Sep 17 00:00:00 2001 From: "Christoph M. Wintersteiger" Date: Wed, 20 Feb 2019 18:12:09 +0000 Subject: [PATCH] 3rdparty: don't claim armcc support in Everest Readme.md --- 3rdparty/everest/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/3rdparty/everest/README.md b/3rdparty/everest/README.md index aa7d04d46..0e2546662 100644 --- a/3rdparty/everest/README.md +++ b/3rdparty/everest/README.md @@ -2,4 +2,4 @@ The files in this directory stem from [Project Everest](https://project-everest. This is a formally verified implementation of Curve25519-based handshakes. The C code is automatically derived from the (verified) [original implementation](https://github.com/project-everest/hacl-star/tree/master/code/curve25519) in the [F* language](https://github.com/fstarlang/fstar) by [KreMLin](https://github.com/fstarlang/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, clang, or arm-cc, and Visual C (2010 and later). +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).