This commit is a follow up to Ryman's report (#85) of a potential timing attack
that could be leveraged against fwknop when strncmp() is used to compare HMAC
digests. All strncmp() calls that do similar things have been replaced with a
new constant_runtime_cmp() function that mitigates this problem.
Lots of places in the code were already using {0} to initialize stack char
arrays, but memset() was being used as well. This commit removes all
unnecessary memset() calls against char arrays that are already initialized
via {0} (which sets all members to zero for such arrays).
This commit fixes a couple of overflow conditions for Rijndael and HMAC keys
that are larger than anticipated maximums. In the case of Rijndael, PKCS#5 1.5
is supported up to key sizes of 32 bytes or smaller (and maintains compatibility
with OpenSSL, and future versions will support PKCS#5 2.0 (PBKDF2) while allowing
for larger key sizes. HMAC keys may be up to 128 bytes even for digest
algorithms such as SHA256 that have block sizes that are smaller than this.
This is a fairly significant commit that lays the groundwork for getting
selectable HMAC modes working for both the client and server. One libfko API
change was required so that the hmac_type is passed into fko_new_with_data().
This allows the server to set the hmac_type via access.conf stanzas. The
effort in this commit will be extended to allow HMAC MD5, SHA1, and SHA512
also function properly.
Now that encryptions keys and hmac keys may be acquired from /dev/random with
--key-gen (and base64 encoded), they may contain NULL bytes. This emphasizes
the need to not leverage code that assumes C-style strings when making use of
key information.
