A stab at the sealer in E

[hal@finney.org]

Marc Stiegler wrote:

> ? def sealSystemMaker new() : any {
> >     def privateCurrentContent := null
> >     def sysUnsealer unseal(box) : any {
> >         privateCurrentContent := null
> >         box offerContent
> >         def content := privateCurrentContent
> >         privateCurrentContent := null
> >         content
> >     }
> >     def boxMaker new(message) : any {
> >         def box {
> >             to offerContent {
> >                 privateCurrentContent := message
> >             }
> >         }
> >     }
> >     def sysSealer seal(message) : any {boxMaker new(message)}
> >     [sysSealer,sysUnsealer]
> > }

I don't understand E very well, but I wonder if there is something
like the "man in the middle" attack possible in some implementations.
The idea is that Alice seals data, gives the box to Bob, who gives it to
Carol, and Carol has the unsealer.  However, Bob can wrap the box in a
fake box of his own before he gives it to Carol, with his fake box just
passing through any messages to the inner box.

In this case it is OK, because nothing needs to be returned by the box.
(Actually I think the code as written may accidentally leak the message
value as the return value from offerContent, since that is the last
expression, but that can be trivially patched.)

The one piece of information Bob could learn is _when_ Carol chose to
unseal the box.  This is a small leak but it is perhaps undesirable.

I think Ka-Ping's table version would be immune to this because it can
tell if it is a valid box without saying anything to it.

Hal Finney