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