Digital Signature vs. HMAC with key via DH

I am writing an application that heavily uses cryptology. Like most networked applications, mine breaks up data into different types of messages (instant message, file chunk, video frame, etc.) -- and each one must be checked for authenticity both for anti-tampering and correct origin. So far, I am able to use ECDH to negotiate a shared secret which I use already for AES. Of course, that same shared secret can be used later.

My question is: In this case, is there any added benefit to using ECDSA in order to sign each message, rather than simply using the shared secret established by ECDH with a HMAC?

Below, when I say M, I mean either an encrypted message or plaintext; it shouldn't matter. Please correct any errors below.

I understand that in ECDSA (or DSA) typically hashes a message (M) with a secure hashing algorithm (I am currently using one of the SHA-2s) to make H(M), then encrypts the H(M) using the signer's private key. This produces R and S integers (the signature).开发者_运维知识库 Then, M, R and S are sent to the recipient, who is already in possession of the sender's public key. H'(M) is calculated, and the signature is verified using R and S. BouncyCastle provides ECDSASigner which implements this.

In HMAC, a shared secret is required, which I have. Then:

HMAC(K, M) := H( f2(K) || H(f1(K) || M) ) (Thanks for the correction, Paŭlo Ebermann. See his answer for details.)

So, considering that DH/ECDH negotiate a shared secret securely, is there a reason I shouldn't use HMAC?

Related: why does the NSA specify a standard algorithm for DSA and not MAC? Just because it can be SHA-2 + AES?

Speed is important here because I want this one protocol that I'm making to support not only text messages now, but also large files and video frames in the near future. Therefore I prefer using an HMAC but want to make sure I can meet the goals above.

Thanks for your help!

---

One disadvantage of DSA is that you need quite some good random bytes for your signature. It is even the case that using a bad random source your private key can be reconstructed from the signature. For a MAC, you have to sign lots of messages, so you need lots of random numbers. If you have no hardware producing these, you will run out of entropy.

HMAC does not need any random numbers (it is deterministic).

Additionally I think HMAC will be more efficient than using DSA here, but you could (and should) measure this.

---

About "correct errors": Your description of HMAC is not quite right - there is no "decryption". It is more like this:

You have the message M, a hash function H, and a shared secret K. Add two public functions f1 and f2 (these are some simple XOR+padding). Then

HMAC(K, M) := H( f2(K) || H(f1(K) || M) )

with || being simple concatenation. The sender and receiver do the same calculation, the sender sends his one with the message, and the receiver then compares his result with the sent one. (Make sure you do your comparison in a way which does not allow timing attacks, i.e. compare everything, even if you already found it does not match.)

The exact definition of HMAC is in RFC 2104, which also contains some clarifying figures.

---

About this question:

Related: why does the NSA specify a standard algorithm for DSA and not MAC?

I'm not really sure, but here is one idea:

The list of links there mentions the "Galois Counter Mode" for TLS (RFC 5288) and SSH (RFC 5647), and this is said to protect both confidentiality and integrity in one. Thus a separate MAC is not necessary anymore. (It's the first time I read this, so I can't judge this right now.)