In a system that uses HMAC for a number of different applications, it is important to use different keys for different applications.  Suppose:there is just a single random string available (50 bytes long, in this case) we are using HMAC-SHA1 we will shorten keys longer than the blocksize using SHA1 (as per RFC 2104)Is it safe to generate unique keys by prefixing the application name to the secret, so that the key for application 1 ends up as SHA1(application1 + secret) and the key for application 2 ends up as SHA1(application2 + secret)? The strings application1 and application2 are not kept secret. Or does this open up significant weaknesses compared to using completely different secret keys for each application?Thanks.
Creating HMAC keys using a fixed prefix and a random string
cr.crypto security
Your idea sounds reasonable, at least in theory (and that's what we do here, right? :)A standard way to justify and analyze a design decisions like this is via the random oracle model (ROM) methodology.  Bellare and Rogaway (CCS'93) gave a nice description of ROM analysis, and are generally credited with suggesting that it be applied in practical cryptography.  In the ROM, one pretends that the function SHA1(.) isa truly random function that is available to everyone through an oracle.  Of course, this is never true in reality because SHA1(.) is defined by a publicly-known algorithm.  Nevertheless, ROM analysis seems to be an excellent tool for verifying that protocols and algorithms do not have certain structural weaknesses of the sort you should be worried about.Usage of the ROM is sometimes regarded as a heuristic that theoretically results in a security weakness.  In your situation, you could alternatively justify your design by assuming that the keyed function $F$, defined by$F_K(x) = SHA1(x||K)$,is a secure pseudorandom function.  Now, this is an assumption that has a reasonable shot at being true, unlike the situation with pretending that SHA1 is a ROM.  Either way, we are searching for some way to justify that each of the HMAC keys you generate will look uniformly random and independent to an adversary. After that step, we could give a standard reductionist/provable security analysis of HMAC composed with your key derivation step.(I'm ignoring issues with input/output lengths not fitting together, and so on.  To do this right in a product you'd have to be much more careful about all of this than I have been.  Lower-level errors can mess everything up.)