apidoc: Set QUIET to YES, suppressing any parsing/generating status output

As WARNING messages still get printed, this makes spotting any warnings much
simpler.

apidoc: Enable documentation of static functions

As we scan for header files only, this does not affect any local functions,
but documents any static inlines we define in header files.

strerror: Move to its own Doxygen subgroup

utils: Clean up includes

align: Move min/max/padding/alignment functions to separate files

time: Move time related functions to separate files

object: Move OO programming helper macros to a separate header file

status: Move status_t type and functions to separate files

path: Move path related utility functions to separate files

tty: Move tty related functions to separate files

memory: Move memory manipulation related functions to separate files

string: Move string related utility functions to separate files

byteorder: Move byte order related functions to separate header file

types: Use generic type definitions to separate header file

atomics: Move atomics/recounting support to separate files

unit-tests: Further increase the test vector testing timeout

Some build bots running make check seem to have longer for the DH testing.

test-vectors: Define test vector symbols as extern

We don't actually define a vector, but only prototype the test vector
implemented in a different file. GCC uses the correct symbol during testing,
but clang correctly complains about duplicated symbols during linking.

Fix years in some copyright statements

aesni: Fix doxygen groups

Merge branch 'dh-test-vectors'

Add a Diffie-Hellman backend test method, a set of test vectors and implement
testing of the gmp, openssl and gcrypt DH backend.

kernel-netlink: Don't mangle verbosity during test initialization

We now properly manage thread verbosity in the test framework, and don't need
to silence thread spawning messages.

unit-tests: Set test verbosity just after test suite loading

We see any plugin startup messages during suite configuration, where
initialization is called once to query plugin features. No need to be verbose
and show these messages once again in the first test.

crypto-factory: Remove obsolete transform testing functions

unit-tests: Use progressive testing of transforms with test vectors

This allows us to show which transform from which plugin failed. Also, we use
the new cleanup handler functionality that allows proper deinitialization on
failure or timeout.

transform: Add a getter for the enum_names for a specific transform type

enum-names: Fail gracefully when passing a NULL value as enum names

crypto-factory: Add enumerator method to support individual transform testing

unit-tests: Invoke all registered thread cleanup handlers on test failure

If a test fails in a timeout or a test failure, longjmp() is used to restore
the thread context and handle test failure. However, there might be unreleased
resources, namely locks, which prevent the library to clean up properly after
finishing the test.

By using thread cleanup handlers, we can release any test subject internal or
test specific external resources on test failure. We do so by calling all
registered cleanup handlers.

thread: Add a function to pop and call all registered cleanup handlers

thread: Don't acquire lock for thread_cleanup_push/pop

This is called only by the thread for its own thread_t, and does not need
synchronization.

travis: Run a gcrypt test with leak-detective

And also enable gcrypt in the all tests with leak-detective enabled.

gcrypt: Explicitly initialize RNG backend to allocate static data

The libgcrypt RNG implementation uses static buffer allocation which it does
not free. There is no symbol we can catch in leak-detective, hence we explicitly
initialize the RNG during the whitelisted gcrypt_plugin_create() function.

leak-detective: Whitelist gcrypt_plugin_create()

gcry_check_version() does not free statically allocated resources. However,
we can't whitelist it in some versions, as it is not a resolvable symbol name.
Instead, whitelist our own plugin constructor function.

unit-tests: Add a TESTS_PLUGINS environment variable

This is often more convenient than specifying plugins in a configuration file.

unit-tests: Use a larger timeout for test vector testing

As we test DH calculations this now takes more time. If multiple DH backends
are enabled, we likely hit the default test timeout.

gcrypt: Support setting private value and testing of DH backend

openssl: Support setting ECDH private values

openssl: Support setting private Diffie-Hellman values

gmp: Support setting Diffie-Hellman private values

test-vectors: Add DH vectors for Brainpool groups

test-vectors: Add DH vectors for ECDH groups

test-vectors: Add DH vectors for subgroup MODP groups

test-vectors: Add DH vectors for normal MODP groups

test-vectors: Support testing DH groups

crypto-tester: Support testing DH groups using DH test vectors

diffie-hellman: Introduce an optional setter for the private value

This allows us to work with deterministic values for testing purposes.

Merge branch 'aesni'

Add an aesni plugin providing CBC, CTR, XCBC, CMAC, CCM and GCM modes for
for AES-128/192/256 based on AES-NI/PCLMULQDQ intrinsics.

NEWS: Add aesni plugin news

aesni: Avoid loading AES/GHASH round keys into local variables

The performance impact is not measurable, as the compiler loads these variables
in xmm registers in unrolled loops anyway.

However, we avoid loading these sensitive keys onto the stack. This happens for
larger key schedules, where the register count is insufficient. If that key
material is not on the stack, we can avoid to wipe it explicitly after
crypto operations.

aesni: Align all class instances to 16 byte boundaries

While the required members are aligned in the struct as required, on 32-bit
platforms the allocator aligns the structures itself to 8 bytes only. This
results in non-aligned struct members, and invalid memory accesses.

utils: Provide aligning variants of INIT/INIT_EXTRA macros

unit-tests: Pass stringyfied assertion statement as non-format string argument

If the assertion contains a modulo (%) operation, test_fail_msg() handles
this as printf() format specifier. Pass the assertion string as argument for
an explicit "%s" in the format string, instead.

utils: Add malloc/free wrappers returning aligned data

While we could use posix_memalign(3), that is not fully portable. Further, it
might be difficult on some platforms to properly catch it in leak-detective,
which results in invalid free()s when releasing such memory.

We instead use a simple wrapper, which allocates larger data, and saves the
padding size in the allocated header. This requires that memory is released
using a dedicated function.

To reduce the risk of invalid free() when working on corrupted data, we fill up
all the padding with the padding length, and verify it during free_align().

aesni: Calculate GHASH for 4 blocks of associated data in parallel

While associated data is usually not that large, in some specific cases
this can bring a significant performance boost.

aesni: Calculate GHASH for 4 blocks of encryption data in parallel

Increases performance by another ~30%.

aesni: Use 4-way parallel en/decryption in GCM

Increases overall performance by ~25%.

aesni: Use dedicated key size specific en-/decryption functions in GCM

This gives not much more than ~5% increase in performance, but allows us to
improve further.

aesni: Add a GCM AEAD based on the AES-NI key schedule

aesni: Implement CMAC mode to provide a signer/prf

Compared to the cmac plugin using AESNI-CBC as backend, this improves
performance of AES-CMAC by ~45%.

aesni: Implement XCBC mode to provide a signer/prf

Compared to the xcbc plugin using AESNI-CBC as backend, this improves
performance of AES-XCBC by ~45%.

aesni: Partially use separate code paths for different key sizes in CCM

Due to the serial nature of the CBC mac, this brings only a marginal speedup.

aesni: Add a CCM AEAD reusing the key schedule

aesni: Use 4-way parallel AES-NI instructions for CTR en/decryption

CTR can be parallelized, and we do so by queueing instructions to the processor
pipeline. While we have enough registers for 128-bit decryption, the register
count is insufficient to hold all variables with larger key sizes. Nonetheless
is 4-way parallelism faster, depending on key size between ~10% and ~25%.

aesni: Use dedicated round count specific encryption functions in CTR mode

This allows us to unroll loops and hold the key schedule in local (register)
variables. This brings an impressive speedup of ~45%.

aesni: Implement a AES-NI based CTR crypter using the key schedule

aesni: Use 4-way parallel AES-NI instructions for CBC decryption

CBC decryption can be parallelized, and we do so by queueing instructions
to the processor pipeline. While we have enough registers for 128-bit
decryption, the register count is insufficient to hold all variables with
larger key sizes. Nonetheless is 4-way parallelism faster, roughly by ~8%.

aesni: Use separate en-/decryption CBC code paths for different key sizes

This allows us to unroll loops, and use local (register) variables for the
key schedule. This improves performance slightly for encryption, but a lot
for reorderable decryption (>30%).

aesni: Implement a AES-NI based CBC crypter using the key schedule

aesni: Implement 256-bit key schedule

aesni: Implement 192-bit key schedule

aesni: Implement 128-bit key schedule

aesni: Add a common key schedule class for AES

aesni: Provide a plugin stub for AES-NI instruction based crypto primitives

utils: Provide an INIT_EXTRA() macro, that allocates extra data to INIT()

test-vectors: Add some self-made additional AES-GCM test vectors

We missed test vectors for 192/256-bit key vectors for ICV8/12, and should
also have some for larger associated data chunk.

test-vectors: Define some additional CCM test vectors

We don't have any where plain or associated data is not a multiple of the block
size, but it is likely to find bugs here. Also, we miss some ICV12 test vectors
using 128- and 192-bit key sizes.

crypto-tester: Use the plugin feature key size to benchmark crypters/aeads

We previously didn't pass the key size during algorithm registration, but this
resulted in benchmarking with the "default" key size the crypter uses when
passing 0 as key size.

crypt-burn: Support burning signers

crypt-burn: Add a encryption buffer command line argument

crypt-burn: Set a defined key, as some backends require that

crypt-burn: Refactor to separate burn methods

crypt-burn: Accept a PLUGINS env var to configure plugins to load

vici: Relicense libvici.h under MIT

libvici currently relies on libstrongswan, and therefore is bound to the GPLv2.
But to allow alternatively licensed reimplementations without copyleft based
on the same interface, we liberate the header.

utils: Define MAX_(U)INT_TYPE to the maximum size integer type available

utils: Typedef int128_t and u_int128_t types if supported

configure: Check for __int128 type support

Merge branch 'const-memeq'

Introduce constant time memory comparing functions for cryptographic purposes,
and a tool to test such functions or crypto transforms relying on them.

utils: Use chunk_equals_const() for all cryptographic purposes

utils: Add a constant time chunk_equals() variant for cryptographic purposes

utils: Use memeq_const() for all cryptographic purposes

utils: Add a constant time memeq() variant for cryptographic purposes

scripts: Add a tool that tries to guess MAC/ICV values using validation times

This tool shows that it is trivial to re-construct the value memcmp() compares
against by just measuring the time the non-time-constant memcmp() requires to
fail.

It also shows that even when running without any network latencies it gets
very difficult to reconstruct MAC/ICV values, as the time variances due to the
crypto routines are large enough that it gets difficult to measure the time
that memcmp() actually requires after computing the MAC.

However, the faster/time constant an algorithm is, the more likely is a
successful attack. When using AES-NI, it is possible to reconstruct (parts of)
a valid MAC with this tool, for example with AES-GCM.

While this is all theoretical, and way more difficult to exploit with network
jitter, it nonetheless shows that we should replace any use of memcmp/memeq()
with a constant-time alternative in all sensitive places.

Merge branch 'cpu-features'

Centralize all uses of CPUID to a cpu_feature class, which in theory can support
optional features of non-x86/x64 as well using architecture specific code.

sqlite: Use our locking mechanism also when sqlite3_threadsafe() returns 0

We previously checked for older library versions without locking support at
all. But newer libraries can be built in single-threading mode as well, where
we have to care about the locking.

rdrand: Reuse CPU feature detection to check for RDRAND instructions

sqlite: Show SQLite library version and thread safety flag during startup

padlock: Reuse common CPU feature detection to check for Padlock features

cpu-feature: Support Via Padlock security features

cpu-feature: Add a common class to query available CPU features

Currently supported is x86/x64 via cpuid() for some common features.

vici: Defer read/write error reporting after connection entry has been released

If a vici client registered for (control-)log events, but a vici read/write
operation fails, this may result in a deadlock. The attempt to write to the
bus results in a vici log message, which in turn tries to acquire the lock
for the entry currently held.

While a recursive lock could help as well for a single thread, there is still
a risk of inter-thread races if there is more than one thread listening for
events and/or having read/write errors.

We instead log to a local buffer, and write to the bus not before the connection
entry has been released. Additionally, we mark the connection entry as unusable
to avoid writing to the failed socket again, potentially triggering an error
loop.