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%.
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%.
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%).
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.
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.
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.
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.
Since we can't get rid of all unmet dependencies (at least not in every
possible plugin configuration) the message is more confusing than
helpful. In particular because a detailed warning about plugin features
that failed to load due to unmet dependencies is only logged on level 2.
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
Some CAs don't use SHA-1 hashes of the public key as subjectKeyIdentifier and
authorityKeyIdentifier. If that's the case we can't force the
calculation of the hash to compare that to authorityKeyIdentifier in the CRL,
instead we use the subjectKeyIdentifier stored in the issuer certificate, if
available. Otherwise, we fall back to the SHA-1 hash (or comparing the
DNs) as before.
While these files are generated they don't really change and are not
architecture dependant. The previous solution prevented cross-compilation
from the repository as `bliss_huffman` was built for the target system but
was then executed on the build host to create the source files, which
naturally was bound to fail.
The `recreate-bliss-huffman` make target can be used inside the bliss
directory to update the source files if needed.
Fixes#812.
Martin Willi