Has anyone tried it yet? What do you think?
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAD2Yiva-CRvFB8EAE1xqFO2s%3D904QQK5_TpWK9HN4wtfnW7W9A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/85AFD469-005F-4B27-9DDB-45BA7879ED17%40gmail.com.
> Finally, some real security for IoT devices!except perhaps for all the side channel timing attacks?
> The key thing is that a process can only name capabilities it legitimately holds. No others should be in its clist. There is no generate & test or guessability issue involved. Is that the case here?
The documentation is sparse, but AFAICT, a handle is a 32-bit integer. If one makes a syscall, a handle may be passed in. One result of a syscall might be ZX_ERR_BAD_HANDLE, presumably because the calling process does not in fact have the rights to use that handle, or has guessed a handle that does not exist at all.
I’m sure the process is prevented from using a handle to which it has no rights.
But what is to stop a process from guessing and passing 32-bit integers into syscalls (unless there is some kind of additional security mechanism like rate limiting?)
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hEpoTqesNPckdxwtM_-vzoJ0SBFcM20i_zE4Qf08w2MWA%40mail.gmail.com.
However, you can pass these addresses to the kernel
and it will understand what they are. It's a crude way to have memory
safety for references and yet still support native executables.
Should a program protect its capabilities by using a memory safe
language? Yes, by all means. However, that's an additional step on
top of the security that the system itself provides.
The security world has focussed for so long on "mitigations", which
should really be the last 5%. These are really what to do when your
lines of defence have been broken. But the first step should be
building strong, flexible lines of defense in the first place, and
making that the substrate on which the system is built.
--
William Leslie
Q: What is your boss's password?
A: "Authentication", clearly
Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hEJBOpCcR6ES91jTc7GpFnivgA%3DSuyysBC%2BQQTVpis38Q%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hEdC0CBWa0%2BVtr0sA%3DORChZnkqYseKohHGpV3TJMmZvgA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/r480Ps-10146i-1A32498DBB0340209B02CFB448504787%40Williams-MacBook-Pro.local.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/r480Ps-10146i-49B2C6D4F3AC4D1D9916D32B6FE167C7%40Williams-MacBook-Pro.local.
It definitely *sounds* like they're doing many things right.
I'm very interested in looking at it, even trying it if it's possible.
Time of course is a constraint, but...
Looks like the right place to start is here:
https://fuchsia.dev/fuchsia-src/get-started
Has anyone tried it yet? What do you think?
Dan Finlay writes:
> Here is the Fuchsia page on their security principles. It manages authority
> by passing unforgeable objects as authority, not names, so it is passing my
> initial confused-deputy-resilience smell tests:
> https://fuchsia.dev/fuchsia-src/concepts/principles/secure
>
> On Tuesday, May 25, 2021 at 9:21:28 AM UTC-7 Dan Finlay wrote:
>
>>
>> Today Google began rolling its new OS "Fuscia" out
>> to first-gen Google Nest devices.
>>
>> Fuscia is built on their "Zircon Kernel
>> <https://en.wikipedia.org/wiki/Google_Fuchsia#Kernel>", which is based on
>> "Little Kernel" by Travis Geiselbrecht <https://tkgeisel.com/>.
>>
>> The OS is going to be rolling out slowly on Nest devices for now, but is
>> claimed to be built to run on basically anything, from laptops to traffic
>> lights.
>>
>> Seems pretty relevant to this group that a new capability-based OS might
>> be coming out. Is anyone here familiar with it? Is this a true
>> "object-capability" operating system? Will it have any notion of remotable
>> objects? Lots of questions, I'll be reading up on it a bit today.
>>
>> - Dan Finlay
>>
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/871r9uzjim.fsf%40dustycloud.org.
At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFoPYMbqkP3wotbAcrZAZhoSnJnwuChJF2MPmHuPYX0BxQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc3%2BAjPFOce3CSZBv_Gh-Oqkb_rYixt-68P8dxV5T%3Dxvsw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc3%2BAjPFOce3CSZBv_Gh-Oqkb_rYixt-68P8dxV5T%3Dxvsw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2UM%3Dd65PAnUoHY9ggqQ3-C-2i4-2-0oPcoXrAvqXqyzg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1zcYEzY_GhCNKxdt%3DY2aRcQoMwSFt0LW7T%2BxXNoQpP9w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1zcYEzY_GhCNKxdt%3DY2aRcQoMwSFt0LW7T%2BxXNoQpP9w%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87eedmriyy.fsf%40dustycloud.org.
Imagine that Actor A wants to send a message to Actor C via Actor B, an intermediary they don't trust with the contents of the message. (B might be a notary certifying delivery.) Actor A sends Actor C half of a key pair. Now, A can encrypt a message and hand it to B for delivery to C. C can read the message, but B cannot.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc29yaDt4hOBNYuFFu7uctenSj2GvrU85YW-paLN_7uzVw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0oFjpiUpos%3D2su2rryknM%2B9eUY%2BpBDRmF-3_5wef73fw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2cGXVGZHzG%3D4tC3U_fOUAWpnUuBAA03vvP6MWm7ExaDw%40mail.gmail.com.
RevocationManager◁aType:Type▷:[aType] constructs interface revokable → aType ⦶ revoke → void♢ ~
[anActor] construct // constructor with the single argument anActor
revoked := false♢
revocable ↦ revocableFacet⦶
upgrade[revocationManagerConstructor] ↦ // upgrade to next version using revocationManagerConstructor
become revocationManagerConstructor[revoked]♢ // become next version passing along revoked
facet revocableFacet implements aType
aMessage ↦ revoked cases true ↠ throw Revoked[ ]⦶
false ↠ anActor.aMessage♢♢▮
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD6anCBtk%2BkHTiqnEWzJ6wUOx5jGMbvC3_gYwGmEQdceUA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2cGXVGZHzG%3D4tC3U_fOUAWpnUuBAA03vvP6MWm7ExaDw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc2ZRkjuK0up8RxqADjdYcJAPoCjSUk9%2BotkQXbZKGvyeQ%40mail.gmail.com.
On Mon, 31 May 2021 at 02:13, Matt Rice <rat...@gmail.com> wrote:
>
> I haven't tried it yet, but i'm a bit apprehensive towards it, somewhat by the number of system calls https://fuchsia.dev/fuchsia-src/reference/syscalls,
> but mostly by the idea of a per-process filesystem/namespace. https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
> They at least did 2 things right with the namespaces by not implicitly inheriting between parent and child processes and the obvious lack of a global filesystem...
> Now if I could take the opportunity to paraphrase Christopher to Christopher,
>
> At some point there was a discussion on how to introduce a confused deputy problem within a capability system.
> which is something like a 2 step process, throw a bunch of capabilities into a bucket of some sort, and delegate access to that bucket with multiple people of diverging security context.
> The typical response is that this is somewhat unnatural in a capability system, you have to introduce both buckets, and a mechanism for delegating them, which works in a different way than every other process shares
> on top of a perfectly good mechanism for sharing. Thus you have to go out of your way, and jump through some hoops in order to introduce confused deputy problems.
>
> Typically when I look towards a capability OS I imagine something where we can keep filesystems and directory objects closely guarded to the shell, giving directory objects to non-shell processes should be the outlier rather than the
> modus operandi... Anyhow it feels to me like they are 1/2 way to a confused deputy such that all you need to add is delegation of the namespace, because they've normalized "putting capabilities into buckets", ...
> It seems delegation is not the expected mechanism to use but namespace transfer instead...
>
It would be great if we could remove the need to provide a (unixesque)
filesystem to a process, but if you want to support Android
applications, you've got to give them something.
Additionally, everything from ld.so to python expects to load the components of the
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hFSUuTugcZTN2wL1ESOOsvkS0At%3D5E8LL-5EG5qG_gsnA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2gnpOrvAHXPx9_bn%3DdBmqetwFTBZaGT0dgMV%2BZTz%3D4Rw%40mail.gmail.com.
It's easy to create a new type as follows:myPrivateMessageType extends myMessageTypeThen send (myPrivateMessageType restricted decrypt[myPrivateMessageType]->Nullable<myPrivateMessageType>) to other parties.In any case, application programmers need to learn about manifesting and abstracting types ;-)Type Actors are a powerful generally useful mechanism unlike the seal/unseal protocol.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc22HODWHga6JgTEwEAWyEWaC8gUdy98Y4p75wqAo9hBYA%40mail.gmail.com.
A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?
Regards,PS. I agree with Mark that it can be difficult to understand programming language notation.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1d25x%3DxDdFZnm1ubz8vbC3FeJ9zd1kJz3nj6h%3DHBm8ng%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0EH%2B4QBdW_Fxdw9W5p%2BcpdXqLhZ61DH9aacrRJuyZzNg%40mail.gmail.com.
Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.
On Tue, Jun 1, 2021 at 1:40 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:On Tue, Jun 1, 2021 at 1:33 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?Better in what sense? In any case, it is a good example.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0_26YtTXo00gupi9zxD3nWjbZuKPARfJtS2Af%3D9_Yeeg%40mail.gmail.com.
On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.This is true. I'll try to find a good clear simple example that demonstrates the power of the asymmetric nature of seal/unseal. But until then, the MintMaker challenge is certainly a fine first example.If anyone has a suggested small simple challenge that illustrates the power of the asymmetric nature of seal/unseal, please post! Thanks.
----On Tue, Jun 1, 2021 at 1:40 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:On Tue, Jun 1, 2021 at 1:33 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:A great thing about Alan's contribution was thathe was able to identify a fundamental principle.We need more focus on fundamental principles and general mechanisms.Mark: Do you have a better example than MintMaker?Better in what sense? In any case, it is a good example.
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0_26YtTXo00gupi9zxD3nWjbZuKPARfJtS2Af%3D9_Yeeg%40mail.gmail.com.
--Cheers,
--MarkM
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjhYxuVtJ3iUK9PHHSmvDhgYVEiK%2BZo%3D91gNSq1uTXVig%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFq3vYBYsy4DmOZXVTzvxS7bmLGctb%2BtCi%2B%2BGT6QhxM1%2Bg%40mail.gmail.com.
On Jun 1, 2021, at 2:53 PM, Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:From what I have seen so far, the seal/unseal protocol seems very special purpose.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0%3DjfOkboFo4-gU2i0S6ZZgdiLgjD%2BTfSN09VJQQ3__SQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD4mCbLPThciHpC-oKKFBLr%2B1fhCpL_4Sf9UadYoFbo%3DbQ%40mail.gmail.com.
Sorry! Because of bad formatting on my computer I missed Chip's tail end phrase "without cryptography".But my points about the value of abstraction and the value of general purpose programming language constructs still stands.The sealer/unsealer primitive still seems low level, awkward, special purpose, and superfluous.Why do you think that type Actors and facets can't do the MintMaker?
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc34fAwroXSjbUJZ85KO2UR-d-0Z0pqbq3ei%3Dbxn-EhCKA%40mail.gmail.com.
SealedUnsealer◁aType:Type▷:[aType] constructs interface getSealed → NoMessages ⦶ getUnsealer→ Unsealer◁aType▷ ♢ ~
[anActor] construct // constructor with the single argument anActor
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc07xDPu-4cKWHg36Tr2qzCGwAGKZs2r9X3f2tZqCsVP0Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7niR5H3NF-X5KB8Xp%2BBZuw%2B-wAVkFM4Qek4ipFUVL0_g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0gR%2BPaBxjN1%3DuZnsO%3DS1tfjUWFJJ3wpFF3CwEU77DRCw%40mail.gmail.com.
SealedUnsealer◁aType:Type▷:[aType] constructs interface getSealed→Sealed ⦶ getUnsealer→Unsealer◁aType▷ ♢ ~
facet sealedFacet implements Sealed
facet unsealFacet implements
Unsealer◁aType▷ using
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0gR%2BPaBxjN1%3DuZnsO%3DS1tfjUWFJJ3wpFF3CwEU77DRCw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/0f5c6a1e-2cbe-f099-180a-dc7ae194b3f5%40mydruthers.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc0RZ58-aUvqOD65sMiS2H6CsHXWXR66kQJOAOVNob6Brw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/39b27352-ef54-4a4b-a368-d187bbfcfb25n%40googlegroups.com.
SealerUnsealer◁aType:Type▷:[aType]
→
interface
getSealer→Sealer
◁aType▷
getUnsealer→Unsealer◁aType▷
[ ] ↦ // constructor with no arguments
getSealer ↦ sealerFacet
getUnsealer ↦ unsealerFacet
facet sealerFacet implements Sealer◁aType▷
using
seal[y] ↦ implementation Sealed◁aType▷ using
get[z]
↦
z cases
unsealerFacet
↠ y
facet unsealerFacet implements
Unsealer◁aType▷ using
unseal[y] ↦ y.get[unsealerFacet]
Carl, your code works for a single x, but the point of a sealer/unsealer pair is that just as with public & private keys, they can be reused. Anything sealed with the sealer should be retrievable using the unsealer and only with the unsealer.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTaduU3NqYZKmZCKceNVm8j%3DNqEHK3s7zB5Tm5XWd1S-nQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1b5zW4D_Kqisnm4v1TOWysdc56-7bVoZyspn5BX1%2BOUQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1b5zW4D_Kqisnm4v1TOWysdc56-7bVoZyspn5BX1%2BOUQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTZO%3D4s6GYxyw-i4YbVoyL_PN69%3DByiYkPW0JexOyZeN%2BA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5S0y1ACdcLMbJZi_vX62qX5S4mY0wKAqnpfFBfV-NTBg%40mail.gmail.com.
Sealed◁aType:Type▷:[aType,
Unsealer◁aType▷]→interface get[Unsealer◁aType▷]→aType
[y, anUnsealerFacet]
↦
get[z]
↦
z cases
anUnsealerFacet
↠ y
Unsealer◁aType▷
interface unseal[Sealed]→aType
SealerUnsealer◁aType:Type▷
interface unseal[Sealed]→aType
seal[y] ↦ Sealed◁aType▷.[y, unsealerFacet]
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5S0y1ACdcLMbJZi_vX62qX5S4mY0wKAqnpfFBfV-NTBg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1nfMxgFAJgDw6sJqb05UU%2BjjXToiq_v4SYbw4rbhN8eA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTbDogzZJ1u50mak5_3-tBtVC82s_Tn-A4VHA7_3VXNJ1A%40mail.gmail.com.
It would be interesting to see implementations of SealedUnsealer in other systems.
For example, take a look at the simple money example in E and the underlying sealer/unsealer pattern.
I have been using these as an exercise to explore some of the recent programming language developments:
- money.coffee in August
- sealing.py in October
- money.dart November 10
- money.scala November 11
Thanks Matt!It would be great to see your examples worked out.Cheers,On Tue, Jun 1, 2021 at 2:30 PM Matt Rice <rat...@gmail.com> wrote:
On Tue, Jun 1, 2021 at 2:07 PM Carl Hewitt Twitter: ProfCarlHewitt <carl.e...@gmail.com> wrote:Mark: You indicated that the MintMaker example might not illustrate the full power of the Seal/Unseal protocol.A better example might provide more insight.This is true. I'll try to find a good clear simple example that demonstrates the power of the asymmetric nature of seal/unseal. But until then, the MintMaker challenge is certainly a fine first example.If anyone has a suggested small simple challenge that illustrates the power of the asymmetric nature of seal/unseal, please post! Thanks.
I'm not sure, off the top of my head I can think of some asymmetric uses of seal/unseal i've toyed with but these were somewhat reliant on confinement,in particular a gift purchase/delivery agent which doesn't reveal the shipping address to the purchaser or the shop (So you cannot obtain the delivery address by starting a shop, only by starting a delivery agent).similarly the delivery agent wasn't able to unseal the package I'd done this in the context of using typed communications channels between shop -> delivery agent... where the delivery agent was restricted to receiving sealed packages,only the shipping destination could unseal, the shop could merely seal these packages and produce the sealed gift. Anyhow it had 4 participants shop, delivery agent, receiver and purchaser... maybe something like this could work...
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc1puhkY4Xme8OLdxZXi9i3Upigsayhx-ppRY4XjjHRJaQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CA%2BymXc3gFgWK5AqGjJcsiHMTb6u-KKqYxaF46_bewt26Mr8sCQ%40mail.gmail.com.