Just wondering about this. Does it need a PKI to work?
An HMAC key is a symmetric key, i.e. a bunch of bytes. The "symmetry" relates to the following important fact: the very same key is used both to produce a HMAC value over some message, and to verify the HMAC value over the message. In that sense, HMAC is not a digital signature algorithm (but some people are nonetheless talking of "signatures" about HMAC, which is both wrong and confusing).
Distributing symmetric keys is a complex endeavour for two reasons:
- A secret value which travels is "less secret" because travel implies extra risks of exposure.
- A secret can remain secret only if not too many people are aware of it. Therefore, if n people must be able to do symmetric cryptography with each other, you more or less need a shared secret per pair of users; so there will be n(n-1)/2 symmetric keys in the whole system.
To make things easier, public-key cryptography was invented. It is also known as asymmetric cryptography; when used with digital signatures, the key used to generate signatures is distinct from the key used to verify signatures; they are mathematically linked to each other, but it is not feasible (or so we hope) to recompute the signature generation key from the signature verification key. Therefore we can afford to make the latter public, hence the name.
Public-key cryptography makes the key distribution problem substantially easier:
- The public keys are public, so confidentiality of transfer is no longer an issue.
- Each user only has one public/private key pair, so there are much fewer keys altogether in the whole system.
Now public-key cryptography makes key distribution easier, not easy. You still have to come up with something which allows user to make sure that they use the right public keys. This is where PKI comes into play: a PKI is a system to distribute public keys.
So how would things go in practice ? Consider SSL/TLS, often used in combination with HTTP, yielding HTTPS. When a Web browser connects to a HTTPS-powered Web site:
- An initial "handshake" procedure is performed, where the server shows his certificate to the client (the browser). This is PKI. The certificate contains the server's public key, and is signed, and that signature is the incarnation of the PKI. The client verifies a bunch of signature and is finally convinced that the public key it sees really is the genuine public key from the intended server.
- Using the server's public key, more asymmetric cryptography occurs (this time a key exchange, possible based on asymmetric encryption, not signatures), which ends up with a nice result: client and server now know a shared secret value, and nobody spying on the line would be able to rebuild that value.
- The shared secret value is then expanded (with a Key Derivation Function) into several symmetric keys, which the client and server will use to encrypt and MAC whatever data they then want to send to each other. In SSL/TLS, the usual MAC algorithm is HMAC.
The complete picture is that PKI is used to distribute public keys, and these public keys are then used with asymmetric cryptography to dynamically create a shared secret, and that shared secret is then used with symmetric algorithms such as HMAC.
So you do not distribute HMAC keys directly with a PKI; there is one intermediate layer.
What I thought, just that I did understand for PKI what you describe in points 1 and 2, rather than just 1. Anyway, good explanation of encryption.– user15194Oct 18, 2013 at 20:56
1Getting back to the question, how do you transmit the HMAC secret key? First you perform bulk encryption of your message with a symmetric algorithm (e.g. AES128). You then encrypt the random AES128 session key with the recipient's public key. The other piece of the implementation is to generate a MAC of the ciphertext, as well as the IV used for symmetric encryption. If HMAC is used, you need to generate a password. How is that password sent to the recipient? Some have suggesting reusing the AES key. Others suggest using the hash of the AES key. You seem to suggest using PBKDF to generate it.– Ian BoydMay 8, 2015 at 1:19
Would not it be easier to encrypt the password with the public key of the recipient? Dec 28, 2016 at 20:29