[e-lang] A broken brand?

David Wagner daw at cs.berkeley.edu
Tue Mar 4 19:26:26 EST 2008


Mark Miller writes:
>Would
>
>    try {
>       box();
>       if (!flag) { throw ...; }
>       return squirrel;
>    } finally {
>       flag := false
>    }
>
>be necessary or sufficient?

Looks reasonable to me.  I can't come up with any attack on this.

>I wonder how likely we would have been to find this by fuzz testing.

Very unlikely, I think.  I don't think standard fuzz testing is
even applicable, since fuzz testing is designed for testing things
whose inputs are binary data (not object references).

>Altogether, between this and your attack on the Cajita Mint, it's
>clear we need better tools for this kind of programming to become
>adequately robust. (Not that there's any known better alternative.)

It'd be nice to have better tools.  It's a hard problem.  But it's
not hopeless.

I think of these problems (building a mint, building a sealer/unsealer) as
somewhat akin to the problem of designing secure cryptographic protocols
-- a notoriously hard problem.  A five-line crypto protocol can contain
subtle flaws that go unnoticed for a decade.  If this were representative
of the practice of building secure systems, I'd despair.  Fortunately,
I don't think it's representative.  It's very rare that systems builders
have to design and implement a secure crypto protocol; instead, they
reuse one that others have sweated over and that the community has
gradually come to trust.  Hopefully you only need a limited number of
these hard-to-build primitives.  I think it's plausible that designing
and implementing a secure brand is more like crypto protocol design than
like ordinary secure systems programming.

If I'm right, it's enough to have good libraries that provide these basic
abstractions, and to get the libraries right once.  I find it hard to
believe that developers will routinely need to implement their own brand
(and if they try to do that, we can teach them to reuse standard brand
APIs rather than rolling their own, just like we teach developers to
use standard crypto protocols rather than rolling their own).

>Cajita doesn't yet have trademarking, though Mike Stay has a prototype
>implementation. Perhaps this should raise the priority of adding
>trademarking to Cajita?

I don't think so.  If you think applications programmers will need to
use brands/sealers/unsealers, then you should add a library function
that implements sealers/unsealers securely.  Application programmers
should not be implementing their own brands.


More information about the e-lang mailing list