Are there any serious problems with this technique for generating symmetric keys?

Question

I'm using a technique borrowed out of a book by Bruce Schneier and Niels Ferguson called Practical Cryptography. Basically, it boils down to this:

---

Bob does this:

pubk_A = Alice's public key

entropy = bytes from cryptographic quality PRNG

encrypted_entropy = RSA_Encrypt_{pubk_A}(entropy)

hashed_entropy = SHA2-512(entropy)

encrypt_key_BA = hashed_entropy[0:32]
encrypt_nonce_BA = hashed_entropy[32:48]
hmac_key_BA = hashed_entropy[48:64]

Bob then sends encrypted_entropy to Alice.

Then Alice does this:

privk_A = Alice's private key

entropy = RSA_Decrypt_{privk_A}(encrypted_entropy)

hashed_entropy = SHA2-512(entropy)

encrypt_key_BA = hashed_entropy[0:32]
encrypt_nonce_BA = hashed_entropy[32:48]
hmac_key_BA = hashed_entropy[48:64]

---

This works great for generating keys that can be used to communicate from Bob to Alice. But I need keys I can use in both directions. I was thinking of modifying the algorithm in this way:

---

Bob does this with entropy:

pubk_B = Bob's public key

hashed_entropy_BA = SHA2-512(SHA2-256(pubk_A) + entropy

encrypt_key_BA = hashed_entropy[0:32]
encrypt_nonce_BA = hashed_entropy[32:48]
hmac_key_BA = hashed_entropy[48:64]

hashed_entropy_AB = SHA2-512(SHA2-256(pubk_B) + entropy

encrypt_key_AB = hashed_entropy[0:32]
encrypt_nonce_AB = hashed_entropy[32:48]
hmac_key_AB = hashed_entropy[48:64]

Alice can do the same thing on her side after she obtains entropy by decrypting encrypted_entropy.

---

As you can see, now there are two sets of keys, one used for communicating from Bob to Alice, and another for communicating from Alice to Bob.

Is there anything wrong with this? What security risks am I taking? Is the security of the system less or more than if I simply had one party tweak a bit in the nonce? Is there a better way to handle this problem without adding round-trips?

Answer 1

There shouldn't be a problem with both Alice and Bob having a shared key for bi-directional communication. In fact this is a lot like SSL/TLS's shared master secret. The only consideration is that you cannot use the same iv+master key combo with any packet. Also this iv must be random.

One improvement that can be made to this Schneier/Ferguson protocol is using cmac mode, which would remove the need for the hmac_key. This would reduce bandwidth used in the handshake and cpu usage for each packet.

In terms of your variant of this protocol. You still have to rely upon transmitting encrypted_entropy = RSA_Encryptpubk_A(entropy). This is an important step because you need to have a shared secret. The use of a known value pubk_A in the key generation bothers me. Keep in mind that it should be assumed that any public key is known to the attacker. The use of sha256 doesn't make this value more random or more difficult to brute force. Thus the number of guesses the attacker has to make is equivalent for these three calculations: sha512(sha256(pubk_A)+entropy),sha512(pubk_A+entropy),sha512(entropy). Which means this is a waste of resources because you are not obtaining an advantage over your attacker.