[E-Lang] ERTP-aware MintMaker

Mark S. Miller markm@caplet.com
Wed, 14 Feb 2001 17:05:28 -0800

At 08:24 PM Tuesday 2/13/01, hal@finney.org wrote:
>This may go away once Mark fixes that other problem with vouch, but the
>following code seems a little risky to me:
>>                 to transfer(var src,var dest) { 
>>                     src := issuer vouch(src)
>>                     dest := issuer vouch(dest)
>>                     unsealer unseal(src.decr)(quantity)
>>                     unsealer unseal(dest.incr)(quantity)
>>                 }
>It is not wrong, but it is brittle in that "vouch" works OK for both
>purses and assays.  In this case we expect it to be used for a purse,
>and indeed only purses will respond to the getDecr message implicit
>in src.decr.

A great lesson in avoiding brittle patterns.  Steve and I have two 
not-yet-posted MintMakers that fixed my vouch problem, but remain vulnerable 
to the attack your later email found in the above brittleness -- the decr 
with no incr.

>However if at some point in the future someone unthinkingly adds a getDecr
>message to assay, they will have opened up the possibility that an assay
>could be passed as src to this code.  Then it will no longer throw the
>exceptions that prevent a fraud from being put across.
>It seems risky to have the security depend on the fact that only certain
>objects will respond to messages with particular names.

Hal, this is the second time I've heard you talk of guarding against loss of 
security under maintenance.  (The first one was when you reviewed Bill's 
Data-Pluribus protocol, aka VatTP.)  Both times I was struck both by its 
rarity (security folk rarely talk about it), and by its necessity. To 
succeed at security, we must take this issue into account.  Of course, 
rarity and necessity are a dangerous combination.

Besides helping us fix the particular problems above, can you say anything 
about what you look for that helps you spot such problems?