[E-Lang] Re: Identity et al [was: ALU capability]
Mon, 22 Oct 2001 08:39:32 -0700
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
>>>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
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 :-)