1
$\begingroup$

Almost every encryption algorithm is based on a secret key. I wonder when the algorithm is considered safe, does that also imply that I can prefix (or suffix) the key with a known value, as long as the unique part is of sufficient size? Just disregarding the fact wether would be wise in the first place.

$\endgroup$
2
  • 3
    $\begingroup$ It's probably a bad idea to use a value like this directly, in that some ciphers may not have been studied under partial key secrecy. At the very least, I would run a key like this through something like HKDF (or even simply a hash function) to evenly distribute the entropy in the key. With that done, the only weakness should be the reduced keyspace. $\endgroup$ Commented Mar 20, 2015 at 22:37
  • 1
    $\begingroup$ @StephenTouset The other plus for a KBKDF is that it can often involve a label (e.g. TLS's PRF), which might fill the role you want to fill with the known prefix/suffix. $\endgroup$
    – cpast
    Commented Mar 21, 2015 at 2:51

1 Answer 1

1
$\begingroup$

Generally, the actual key for most cryptographic algorithms is a fixed length bitstring (or something more complicated, like a tuple of appropriately chosen large numbers). Thus, if you just take a valid key and add a prefix to it, it will no longer be a valid key at all.

(There are a few notable exceptions, such as HMAC, which can use any octet string as a key. But those are definitely the exceptions to the norm.)

So what if your un-prefixed key was shorter than the algorithm needs (but still long enough to resist brute force guessing), and you choose the prefix so that it pads the key to the needed length? Well, clearly you could do that, but depending on the specific algorithm you're using, it might not be a good idea, for several reasons:

  • Even if the algorithm is specified to just take a bitstring of a certain length as its key, that doesn't necessarily mean that every part of the key contributes equally to the security of the algorithm. For example, some authenticated encryption schemes (such as, notably, SIV) take a key which is split into two halves, one of which is used to authenticate the message, and the other to encrypt it.

    Thus, for instance, SIV-AES-128 takes a 256-bit key; if you were to construct one by padding a 128-bit key with a known 128-bit suffix, your messages would be perfectly well authenticated, but totally trivial to decrypt. (Using a known prefix would compromise the authentication part instead, but due to details of the SIV design, that seems a bit trickier to exploit. At least it would make it trivial for an attacker to verify if they guessed the plaintext of a message correctly.)

  • Even if all the key bits are supposed to contribute equally to the security of the algorithm, that's not guaranteed to hold in practice. Many otherwise secure and well-regarded ciphers can be vulnerable to related-key attacks (including AES, although the published attacks against it are, so far, mostly of academic relevance). Such attacks are outside the scope of many commonly used security definitions, and thus may receive less cryptanalytic attention than usual.

Instead, the proper way to expand a too short (or otherwise unsuitably formatted) secret value into a proper-sized key is to run it through a key-derivation function. There are plenty such functions to choose from, but (for applications that do not require key stretching) I personally rather like HKDF (RFC 5896) for its flexibility.

$\endgroup$
3
  • $\begingroup$ It looks like HMAC can even use any bit-string as a key. $\;$ $\endgroup$
    – user991
    Commented Mar 21, 2015 at 2:48
  • $\begingroup$ Since HMAC exhibits weird behaviour with variable length keys, I wouldn't really count it as an exception. $\endgroup$ Commented Mar 21, 2015 at 9:26
  • $\begingroup$ @CodesInChaos: I would. HMAC does have its quirks (like the ability to easily construct equivalent keys of different length), but it's still a secure MAC with keys of any length (even if the nominal security level is capped by the hash output length), as long as they have enough entropy to resist brute force attacks. (That said, if you're using multiple HMAC keys derived from each other, you should probably ensure that they're all the same length, or otherwise that they cannot be equivalent. Using a proper KDF to derive your keys from a single master key is generally enough.) $\endgroup$ Commented Mar 21, 2015 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.