Thou shalt have no other gods before the ANSI C standard 1566

Different mindsets. Crypto prople tend to regard the channel used as a neat pipe; a well ordered, but insecure, pipe between Alice and Bob, so to speak.The challenge is to acheive secure communications despite tha fact that everyone else can attack the stream.

In software the more prevalent attacks are to attack the pipe itself, and play with Alice's mind; and disregard the top-level security.

Just the point. You break the channel itself by attacks that are rightly labeled 'trivial' in the cryptology mindset. The perimeter between trust and danger is not so well defined, and has exploding complexity.

This is why it has to be lifted out of the programmer's domain and int a systems domain where provable solutions can be applied. This wish is easy to state, but oh so difficult to acheive.

It can be approached on a number of levels. One is to attack the language, and see to it that it cannot produce invalid constructs, or that such are easily flagged.

Others are to accept the channel attacks, but to diminish the prizes. This is what OS support has been doing, disregarding major systems out there.

If the prize is high enough, they are. Like a celebrity's mobile phone compromised.

We do, but it gets lost in the daily grind.

No, we have made loud complaints about how the academic field handles this subject before. The good results are made by a handful of people. Go look at Multics and OpenBSD. These are the only places I know that has attacked this problem in a systemic manner. Be prepared to read source code.

Or, go read some sites with a different colour on the hat. 2600 magazine is a good place to start.

Do you think the bad guys are publishing their results?

There is a huge gulf between academia and the real world here. We knew that. It may be news to the sci.crypt crowd. This may be a little discomforting to them.

-- mrr