A stab at the sealer in E

hal@finney.org hal@finney.org
Tue, 2 Nov 1999 18:12:56 -0800

Mark Miller writes, regarding Ka-Ping Yee's code: 
> >             define Envelope {
> >                 to getContents(key) : any {
> >                     if (key == _key) {
> >                         contents
> >                     }
> >                 }
> >             }
>      >         define BadEnvelope {
>      >             to getContents(key) : any {
>      >                 keyStash := key
>      >                 define BadDecr(amount) {
>      >                     # do nothing silently
>      >                 }
>      >             }
>      >         }
> Alice's BadPurse, when asked for an envelope encapsulating the decr
> function, hands back a BadEnvelope.  Bob's purse then gives Alice's
> BadEnvelope the key to the mint!  The BadEnvelope then puts or send this
> somewhere where Alice can then use it to engage in further mischief.
> Finally, Alice's BadDecr function does not decrement anything but claims to
> succeed, by returning without throwing an exception, fooling Bob's Purse
> into incrementing its balance and reporting success to Bob.

It sounds like the problem is that Alice's BrandMaker knows a key, and
a putative Envelope handed to the BrandMaker knows a key.  If they know
the same key, the Envelope is supposed to give up its contents.  But
neither can safely reveal their key to the other.

If the keys are random numbers, there are cryptographic protocols by
which two untrusting parties can determine whether they have the same
key without an eavesdropper being able to learn anything about the keys
they have, and with neither side learning what the other's key is if
they aren't the same.  These are sometimes used as fancy versions of
login passwords immune against eavesdroppers.

One is SPEKE, described at http://world.std.com/~dpj/peek.html, where
S on that page would be the (hopefully) shared key value.  At the end
the two parties know whether they started with the same key, but if they
didn't, they don't learn what the other's key is.

SPEKE may be overkill in that it also generates a shared secret between
the two parties, which is not needed in this case.  There might be
simpler protocols that will work, but at least in principle this should
solve the problem.

Hal Finney