Leichter, Jerry wrote:
I suspect the only heavy-weight defense is the same one we use against
the "Trusting Trust" hook-in-the-compiler attack:  Cross-compile on
as many compilers from as many sources as you can, on the assumption
that not all compilers contain the same "hook". ...
Of course, you'd end up with a machine no faster than your slowest
chip, and you'd have to worry about the correctness of the glue
circuitry that compares the results.

Each chip does not have to be 100% independent, and does not have to be used 100% of the time.

Assuming a random selection of both outputs and chips for testing, and a finite set of possible outputs, it is possible to calculate what sampling ratio would provide an adequate confidence level -- a good guess is 5% sampling.

This should not create a significant impact on average speed, as 95% of the time the untested samples would not have to wait for verification (from the slower chips). One could also trust-certify each chip based on its positive, long term performance -- which could allow that chip to run with much less sampling, or none at all.

In general, this approach is based on the properties of trust when viewed in terms of Shannon's IT method, as explained in [*]. Trust is seen not as a subjective property, but as something that can be communicated and measured. One of the resulting rules is that trust cannot be communicated by self-assertions (ie, asking the same chip) [**]. Trust can be positive (what we call trust), negative (distrust), and zero (atrust -- there is no trust value associated with the information, neither trust nor distrust). More in [*].

Ed Gerck

[*] www.nma.com/papers/it-trust-part1.pdf

[**] Ken's paper title (op. cit.) is, thus, identified to be part of the very con game described in the paper.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to