# Multiplication instead of Key Derivation Function?

### context

In a one message communication. We are right after 2 DHKE (instead of one). Both users then have 2 secret numbers, J and K.

### question

Is it a risk to replace the use of a Key Derivation Function with a multiplication of the form S=J**K, creating a big number and only use the bits we need to exchange the only message that conversation needs using a xor operation between S and the message?

Thanks

## edit:

After generating the arrays of solutions, that idea is definitely BAD for even values of J and if you don't truncate the first bits. Many numbers have a bias and large contiguous 0s are happening. Other than that, it really seems random.

## edit2:

"Other than that, it really seems random.". Let me rephrase it: if you are not using even values, no bias occur and the generated number really seems random and completely unrelated to previous values.

• "Many numbers have a bias and large contiguous 0s are happening. Other than that, it really seems random." Uh, "other than that*? For cryptographers, there is no after that if a supposedly random number has bias or large contiguous zeros :) Jan 21 '19 at 18:13
• @MaartenBodewes: Right. The bias occur on even values. Not on odd ones. My phrasing is not correct but the algorithm seems to be. I will keep testing huge values over the night. I will put the algorithm online. people will be able to try it if they wish. Edited the question. Jan 21 '19 at 19:10

Is it a risk to replace the use of a pbkdf function with a multiplication of the form S=J**K, creating a big number and only use the bits we need to exchange the only message that conversation needs using a xor operation between S and the message?

One concern I would have would be a possible bias in the bits of $$S$$; at the very least, the lsbit of $$S$$ would be 0 with probability 0.75; if you use that to xor with the message, that would mean that the attacker would learn some probabilistic information about that bit.

In addition, if you encrypt the message without doing any sort of integrity protection, that means that the attacker can modify the encrypted message (for example, by flipping bits within the ciphertext) which would yield predictable changes in the decryption of the modified message.

I would suggest that you stick with conventional wisdom when implementing your system; for example, you might want to use:

$$S = \operatorname{SHA-256}( J \mathbin\| K )$$

(possibly along with nonces that are exchanged along with the DH negotiation), and then use $$S$$ as a key to AES-GCM, which encrypts the actual message.

• My idea is so bad it is laughable. See my edit and thanks for your help Jan 21 '19 at 10:44