| [1] This is also my solution to the famous trust paradox proposed by Ken | Thompson in his " Reflections of Trusting Trust". Trust is earned, not | given. To trust Ken's code, I would first ask two or more programmers (who | I choose) to code the same function and submit their codes to tests. If they | provide the same answers for a series of inputs, including random inputs, | I would have a qualification for trusting (or not) Ken's code. This works | even without source code. Trust is not in the thing, it's how the thing works. The code Thompson describes would produce equivalent outputs[1] for all but a very small number of specially-selected strings. If this test caused you to change your level of trust in the code ... it did you a great disservice. "N-version programming" - which is what you are proposing here - can increase your level of trust against random errors[2], but its of no use at all against a deliberate attack. (Recall the conversation here a couple of months ago about how difficult - to the point of impossibility - it would be to use external testing to determine if a crypto-chip had been "spiked".)
[1] Since Thompson was talking about a compiler, the mapping from inputs to outputs is a partial function. Just because two compilers produce different sets of bytes doesn't mean either one is wrong. Determining the equivalence of two programs is a very hard problem; in fact, even *defining* the equiva- lence seems intractable. Suppose the only difference is that the "spiked" compiler introduces enough data-dependent speed variation to leak information through a timing channel? [2] BTW, test have shown that the "random error" model for bugs isn't a very good one. Certain kinds of code are just more likely to contain errors - and the errors produced by completely independent programmers are often quite strongly correlated. So the simple-minded analysis that says that if one program fails with probability p then the chance that of of n different versions fail with probability p^n is way off. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]