On Wed, Jun 14, 2006 at 08:52:01PM -0700, Wolfgang S. Rupprecht wrote: | > So what if one of the driver writers for one of the open source operating | > systems were to design a set of open standards for a hardware/software | > interface for chipsets in this class. | | I guess the part I don't understand is why are open source folks so | wary of running black-box *.o binaries from a vendor but are quite | eager to use blackbox crypto cards (that effectively run blackbox *.o | firmware)?
Don't assume that everyone is even willing to hand over their private data to some "sealed black box". There are, of course, a number of differences. What runs on the card/chip generally won't have access to the rest of the system (assuming reasonable bus security, which may not be true). But a *.o binary driver will have that access to the level it is installed (probably the kernel, which means it has access to everything). Bugs in the *.o could crash or hang the kernel if it is there. But in the card/chip it is less likely to cause damage, although that isn't impossible (could lock up the bus). I'd be a bit more trusting of a crypto device that was connected via some soft means like an ethernet. But that still implies a (possibly misplaced) trust in the ethernet card itself. Then there is the issue of whether they provide kernel level *.o files for all the platforms OpenBSD and other systems support. | While I don't think these cards really do contain trojans, they | certainly could at some point in the future. What prevents the | manufacturers from storing all keys into some on-chip nv-ram for later | retrieval? Ditto for the card intentionally leaking the keying data | into the cipher stream? At one point during the cold-war it certainly | seemed like the US did manage to slip a leaky key trojan into a well | respected company's cipher system. Similar risk could exist in CPU based crypto instructions, too, if such a CPU were to be made public. Ultimately, I'll personally depend on crypto in software I can access for myself. I think that's your real point. FYI, I don't even trust Theo for writing safe crypto software. But that's not a personal statement ... it's just a statement of procedure; I would not trust anyone, period. The big advantage of open source that we all already know is the "many eyes (with no conflict of interest)" aspect. That cannot be said for either binary software or hardware implementations. What interests me among Hifn's chips are not the crypto capabilities, but the compression capabilities. No export regulations for that as long as it doesn't have the crypto in it, so those should be fully open (I have not checked) as to interface and interoperability (e.g. uses a standard compression format). Even data compression in a sealed box has risks, such as it detecting actual keys being moved around in the clear and saving them into NVRAM. How do you know your CPU doesn't have this?
