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 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

With RSA you can safely transmit n-1 bytes of entropy based on the size of the key chosen. Thus a 2048bit RSA key can encrypt 2047bits of data, which more than enough for a pair of key/nonce/hmac. Stretching entropy with a message digest function should be avoided, however there is more than enough entropy to go around so long as the RSA message isn't padded. The first step is to split the 2047 bits of entropy in half and hash the results:

hashed_entropyA=SHA2-512(entropy[0:1023])
hashed_entropyB=SHA2-512(entropy[1024:2047])

The first set:

encrypt_keyB = hashed_entropyB[0:32]
encrypt_nonceB = hashed_entropyB[32:48]
hmac_keyB = hashed_entropyB[48:64]

The second set:

encrypt_keyA = hashed_entropyA[0:32]
encrypt_nonceA = hashed_entropyA[32:48]
hmac_keyA = hashed_entropyA[48:64]

The results are independent and strong form of key derivation such that two parties can communicate. One side of the communication can be compromised without the entire system being compromised. Defense in depth, security in layers.

Answer 2

Answer to your specific question: There's an easier way to tweak their scheme to achieve what you have in mind. Go with what's in the book, except make the following modification:

hashed_entropy = SHA2-512(0 || entropy) || SHA2-512(1 || entropy)

so that hashed_entropy now contains 128 bytes. Now use the first 64 bytes for the Bob->Alice direction (e.g., extracting keys and nonce as in the book), and the next 64 bytes for the Alice->Bob direction (similarly, extracting keys and nonce).

(Here I write || for the concatenation of two byte-sequences.)

Important cautionary note: This scheme does not authenticate Bob. It is not suitable for use in environments where mutual authentication is expected or required.

High-level comment: I tried to answer the specific question you asked. However, I would be negligent if I stopped there. Are you sure you are asking the right question? Are you sure you need to implement your own way of building a secure (encrypted, authenticated) channel?

While Practical Cryptography is a fantastic book, I'd be pretty reluctant to use a custom design, even one taken from that book, unless I had no other choice. If it were me, I would first make a serious attempt to reuse some well-vetted, widely-deployed design, e.g., TLS. Only if that completely failed to meet my requirements would I then consider doing something custom.

My criticism has nothing to do with the quality of Practical Cryptography, but rather with the broad variety of things that can go wrong if you design and implement your own secure channel (including, e.g., subtle implementation flaws that can be introduced).

Answer 3

What you want is a Key Derivation Function: a KDF takes as input a "master key" (here, your "entropy" string) and produces as many bytes as you need for your symmetric cryptography. A single hash function call is a crude KDF which produces as much output as the hash function output size, i.e. 64 bytes for SHA-512.

Many protocols include a custom KDF. E.g., in SSL/TLS, the "PRF" function (defined in section 5) is a construction using the underlying hash function (usually SHA-256 for TLS 1.2) within HMAC, repeatedly. Another standard KDF is PBKDF2 (section 5.2). Actually any good stream cipher would be a decent KDF (see the eSTREAM Project for some good stream ciphers).

Another option would be to be less wasteful with your key material. From the names you give to the derived elements ("encrypt_key", "encrypt_nonce", "hmac_key"), I surmise that you wish to symmetrically encrypt things, with a keyed integrity check. Symmetric encryption and MAC together are not an easy task; there are many hidden pitfalls. The smart thing is to use an Authenticated Encryption mode for a block cipher. An AE mode combines symmetric encryption and integrity check, and internally handle its own KDF. I suggest EAX. Such a mode only requires a "nonce": that's an IV with only one requirement, i.e. not to be used twice with the same key. This would yield the following protocol:

• Bob obtains some bytes M from a PRNG (at least 16 bytes).
• Bob encrypts M with Alice's public key; Alice will use here private key to get M.
• Both Alice and Bob compute SHA-256(M) yielding a 32-byte string K.
• Afterwards, Bob sends messages to Alice, using K[0..15] as key with EAX mode; the nonce is a message counter (1 for first message, 2 for second message, and so on). The nonce can be appended to each message, or known implicitly by Alice (e.g. the "messages" are successive records on a TCP connection).
• Similarly, Alice can send messages to Bob, using K[16..31] as key with EAX mode.

And there you are: only 256 bits worth of initial key material required, so a simple hash function invocation will be fine; no clunky KDF needed.

But, really, that's just reinventing SSL. That's fine for research / educational purposes, but, for anything which is meant to be deployed in practice, you really should stick to standard protocols where security issues and implementation hurdles have already been (painfully) reconnoitred. Did I mention SSL ?