- Test the same plaintext multiple times. Does it need to be different each time? How much of the MAC is different each time? It might help to explore the data your hashing function spits out as it can tell you how your hash function does what it does.
- Replay it. How can a user abuse identical MAC'd data if they replay it at a later date? For a different user? Can you add items to the plaintext that will allow you to validate not only the data but the source or timeframe as well?
- Ensure your hashes are detecting changes. Is your MAC rejected if you change the data at various places within the message?
- Rotate the key. Do you need a hash to survive a key change? Usually you can just regenerate the data and re-MAC it, so figure out if you really need to use MACs over long lifetimes. They're easy to compute.
- Generate a bunch at once. Is performance an issue with the service? Most hashes are built for speed, but is yours?
Time and again, the past three years have taught me that cryptography must be easy for it to be used widely. I've stayed with Signal for text messaging because it just works. I can invite friends and not be embarrassed at its user interface. It doesn't tick all the boxes (anonymity is an issue being a centralized solution), but it has enough features to be useful and few shortcomings. This is the key to widespread adoption of encryption for securing communications. Since Snowden revealed the extent of the NSA's data collection capability, sites everywhere have switched on HTTPS through Let's Encrypt. Learning more about each implementation of SSH and TLS in the course was both informative and daunting. I was anxious to get HTTPS enabled without rehosting the site on my own. Early 2018, Blogger added the ability to do just that through Let's Encrypt. It requires zero configuration once I toggle it on. I can't sing its praises enough. The content of this blog isn't exactly revolutionary, but this little move toward a private and authentic web helps us all.
Dan Boneh's Cryptography course continues to inform my testing. The core lesson still applies: "Never roll your own cryptography." And the second is how fragile these constructs are. Randomness is only random enough given the time constraints. Secure is only secure enough for this defined application. Every proof in the course is only as good as our understanding of the math, and every implementation is vulnerable at the hardware, software, and user layers. In spite of this, it continues to work because we test it and prove it hasn't broken yet. I'm looking forward to another three years of picking it apart.