8

I want to combine two or more keys to create a single encryption key that relies on all of them. What is the proper method for doing that? Simple XOR? Using hash functions? Something else?

I personally used this: k = md5( key1 || key2 ). Note: || means concatenation. I used md5 because I use 128-bit encryption and thus need a 128 bit output key.

Some other questions arise here for me:

  1. Is using MD5 secure for this specific purpose?

  2. I don't know of any other standard 128-bit output hash functions. It seems newer cryptographic hash functions all have 256-bit and more output lengths. So is using another hash function that has a 256/512-bit output and then truncating the result down to 128 bits secure to an equal or more degree than using MD5?

Note that key1 and key2 are random keys, not passwords, and thus key stretching is not relevant or applicable.

If it is relevant, I generated both keys, and I know that both keys are cryptographically random. Neither key was supplied by an untrusted party. At present both keys happen to be the same length, but I'd prefer a more general solution that does not rely upon this assumption, if possible.

D.W.
  • 36,982
  • 13
  • 107
  • 196
H M
  • 293
  • 3
  • 8

4 Answers4

6

If the keys have constant, known length, I'd concatenate them, and then apply SHA256. If they have variable length, applying some separation mechanism might be useful.

Truncating hash functions works well. If the original hash function is good, a truncated hash function has the same properties, albeit at a correspondingly lower security level. Truncating SHA-256 is certainly better than using MD5.

I recommend something like:

Truncate(SHA-256(output-size || number-of-keys || sizeof(key1) || key1 || sizeof(key2) || key2 ...), output-size) where output-size <= 256

CodesInChaos
  • 25,121
  • 2
  • 90
  • 129
2

If I understand your question correctly, you have $n$ keys: $K_0$ ... $K_{n-1}$ and you want to derive a key, $M$ such that:

  • $M$ is 128 bits (16 bytes) in size.
  • $M$ is derived using a deterministic algorithm.
  • $M$ cannot be derived without the knowledge of every $K$.

If every $K$ is 128 bits in size:

$M = K_0 \oplus K_1$ ... $\oplus K_{n-1}$

If every $K$ is smaller than 256 bits in size:

$K_x = K_x || [0x00 * (32 - length(K_x))]$

$K_x = H_{SHA-256d}(K_x)$

$K_x = truncate(K_x, 16)$

$M = K_0 \oplus K_1$ ... $\oplus K_{n-1}$

If every $K$ is larger than 256 bits in size:

$K_x = H_{SHA-256d}(K_x)$

$K_x = truncate(K_x, 16)$

$M = K_0 \oplus K_1$ ... $\oplus K_{n-1}$

Chris Smith
  • 1,202
  • 1
  • 11
  • 18
0

If you have a cryptographic key (K), you can split it into any number of parts (P) using an XOR.

Px = P1 XOR P2 XOR P3 XOR ... XOR Px-1 XOR K

Then destroy the key K, and distribute all parts P.

To retrieve K, just XOR P1 to Px, the result will be the original key K.

Sources:

http://www.nd.edu/~cseprog/proj02/cryptogrophy/final.pdf

http://users.telenet.be/d.rijmenants/en/secretsplitting.htm

Petey B
  • 117
  • 3
-2

the problem with hash-functions such as md5 and sha* are that they were not designed to solve the problem you have: create a cryptographic hard key for further use. they were design to calculate hashes very very fast without having a too high chance of hash-collisions.

what you really want to use is a so called key derivation function. examples for such functions are:

what kind of secrets you pipe into that function to get the actual key is pretty much up to you. the main point of such functions is that it takes relatively long time to calculate the key and thus slowing down brute force attacks quite a bit.

akira
  • 97
  • 3