Update to the Yubikey PBA

Security-relevant changes:
 * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation).
 * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user
   (as the PBKDF2 password), so that if two-factor authentication is enabled
   (a) a USB-MITM attack on the yubikey itself is not enough to break the system
   (b) the potentially low-entropy $k_user is better protected against brute-force attacks
 * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random.
 * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte.
   Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64.
 * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte.
   Example: For a luks device with a 512-bit key, keyLength should be 64.
 * Increase of the PBKDF2 iteration count per successful authentication added as the
   parameter "iterationStep", defaults to 0.

Other changes:
 * Add optional grace period before trying to find the yubikey, defaults to 2 seconds.

Full overview of the yubikey authentication process:

  (1) Read $salt and $iterations from unencrypted device (UD).
  (2) Calculate the $challenge from the $salt with a hash function.
      Chosen instantiation: SHA-512($salt).
  (3) Challenge the yubikey with the $challenge and receive the $response.
  (4) Repeat three times:
    (a) Prompt for the passphrase $k_user.
    (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response.
        Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength).
    (c) Try to open the luks device with $k_luks and escape loop (4) only on success.
  (5) Proceed only if luks device was opened successfully, fail otherwise.

  (6) Gather $new_salt from a cryptographically secure pseudorandom number generator
      Chosen instantiation: /dev/random
  (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2).
  (8) Challenge the yubikey with the $new_challenge and receive the $new_response.
  (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b),
      but with more iterations as given by iterationStep.
 (10) Try to change the luks device's key $k_luks to $new_k_luks.
 (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD.
      Note: $new_iterations = $iterations + iterationStep

Known (software) attack vectors:

 * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM
   attack on the yubikey for the $response (1) or the $new_response (2) will result in
   (1) $k_luks being recovered,
   (2) $new_k_luks being recovered.
 * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication
   can recover $k_user, $k_luks, and  $new_k_luks
 * If an attacker has recovered $response or $new_response, he can perform a brute-force
   attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's
   "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's
   luks header and run the brute-force attack without further access to the system.
 * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force
   the yubikey's internal key ("shared secret") without it needing to be present anymore.

Credits:

 * Florian Klien,
   for the original concept and the reference implementation over at
   https://github.com/flowolf/initramfs_ykfde
 * Anthony Thysse,
   for the reference implementation of accessing OpenSSL's PBKDF2 over at
   http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c