Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Andrew Archibald (aarchibayahoo.com)
Date: Mon Feb 26 2001 - 18:00:04 CST
I'm implementing an application that uses Diffie-Hellman to do key
agreement. Out of this process comes a shared secret bit string K. I also
have a session ID S made up of all the public data that has been exchanged
fed through a hash function. I need a number of shared secret keys which
should be derived from these values in some way.
How should I generate these secrets?
SSH2 generates them by taking a hash of S || x || K, where x is a single ASCII
letter denoting the function (the first secret, say the client to server
MAC, gets "A", the second gets "B", etc.)
TLS generates them by using its "PRF", which roughly takes K as the key to
an HMAC and feeding it first the seed, then output || seed, then ouput ||
seed. Its secret keys are generated using PRF(K, "master_secret"||S).
In short, they both use hash functions to generate secrets from a master
Is this a good approach (from a cryptographic point of view)? It seems
that what is wanted is a function that will take a small secret and turn it
into a big secret, for which it is infeasible to find the original secret
given any section of the output, and for which it is infeasible to compute
one part of the output given the rest of the output. That sounds like a
stream cipher, except that we have a (potentially) long key (e.g. 1024
I have an approach which resembles the SSH approach implemented now, but
I'm not sure whether another would be better. I already use block
encryption algorithms, so using one in OFB or counter mode wouldn't add new
 If this doesn't generate enough bytes, they generate more by re-hashing
output || K until enough are available.
 In fact, it splits the secret into two pieces and does this process
with SHA-1 for one and with MD5 for the other, then XORs the result.