b. There are low-end environments where performance really does matter. Those often have rather different properties than other environments--for example, RAM or ROM (for program code and S-boxes) may be at a premium.

Such environments are getting very rare these days. For example, an electrical engineer friend of mine was recently working on designing a cheap aimable mirror, to be deployed by the thousands to aim sunlight at a collector. He discovered that connectors and wires are more expensive than processor chips these days! So he ended up deciding to use a system-on-chip with a built-in radio that eliminated the need to have a connector or a wire to each mirror. (You can print the antenna on the same printed circuit board that holds the chip and the actuator.) What dogs the security of our systems these days is *complexity*. We don't have great security primitives to just drop into place. And the ones we do have, have complicated tradeoffs that come to the fore depending on how we compound them with other design elements (like RNGs, protocols, radios, clocks, power supplies, threat models, etc). This is invariant whether the system is "low end" or "high end". That radio controlled mirror can be taken over by a drive-by attacker in a way that would take a lot more physical labor to mess up a wire-controlled one. And if the attack aimed two hundred mirrors at something flammable, the attacker could easily start a dangerous fire instead of making cheap solar energy. (Denial of service is even easier - just aim the mirrors in random directions and the power goes away. Then what security systems elsewhere were depending on that power? This might just be one cog in a larger attack.) Some of the security elements are entirely external to the design. For example, is the radio protocol one that's built into laptops by default, like wifi or bluetooth? Or into smartphones? Or does it require custom hardware? If not, a teenager can more easily attack the mirrors -- and a corrupt government can infect millions of laptops and phones with malware that will attack mirror arrays that they come near to. For products that never get made in the millions, the design cost (salaries and time) is a significant fraction of the final cost per unit. Therefore everybody designs unencrypted and unauthenticated stuff, just because it's easy and predictable. For example it's pretty easy to make the system-on-chip above send or receive raw frames on the radio. Harder to get it to send or receive UDP packets (now it needs an IP address, ARP, DHCP, more storage, ...). Much harder to get it to send or receive *authenticated* frames or UDP packets (now it needs credentials; is it two-way authenticated, if so it needs a way to be introduced to its system, etc). Much harder again to get it to send or receive *encrypted* frames or UDP packets (now it needs keys too, and probably more state to avoid replays, etc). And how many EE's who could debug the simple frame sending firmware and hardware, can debug a crypto protocol they've just implemented (even making the dubious assumpion that they compounded the elements in a secure way and have just made a few stupid coding mistakes)? John _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography