[prev in list] [next in list] [prev in thread] [next in thread]
List: cap-talk
Subject: [cap-talk] Retroactive Corroboration for the EQ-less Horton Protocol
From: "Jim Larson" <jimlarson () google ! com>
Date: 2008-02-20 21:56:17
Message-ID: 870755490802201356n6a19799evfe60154c14dac646 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
As promised, I've got a fix for the EQ-less Grant Matcher problem,
and a solution for EQ-less retroactive validation for the Horton
protocol (from Mark Miller's earlier challenge). Both rely on the
same foundation, so let me start with a prelude.
*** Prelude: Tunneling Capabilities Over a Bit Stream
Suppose Alice and Bob can communicate over a bi-directional bit
stream, and Bob has a reference to Carol. Alice and Bob can cooperate
to let Alice create an object "Carol-A" which is behaviorally-equivalent
to Carol, even though Bob can't introduce Alice to Carol in the
Granovetter sense.
Alice and Bob can do this by agreeing on a protocol for serializing
call arguments and return values over the bit stream. This is
mundane for integers, strings, aggregates, etc. Since capailities
themselves cannot be passed over the channel, Alice and Bob will
refer to them indirectly. Each will maintain a counter (starting
at 0) to refer to capabilities that each would otherwise like to
send. Carol will then be known as Bob[0]. If Alice's version of
Carol ("Carol-A") is passed the message "foo(123, Dave, Ed)", where
Dave and Ed are capabilities, then the exchange might go like:
1. Someone makes the call Carol-A.foo(123, Dave, Ed).
2. Alice sends "call[0]: Bob[0].foo(123:int, Alice[0], Alice[1])" over the
bit stream to Bob.
3. Bob creates new objects Dave-B and Ed-B as proxies for Dave and Ed.
4. Bob calls Carol.foo(123, Dave-B, Ed-B).
5. Carol returns a tuple like {true, Fred}, where Fred is a capa.
6. Bob sends "return[0]: {true:bool, Bob[1]}" over the bit stream to Alice.
7. Alice creates a new object Fred-A as a proxy for Fred.
8. The original call returns with the value {true, Fred-A}.
Alice and Bob remember the association between capabilities they've
seen or created and the indices sent over the protocol.
In a system where capabilities cannot be tested for equality, the
proxy objects will be indistinguishable from the originals, and the
bit stream proxying protocol will be equivalent to the actual
exchange of capabilities - as long as Alice and Bob are faithful
transparent forwarders.
Just to be brutally pendantic, let me explain "transparent forwarder".
A proper transparent forwarder behaves as follows:
1) For each call made on the forwarder:
- all data values are transmitted verbatim
for the call arguments and the return;
- all capabilites C for the call arguments and
return, either:
- C is transmitted verbatim, or
- a referece to a transparent forwarder
for C is used.
2) No other calls are made.
"Misbehavior" is anything that's not the proper behavior of a
transparent forwarder, i.e.:
- an extra call is made;
- a proxied call with a change to data values
on the call or the return;
- a proxied call with a change to capabilities
to something that's not a transparent forwarder,
i.e. something that has misbehavied or might misbehave.
*** EQ-less Synergy: Sealer/Unsealer Pairs
As Dean Tribble has previously pointed out, eq-less systems are
capable of surprising tricks, such as the Joule verifier protocol.
Similar methods can give rise to sealer/unsealer pairs. Here is
one way to do it that does not make use of a magic nonce or anything
beyond vanilla Actor semantics.
A sealer and an unsealer are created sharing a common hash table,
mapping tags to (lastChallenge, secret) pairs. The sealer maintains
state to produce unique tags and the unsealer maintains state to
produce unique challenges. When the sealer is given a secret S,
it creates a unique tag T, and stores the entry T => (null, S) in
the hash table, and returns a capability for a box B which knows T
and has a reference to the hash table.
When the unsealer is asked to unseal the box B, it creates a unique
challenge C (though not ncecessarily unguessable - it could be as
simple as a counter) and calls B.challenge(C). When B receives the
challenge, it updates the lastChallenge field of its hash table
entry and returns its tag T. The unsealer then looks up T, and if
the lastChallenge field equals C, the unsealer returns the secret
S to the caller. The protocol is summarized as:
Client Unsealer Box (B) Hashtable (H)
----------- -------------- ---------------------- -------------
U.unseal(B) ->
C = nextChallenge++
B.challenge(C) ->
H.updateChallenge(T, C) ->
<- return ok
<- return T
H.get(T) ->
<- return (C, S)
check C == C
<- return S
Of course, a middle-man might be listening to the traffic between
the unsealer and the box, and might alter the challenge C sent, or
the tag T returned, but the middle man can only prevent the legitimate
unsealing of S, and cannot access any other secrets in the hashtable.
It's possible for Ernie, with access only to the unsealer, and Fred,
with access only to a sealed box, can conspire to unseal its contents
through a bit-stream communications channel (say, by wall-banging).
But as shown above, in an EQ-less system a bit-stream is equivalent
to capability-passing, so this is just equivalent to Ernie and Fred
combining their authority to unseal the object.
[* Well, not entirely. For instance if they know they're dealing
with the first secret sealed by a fresh sealer/unsealer pair, Ernie
and Fred can deduce both the tag and challenge without communication.
They still need to conspire to unseal the secret, though.]
Note if there is a middle-man between the client and the unsealer,
the middle-many may get access to the secret! Because of the
external interface, the unsealing process is only as good as your
reference to the unsealer, which will be important in a minute.
*** The Grant Matcher Broken and Fixed Again
Dean Tribble responded to an earlier challenge from Mark Miller to
do the Grant Matcher problem without EQ. The solution was for the
grant matcher to give a sealed object to one of the references and
an unsealer to the other. Only if both references eventually
bottom-out in the "same object" (or an equivalent cluster of
communicating conspirators) can it be unsealed, giving access to a
box where the canonical reference to the object can be written.
This gives a solution to a general coercive equality protocol.
Except it's broken, since you can only trust an unsealing as far
as you can trust the unsealer. Suppose you have references A and
D, purportedly to the same underlying object C, but A is actually
a nasty mostly-transparent forwarder. You create a sealer/unsealer
pair, seal a secret, send the sealed box B to D and the unsealer U
to A. The hostile proxy A relays not U, but a fake U2 that it
controls. When the underlying object C gets B and U2, it calls
U2.unseal(B). The attacker then has access to both U and B, and
can unseal the secret.
The attack hinges on the fact that the unsealing call U.unseal(B)
gives the purported unsealer the keys to the kingdom. An equivalent
protocol could involve passing the unsealer to the sealed box. In
this case we'd have to trust the sealed box, and D could mount the
same attack above. No matter what we do, the grant matcher and the
underlying charity cannot ever contact each other except through
the untrusted intermediaries, so any capability resulting from any
prtocol between them will be tainted by one untrusted channel or
the other.
However, the we know that the intermediaries don't trust each other
and will not conspire (otherwise there's no problem to be solved!).
We can establish a trusted, capability-carrying channel between the
grant matcher and the charity by using the bit-stream protocol from
the prelude and sending its packets through *both* channels at the
same time. On recepetion, packets are compared for bitwise equality.
No channel can alter the data, or inject new data, without detection.
Capabilities are never passed directly over the untrusted channels.
Instead, each side creates its own local behavioral clones of
capabilities on the other side.
This strategy gives us a better version of EQ-less sealer/unsealers.
You can have untrusted, but non-conspiring, references to the sealer
and unsealer, and tunnel a communication path to the sealed object
without ever sending the raw secret capability along either untrusted
channel.
This strategy can be generalized into any arbitrary method of
validating N copies of a bit pattern. We can have synergy requiring
three or more elements to be brought together instead of two, or a
non-unanimous subset like five out of seven.
Note that this strategy requires that the tunneling persists for
the lifetime of the tunneled reference. As soon as we try to relax
and trust one channel or the other, we're open to an attack. Also
note that the protocol does not provide confidentiality for any of
the data sent over it - it only provides confidentiality for the
capabilities that are *not* sent over it.
*** Retroactive Corroboration in EQ-Less Horton
In a cap-talk message on 2007-10-27, Mark Miller lays down a challenge
for EQ-less capability systems to provide the sort of retroactive
corroboration that's possible with EQ:
Alice tells Carol to provide a separate identity tunnel for
Bob's use of Carol's C. Carol does so. Bob's B makes use of C.
Carol logs these uses, attributing them to Bob. However, so
far, Carol has only heard of Bob from Alice, so Carol hold Alice
responsible for Bob's misbehavior. Later, Carol also hears about
Bob from Dave. Based on Carol's prior relationship with Dave
and what Dave says about Bob, Carol now believes that Bob is
independent of Alice. With join, Carol can only absolve Alice
of Bob's misbehavior after the corroborating introduction. With
EQ, Carol can also retroactively absolve Alice of Bob's past
misbehavior.
I pose this as a new challenge to EQ-less ocaps. Can we generate
either a counter-example or a proof that no counter-example is
possible?
http://www.eros-os.org/pipermail/cap-talk/2007-October/009195.html
In Horton, there's a danger that Alice may introduce Carol not to
Bob, but a puppet version of Bob controlled by Alice. The puppet
layer can then intercept all capabilities sent between Bob and
Carol. To the extent that the puppet layer acts as a transparent
forwarder, it will be undetectable. But Alice can use the puppet
layer to cause misbehavior - to change the data or capabilities
sent on any call or return, or to make new calls on her own.
MarkM points out that in a capability system with EQ, if Carol later
receives another reference to Bob (whoBob) from a trusted source
Dave, or at least a source beleived not to collaborate with Alice,
Carol can EQ-compare the two whoBobs she has, and if they are equal,
she can know that Alice transmitted are real whoBob, and all past
activites on the Horton proxy-stub channel between Bob and Carol
can be attributed only to Bob, and not to Alice.
We can get a similar property without EQ. Let's call the proxy-to-stub
path in Horton a "Horton channel". To provide retroactive
corroboration, the parties in a Horton channel will treat the channel
as a bit stream, using the protocol from the prelude, and also log
the protocol messages they see at their channel endpoint. This log
then serves as an audit trail. (To save space, large data values may
be replaced by a secure hash in the log.)
When Carol obtains an new, Alice-independent channel to Bob, she
can cooperate with Bob to use this channel to audit the previous
traffic sent over the Alice-dependent channel to look for any
misbehavior. Note that Carol needn't trust the new channel entirely
- she only needs to trust that it's independent of Alice, by using
the parallel transmission trick of the previous section.
This plan gives retroactive corroboration of a Horton channel if
there has been no misbehavior. If there *has* been misbehavior,
we don't know who to blame - unlike the case with EQ, where Alice
can show that she gave a correct introduction to Bob and is thus
blameless for any subsequent abuse. This ambiguity is appropriate
- the guilty party might be Alice, Bob, or perhaps some interloper
that's contaminating the Alice-Bob or Alice-Carol channels.
In particular, Bob can lie in the verification protocol, and make
it seem like there has been a discrepency, even if there hasn't
been. So without EQ, newly-introduced parties in Horton can abuse
the relationship until an independent introduction is made.
*** Conclusion
A simple serialization protocol and bit-wise comparison can give us
interesting synergies in an EQ-less capability system. Essentially,
given untrusted references, we can obtain new capabilities whose
mistrust is the intersection of our mistrust in the constituents.
If we trust one path, we can use that path to get trusted versions
of any untrusted capabilities. If we trust neither path, but trust
them to be independent, we can synthesize new, trusted capabilities.
This can all be done with pure Actor semantics.
This seems to be an improvement on the original Joule verifier protocol,
as now we don't even need to trust the verifier!
Jim Larson
[Attachment #5 (text/html)]
As promised, I've got a fix for the EQ-less Grant Matcher problem,<br>and a solution for EQ-less \
retroactive validation for the Horton<br>protocol (from Mark Miller's earlier challenge). Both \
rely on the<br>same foundation, so let me start with a prelude.<br> <br>*** Prelude: Tunneling \
Capabilities Over a Bit Stream<br><br>Suppose Alice and Bob can communicate over a bi-directional \
bit<br>stream, and Bob has a reference to Carol. Alice and Bob can cooperate<br>to let Alice create \
an object "Carol-A" which is behaviorally-equivalent<br> to Carol, even though Bob can't \
introduce Alice to Carol in the<br>Granovetter sense.<br><br>Alice and Bob can do this by agreeing on a \
protocol for serializing<br>call arguments and return values over the bit stream. This is<br> \
mundane for integers, strings, aggregates, etc. Since capailities<br>themselves cannot be passed \
over the channel, Alice and Bob will<br>refer to them indirectly. Each will maintain a counter \
(starting<br>at 0) to refer to capabilities that each would otherwise like to<br> send. Carol will \
then be known as Bob[0]. If Alice's version of<br>Carol ("Carol-A") is passed the \
message "foo(123, Dave, Ed)", where<br>Dave and Ed are capabilities, then the exchange might go \
like:<br> <br>1. Someone makes the call Carol-A.foo(123, Dave, Ed).<br>2. Alice sends "call[0]: \
Bob[0].foo(123:int, Alice[0], Alice[1])" over the<br> bit stream to Bob.<br>3. Bob \
creates new objects Dave-B and Ed-B as proxies for Dave and Ed.<br> 4. Bob calls Carol.foo(123, Dave-B, \
Ed-B).<br>5. Carol returns a tuple like {true, Fred}, where Fred is a capa.<br>6. Bob sends \
"return[0]: {true:bool, Bob[1]}" over the bit stream to Alice.<br>7. Alice creates a new object \
Fred-A as a proxy for Fred.<br> 8. The original call returns with the value {true, Fred-A}.<br><br>Alice \
and Bob remember the association between capabilities they've<br>seen or created and the indices sent \
over the protocol.<br><br>In a system where capabilities cannot be tested for equality, the<br> proxy \
objects will be indistinguishable from the originals, and the<br>bit stream proxying protocol will be \
equivalent to the actual<br>exchange of capabilities - as long as Alice and Bob are \
faithful<br>transparent forwarders.<br> <br>Just to be brutally pendantic, let me explain \
"transparent forwarder".<br>A proper transparent forwarder behaves as follows:<br><br>1) For \
each call made on the forwarder:<br> - all data values are transmitted verbatim<br> \
for the call arguments and the return;<br> - all capabilites \
C for the call arguments and<br> return, either:<br> \
- C is transmitted verbatim, or<br> - a referece \
to a transparent forwarder<br> for C is used.<br><br>2) No \
other calls are made.<br><br>"Misbehavior" is anything that's not the proper behavior of \
a<br>transparent forwarder, i.e.:<br><br>- an extra call is made;<br><br>- a proxied call with a change \
to data values<br> on the call or the return;<br><br>- a proxied call with a change to \
capabilities<br> to something that's not a transparent forwarder,<br> i.e. something that \
has misbehavied or might misbehave.<br><br>*** EQ-less Synergy: Sealer/Unsealer Pairs<br> <br>As Dean \
Tribble has previously pointed out, eq-less systems are<br>capable of surprising tricks, such as the \
Joule verifier protocol.<br>Similar methods can give rise to sealer/unsealer pairs. Here is<br>one \
way to do it that does not make use of a magic nonce or anything<br> beyond vanilla Actor \
semantics.<br><br>A sealer and an unsealer are created sharing a common hash table,<br>mapping tags to \
(lastChallenge, secret) pairs. The sealer maintains<br>state to produce unique tags and the \
unsealer maintains state to<br> produce unique challenges. When the sealer is given a secret \
S,<br>it creates a unique tag T, and stores the entry T => (null, S) in<br>the hash table, and returns \
a capability for a box B which knows T<br>and has a reference to the hash table.<br> <br>When the \
unsealer is asked to unseal the box B, it creates a unique<br>challenge C (though not ncecessarily \
unguessable - it could be as<br>simple as a counter) and calls B.challenge(C). When B receives \
the<br>challenge, it updates the lastChallenge field of its hash table<br> entry and returns its tag \
T. The unsealer then looks up T, and if<br>the lastChallenge field equals C, the unsealer returns \
the secret<br>S to the caller. The protocol is summarized \
as:<br><br>Client \
Unsealer Box \
(B) \
Hashtable (H)<br>
----------- -------------- ---------------------- \
-------------<br>U.unseal(B) \
-><br> C = \
nextChallenge++<br> \
B.challenge(C) -><br> &nbs \
p; \
H.updateChallenge(T, C) -><br> \
&nbs \
p; &n \
bsp; \
<- return ok<br> \
<- return T<br> H.get(T) \
-><br> & \
nbsp;   \
; \
<- return (C, S)<br> \
check C == C<br> <- return S<br><br>Of \
course, a middle-man might be listening to the traffic between<br>the unsealer and the box, and might \
alter the challenge C sent, or<br>the tag T returned, but the middle man can only prevent the \
legitimate<br> unsealing of S, and cannot access any other secrets in the hashtable.<br><br>It's \
possible for Ernie, with access only to the unsealer, and Fred,<br>with access only to a sealed box, can \
conspire to unseal its contents<br> through a bit-stream communications channel (say, by \
wall-banging).<br>But as shown above, in an EQ-less system a bit-stream is equivalent<br>to \
capability-passing, so this is just equivalent to Ernie and Fred<br>combining their authority to unseal \
the object.<br> <br>[* Well, not entirely. For instance if they know they're dealing<br>with \
the first secret sealed by a fresh sealer/unsealer pair, Ernie<br>and Fred can deduce both the tag and \
challenge without communication.<br> They still need to conspire to unseal the secret, \
though.]<br><br>Note if there is a middle-man between the client and the unsealer,<br>the middle-many may \
get access to the secret! Because of the<br>external interface, the unsealing process is only as \
good as your<br> reference to the unsealer, which will be important in a minute.<br><br>*** The Grant \
Matcher Broken and Fixed Again<br><br>Dean Tribble responded to an earlier challenge from Mark Miller \
to<br>do the Grant Matcher problem without EQ. The solution was for the<br> grant matcher to give a \
sealed object to one of the references and<br>an unsealer to the other. Only if both references \
eventually<br>bottom-out in the "same object" (or an equivalent cluster of<br>communicating \
conspirators) can it be unsealed, giving access to a<br> box where the canonical reference to the object \
can be written.<br>This gives a solution to a general coercive equality protocol.<br><br>Except it's \
broken, since you can only trust an unsealing as far<br>as you can trust the unsealer. Suppose you \
have references A and<br> D, purportedly to the same underlying object C, but A is actually<br>a nasty \
mostly-transparent forwarder. You create a sealer/unsealer<br>pair, seal a secret, send the sealed \
box B to D and the unsealer U<br>to A. The hostile proxy A relays not U, but a fake U2 that it<br> \
controls. When the underlying object C gets B and U2, it calls<br>U2.unseal(B). The attacker \
then has access to both U and B, and<br>can unseal the secret.<br><br>The attack hinges on the fact that \
the unsealing call U.unseal(B)<br> gives the purported unsealer the keys to the kingdom. An \
equivalent<br>protocol could involve passing the unsealer to the sealed box. In<br>this case \
we'd have to trust the sealed box, and D could mount the<br>same attack above. No matter what \
we do, the grant matcher and the<br> underlying charity cannot ever contact each other except \
through<br>the untrusted intermediaries, so any capability resulting from any<br>prtocol between them \
will be tainted by one untrusted channel or<br>the other.<br><br> However, the we know that the \
intermediaries don't trust each other<br>and will not conspire (otherwise there's no problem to \
be solved!).<br>We can establish a trusted, capability-carrying channel between the<br> grant matcher and \
the charity by using the bit-stream protocol from<br>the prelude and sending its packets through *both* \
channels at the<br>same time. On recepetion, packets are compared for bitwise equality.<br>No \
channel can alter the data, or inject new data, without detection.<br> <br>Capabilities are never passed \
directly over the untrusted channels.<br>Instead, each side creates its own local behavioral clones \
of<br>capabilities on the other side.<br><br>This strategy gives us a better version of EQ-less \
sealer/unsealers.<br> You can have untrusted, but non-conspiring, references to the sealer<br>and \
unsealer, and tunnel a communication path to the sealed object<br>without ever sending the raw secret \
capability along either untrusted<br>channel.<br> <br>This strategy can be generalized into any arbitrary \
method of<br>validating N copies of a bit pattern. We can have synergy requiring<br>three or more \
elements to be brought together instead of two, or a<br>non-unanimous subset like five out of seven.<br> \
<br>Note that this strategy requires that the tunneling persists for<br>the lifetime of the tunneled \
reference. As soon as we try to relax<br>and trust one channel or the other, we're open to an \
attack. Also<br>note that the protocol does not provide confidentiality for any of<br> the data \
sent over it - it only provides confidentiality for the<br>capabilities that are *not* sent over \
it.<br><br>*** Retroactive Corroboration in EQ-Less Horton<br><br>In a cap-talk message on 2007-10-27, \
Mark Miller lays down a challenge<br> for EQ-less capability systems to provide the sort of \
retroactive<br>corroboration that's possible with EQ:<br><br> Alice tells Carol to \
provide a separate identity tunnel for<br> Bob's use of Carol's C. Carol does \
so. Bob's B makes use of C.<br> Carol logs these uses, attributing them to Bob. \
However, so<br> far, Carol has only heard of Bob from Alice, so Carol hold \
Alice<br> responsible for Bob's misbehavior. Later, Carol also hears \
about<br> Bob from Dave. Based on Carol's prior relationship with Dave<br> \
and what Dave says about Bob, Carol now believes that Bob is<br> \
independent of Alice. With join, Carol can only absolve Alice<br> of Bob's \
misbehavior after the corroborating introduction. With<br> EQ, Carol can also \
retroactively absolve Alice of Bob's past<br> \
misbehavior.<br><br> I pose this as a new challenge to EQ-less ocaps. Can we \
generate<br> either a counter-example or a proof that no counter-example \
is<br> possible?<br><br> <a \
href="http://www.eros-os.org/pipermail/cap-talk/2007-October/009195.html">http://www.eros-os.org/pipermail/cap-talk/2007-October/009195.html</a><br>
<br>In Horton, there's a danger that Alice may introduce Carol not to<br>Bob, but a puppet version \
of Bob controlled by Alice. The puppet<br>layer can then intercept all capabilities sent between \
Bob and<br>Carol. To the extent that the puppet layer acts as a transparent<br> forwarder, it will \
be undetectable. But Alice can use the puppet<br>layer to cause misbehavior - to change the data or \
capabilities<br>sent on any call or return, or to make new calls on her own.<br><br>MarkM points out that \
in a capability system with EQ, if Carol later<br> receives another reference to Bob (whoBob) from a \
trusted source<br>Dave, or at least a source beleived not to collaborate with Alice,<br>Carol can \
EQ-compare the two whoBobs she has, and if they are equal,<br>she can know that Alice transmitted are \
real whoBob, and all past<br> activites on the Horton proxy-stub channel between Bob and Carol<br>can be \
attributed only to Bob, and not to Alice.<br><br>We can get a similar property without EQ. \
Let's call the proxy-to-stub<br>path in Horton a "Horton channel". To provide \
retroactive<br> corroboration, the parties in a Horton channel will treat the channel<br>as a bit stream, \
using the protocol from the prelude, and also log<br>the protocol messages they see at their channel \
endpoint. This log<br>then serves as an audit trail. (To save space, large data values \
may<br> be replaced by a secure hash in the log.)<br><br>When Carol obtains an new, Alice-independent \
channel to Bob, she<br>can cooperate with Bob to use this channel to audit the previous<br>traffic sent \
over the Alice-dependent channel to look for any<br> misbehavior. Note that Carol needn't trust \
the new channel entirely<br>- she only needs to trust that it's independent of Alice, by using<br>the \
parallel transmission trick of the previous section.<br><br>This plan gives retroactive corroboration of \
a Horton channel if<br> there has been no misbehavior. If there *has* been misbehavior,<br>we \
don't know who to blame - unlike the case with EQ, where Alice<br>can show that she gave a correct \
introduction to Bob and is thus<br>blameless for any subsequent abuse. This ambiguity is \
appropriate<br>
- the guilty party might be Alice, Bob, or perhaps some interloper<br>that's contaminating the \
Alice-Bob or Alice-Carol channels.<br><br>In particular, Bob can lie in the verification protocol, and \
make<br>it seem like there has been a discrepency, even if there hasn't<br> been. So without \
EQ, newly-introduced parties in Horton can abuse<br>the relationship until an independent introduction is \
made.<br><br>*** Conclusion<br><br>A simple serialization protocol and bit-wise comparison can give \
us<br> interesting synergies in an EQ-less capability system. Essentially,<br>given untrusted \
references, we can obtain new capabilities whose<br>mistrust is the intersection of our mistrust in the \
constituents.<br>If we trust one path, we can use that path to get trusted versions<br> of any untrusted \
capabilities. If we trust neither path, but trust<br>them to be independent, we can synthesize new, \
trusted capabilities.<br>This can all be done with pure Actor semantics.<br><br>This seems to be an \
improvement on the original Joule verifier protocol,<br> as now we don't even need to trust the \
verifier!<br><br>Jim Larson<br><br>
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic