| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Currently supported is x86/x64 via cpuid() for some common features.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With OpenSSL commit 929b0d70c19f60227f89fac63f22a21f21950823 setting an empty
key fails if no previous key has been set on that HMAC.
In 9138f49e we explicitly added the check we remove now, as HMAC_Update()
might crash if HMAC_Init_ex() has not been called yet. To avoid that, we
set and check a flag locally to let any get_mac() call fail if set_key() has
not yet been called.
|
|
|
|
|
|
|
|
|
|
|
| |
sem_init() is deprecated on OS X, and it actually fails with ENOSYS. Using our
wrapped semaphore object is not an option, as it relies on the thread cleanup
that we can't rely on at this stage.
It is unclear why startup synchronization is required, as we can allocate the
thread ID just before creating the pthread. There is a chance that we allocate
a thread ID for a thread that fails to create, but the risk and consequences
are negligible.
|
|
|
|
| |
The library makes use of htons/ntohs().
|
|
|
|
|
| |
As we make no use of htonl() and friends, this is unneeded, but actually
prevents a Windows build.
|
|
|
|
|
| |
get_replay_state() always returns a replay_state_len when returning a
replay state, but GCC doesn't know about that.
|
|
|
|
|
| |
When building with C11 support, TIME_UTC is used for timespec_get() and
defined in <time.h>. Undefine TIME_UTC for our own internal use in asn1.c.
|
| |
|
|
|
|
|
| |
This was implicitly done by the seed length check before 58dda5d6, but we
now require an explicit check to avoid that unsupported use.
|
|
|
|
|
| |
Append mode hardly makes sense for the special stateful FIPS-PRF, which is
different to other PRFs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If some partial data has been appended, a truncated key gets invalid if it
is calculated from the pending state.
|
|
|
|
|
|
|
| |
The user might have done a non-complete append, having some state in the
hasher.
Fixes #909.
|
|
|
|
|
| |
While that use is uncommon in real-world use, nonetheless should HMAC set a
correct key and reset any underlying hasher.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fixes 80322d2cee75 ("Split IF-TNCCS 2.0 protocol processing into
separate TNC client and server handlers").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to fix usage stats sent via RADIUS Accounting if clients
use MOBIKE or e.g. the kernel notifies us about a changed NAT mapping.
The upper layers won't expect the stats to get reset if only the IPs have
changed (and some kernel interface might actually allow such updates
without reset).
It also fixes traffic based lifetimes in such situations.
Fixes #799.
|
|
|
|
|
|
| |
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
|
|
|
|
| |
Fixes Quick Mode negotiation when PFS is in use.
|
| |
|
| |
|
| |
|