HMAC is a hash generated for a string with a key.
HMAC is commonly used with the SHA256 algorithm for a secured signature to reduce the chances of brute-force attacks. The HMAC is a kind of symmetrical signing where both the signer and the validator are required present the same key.
On the other hand, public-key cryptography is asymmetrical, where the signer uses a private key, and the validator uses a public key.
Whether to send a webhook notification or to redirect the browser on the end-user side, we need to have a validation mechanism to enable the system to confirm where the request initially came from. The most common and fastest way of achieving so is by generating a random string that is exchanged between two systems so that both systems can validate the same signature.
There is no right or wrong way to verify the validity of a message.
However, using a random string hashed with SHA 256 posed a real challenge for both parties in ensuring its confidentiality. Imagine the worst-case scenario where the key is leaked: an attacker can disguise or act like a legit system to fool the recipient.
In layman’s terms:
Imagine you are shipping a box containing an iPhone 14, where you protect the package with a password (e.g., 123456). A delivery guy opened your package, and to his luck, he guessed the password and replaced the iPhone 14 with an outdated iPhone 10. Nobody can tell whether the parcel has been tempered by the delivery guy.
You may set a more complex password to prevent brute-force attempts and send it via a different shipment. To the delivery guy’s luck, he may be the same person to deliver both shipments, and he manages to steal the password. Then, how?
Here is when public key cryptography comes to the rescue.
Instead of relying on the same key for encryption and decryption, you should protect it with a public key. The package can only be opened with a private key (which means we should ask for the recipient’s public key before shipping the iPhone 14 out).
HMAC-way example
Here is a technical example where System A & System B did exchange a string (AABBCCDDEE) that is used as a signing key for HMAC (SHA256):
System A: Send “Hello” to System B
Message: Hello
Signature: 38ba3415f85d1546e65b8f464d676ca5e28452522eb4ed73ba5db9f4284e8a9dSystem B: Receive “Hello” and validate the signature. This system recognizes that the Hello message comes from System A as the hash generated using the key exchanged prior is matched.
<?php
$message = “Hello”; //received from System A
$signature = “38ba3415f85d1546e65b8f464d676ca5e…”;
$key = “AABBCCDDEE”; // exchanged key
$signature_gen = hash_hmac('sha256', $message, $key);
$signature == $signature_gen // returns trueThe real issue arises when the key (AABBCCDDEE) is leaked. Attackers can disguise themselves as System A, and System B has nowhere to tell if the subsequent message did come from any attacker.
E-commerce websites are prone to this risk, especially on the payment notification sent by the payment gateway system to the e-commerce website for the order status update (paid). Once the attacker steals the key (AABBCCDDEE), the attacker can fool the e-commerce website, which may result in revenue losses for the business.
How CHIP mitigates this risk?
There is good news!
There is no such issue when using a public key cryptography mechanism. Since the public key is meant to be publicly distributed, there is no security concern in the event of a leak of the public key.
The public key is used to digitally validate the message sent by CHIP where in the event of a leak, the attacker still could not impersonate CHIP since it requires the attacker to hack the CHIP system too.
Public-key cryptography example
Here is a technical example where CHIP (as a payment system) & Lasada (as an e-commerce website) communicate with a public key cryptography.
CHIP: Send “Hello” to Lasada
Message: Hello
Signature: sjNW0vmlCxwFu2IECHPBIZGBbgstQQCGwJOEc9IzA6cMRUV5FvD8a17H78aS/6vzt4x4JDP96IiNQd9W2qGkpu4zpfSTWuS+PBp3oblmQlWnBqZnog/GXWG+jI9sDBmYSOx5GkjOliOh98m1HC7NG8+KmSB1fKp5lZSXDQ+CgjmPoYRONwy83IbzOTIQGzNirSOWZUVZtbqfBkFVRhbrd2apN2ngJ4XLfAivKDrg4LIDuUBb308/KYGrRv8wduUVL3yducNRsfoY6ejKqO/9OTjDU9A6/VU9jAiUdAVDn30KKQ3U66Z1pQ/yUYJtDqjBFGeYetfDA6C7AlEcNVRaiQ== Lasada: Receive “Hello” and validate the signature. This system recognizes the Hello message from CHIP as the signature generated using the private key against the public key.
Key takeaways
- Public-key cryptography shall be implemented earlier than you thought.
- As the name suggests, public keys are meant to be publicly distributed, yet there is no risk of exposing those keys.
- Public key cryptography reduces the risk of a leak from two to only one party.
Conclusion
Even though the use of public key cryptography seems promising, no one rule fits all since it requires relatively more computing power compared to HMAC.
Hence, if you are building an application where both systems are controlled by you, HMAC might be the best bet. However, if it involves a third party, it is best to implement a public keys method, as we can never be sure how well the other party manages the safekeeping on their end.
A simple comparison between HMAC and public-key cryptography
| HMAC | Public-key cryptography | |
| Type | Symmetrical | Asymmetrical |
| Encryption | Yes | Yes |
| Decryption | No | Yes |
| Signing a message | Yes | Yes |
| The provider side accidentally exposed the key | Requires key reset on both sides | Requires key reset on both sides since the provider is using a private key |
| The user side accidentally exposed the key | Requires key reset on both sides | No. Because the user side is using a public key, and that key is meant to be publicly distributed |
| Requires exchange before transaction | Yes | Typically, no (depending on who signed the public key) |
| Key safe to be transmitted programmatically | No | Yes, since it is meant to be publicly distributed |
| Lightweight (use less computing power) | Yes | No |
Featured image credits:
We’re always open to content contributions from our community. Join our Facebook Group and share your work or topic ideas to potentially be featured on our blog.
Moreover, if you have suggestions for our upcoming features, we’d love to hear them! Share your Wishlist with us.
Don’t forget to like and follow us on our social media platforms if you haven’t yet. You can find us on Facebook, Twitter, Instagram, and LinkedIn. We appreciate your support! 🙂
