Security is difficult to understand, cryptology doubly so. I recently read a wonderful blog post regarding '[cryptographic "right answers"](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html)'. Seeing as this particular blog came from an expert in the field of cryptology implementation (et al; the [developer of 'scrypt' hashing algorithm](http://www.daemonology.net/blog/2009-05-09-scrypt-key-derivation.html)) and security (former BSD security officer), I thought it would be worth sharing. In his blog he mentions the use of an HMAC for message digest & verification. The problem I can see is in terms of HTTP protocols, or more specifically the header information sent from client -> server & server -> client. Most people utilize headers to embed the HMAC for message verification, for those that are familiar with [network traffic analysis](http://blog.monitorscout.com/2012/04/17/importance-of-monitoring-the-network-traffic-flow/) or signals analysis are familiar with the plain text values available to anyone in the route of the traffic. With hackers sitting on the same network segment implementing a proxy by essentially performing a common attack known as [ARP spoofing](http://www.watchguard.com/infocenter/editorial/135324.asp) this HTTP header value can easily be recalculated based on any inected or modified streams to fool the server/client's into thinking valid traffic has been recieved once a [re-calculation of the HMAC](http://www.wolfe.id.au/2012/10/20/what-is-hmac-and-why-is-it-useful/) has been performed. I know what your going to say.. "why not use TLS/SSL?" My retort is not about using or not using TLS/SSL, as if communication must be secure this is the standard. However TLS/SSL attacks are not uncommon, quite the contrary, please review the following attack vectors regarding encrypted streams; [session renegotiation](http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html), [cipher downgrades](http://f0rki.at/static/slides/f0rki-downgrade-attacks-by-example-bsidesvienna2012.pdf), etc The following code example of a [diffie-hellman key exchange](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) is specific for [node.js](http://nodejs.org/) and really isn't about the key exchange itself. As I mentioned I am more concerned with the message digest & how I can "hide" the [digest](http://en.wikipedia.org/wiki/Cryptographic_hash_function) within the [public key](http://en.wikipedia.org/wiki/Public-key_cryptography) payload to make it more difficult for attackers to forget requests in the event of a [MITM attack](http://en.wikipedia.org/wiki/Man-in-the-middle_attack). Here is a simple module that exposes a simple interface to the [node.js crypto module](http://nodejs.org/api/crypto.html) that can help with a Diffie-Hellman key exchange including the ability to include an HMAC hidden within the payload.