as word64 is not always available, introduce an abstract type and companion
operations. They use a word64 if available and fallback on word32[2] otherwise.
Add `WOLFSSL_KEYGEN` option and override enable when `WOLFTPM` is
enabled
Also major reduction of variables for help messages. Override only
updates `VALUE`
This commit adds functions to encrypt and decrypt data using AES in SIV mode, as
described in RFC 5297. This was added in the process of porting chrony to
wolfSSL. chrony is an NTP implementation that can use NTS (network time
security), which requires AES-SIV.
Increasing cmake version required to allow use of more recent
additions in the future.
Reported issue is that Homebrew use different compiler than AppleClang
(from XCode). Correctly test for AppleClang to set xcode specific `ar`
and `ranlib` flags. It may also be appropraite to use for ANDROID as
well see
7d057b2738 (diff-6f7a068f87ca22bd0105fef2143b0960e4993854863fd20c9416c677ee33a737R61-R67)
* Remove NTRU and OQS
* Keep the DTLS serialization format backwards compatible.
* Remove n from mygetopt_long() call.
* Fix over-zealous deletion.
* Resolve problems found by @SparkiDev
For example, if a user does
```
cmake -DCMAKE_C_FLAGS="-DWOLFSSL_AESGCM_STREAM -DFP_MAX_BITS=16384" ..
```
definitions for `WOLFSSL_AESGCM_STREAM` and `FP_MAX_BITS 16384` should wind up
in options.h (same as the autotools build).
Unlike the autotools build, I've chosen NOT to make the build un-deterministic
if WOLFSSL_REPRODUCIBLE_BUILD is set to no (the default). Instead, I just use
whatever CMake's default is. On my system, ar and ranlib run in deterministic
mode by default, and the CMake defaults for the relevant ar and ranlib variables
are:
CMAKE_C_ARCHIVE_CREATE = <CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_APPEND = <CMAKE_AR> q <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_FINISH = <CMAKE_RANLIB> <TARGET>
So my builds are automatically deterministic. This is normal on my system so I
wouldn't want to make them not deterministic by default, hence the decision.
I validated with md5sum on libwolfssl.a that explicitly making the build not
deterministic indeed results in different checksums across multiple runs. The
checksums are the same when flipping back to deterministic mode.
This commit makes all the binary CMake options (i.e. yes/no) conform to one
string convention: "yes/no." Previously, we had a mixture of yes/no and ON/OFF.
