My apologies for summarizing things a little too casually, and thank you for the excellent papers. I'm especially impressed by the cross-campus timing attack in

My apologies for summarizing things a little too casually, and thank you for the excellent papers. I'm especially impressed by the cross-campus timing attack in Boneh. My knowledge of convert channel attacks and timing attacks mostly dates to the 90s. Here's what little I know, for whatever it might be worth: 1. If your crypto primitives take variable time and your attacker can see that, you're hosed. Any encryption system with variable time encryption is useless unless you can somehow quantize it safely. 2. Eliminating covert channels is very nearly impossible. The literature on this goes way back, and it's ugly. Should most users defend against these attacks? The timing attacks, yes. But I would assert that if a hardware encryption module appears to operate in constant time, most users should trust it. But as always, it depends on your threat model. For something like a serious credit card vault, I still think your best bet is to get it off the network, build and audit a custom protocol that only passes a known set of messages, rate limit those messages, and quantize message timings. At that point, your biggest problems are bribery, insiders and physical security. But if you do all that, I can't imagine why you would want to generate your encryption keys using somebody else's black-box hardware. Entropy pools are a good idea, even if you decide to trust your hardware AES implementation. (And yes, I'm still oversimplifying. Hacker News is no substitute for a real threat analysis and security audit, nor for a conversation with whoever regulates or insures your business.)