[E-Lang] Re: Identity et al [was: ALU capability]

[Dean Tribble]

At 09:46 PM 10/20/2001, Mark S. Miller wrote:
>At 09:04 AM 10/19/2001 Friday, Dean Tribble wrote:
>>(e.g., the eq function could be closely held).
>
>If the eq function (or any other object) is closely held, then by definition
>it is not accessible outside the utcb.  Unless it is necessary to refer to
>it in order to explain the semantics of the utcb's exported interface, then
>for all significant purposes (other than a utcb implementors guide), it
>doesn't exist.  Creating objects that are closely held by the utcb is just a
>trick (a valuable one) for partitioning functionality between layers
>internal to the implementation of the utcb.  These objects should not appear
>in any discussion of semantics.

The interesting intermediate case is when it is closely held by code which 
is *not* in the *u*tcb.  For example, it might be available to the comm 
system written in the language, but not to general programs.

>>In programming languages with encapsulation, you have a private data path through scoping.  Once you have numbers, you can build encryption in the language, and this you can have encrypted links.
>
>Where possible, I prefer to treat crypto like I treat analog electronics.
>Both are not certain, but only work with extremely high probability.  For

Same here, but that was not the point I was making, so it's not particularly 
relevant.  You can only send messages across untrusted wires in modern 
hardware with crypto assurance.  Since that can be created in the language, 
there is no need, and probably little value, in requiring it be built into 
the semantics.

>>>I'm also bothered that state and timing are involved in extracting
>>>information.  If the object and/or verifier are slow to respond, and I
>>>get bored waiting for an answer, then that's not a negative answer,
>>>it's an I-don't-know.
>>
>>In a sequential language, there is no issue of timing.  That is introduced by concurrency; it is the introduction of concurrency that must addresses the timing issues.
>
>I don't understand this.

In a sequential language, the verifier process proceeds such that, after the 
challenge from the verifier returns back to the verifier, then either the 
object being tested has stored itself into the secret verification place or 
it didn't.  There is no race, there is no delay, and there is no uncertainty 
about timing.

The "slow to respond" concerns are introduced by concurrency, and are 
completely independent of verifiers.  Thus, I could make perfectly 
legitimate, across the wire request, and have it be slow to respond.  
Nothing to do with verification, but rather with the nature of latency 
exposed by the programming language.  This is a seperate concern and should 
be treated separately.

That's all :-)
dean