[cap-talk] Implementing a crypto brand: What are the security requirements?

Mark Miller erights at gmail.com
Fri Mar 23 16:23:37 CDT 2007

On 3/22/07, Tyler Close <tyler.close at gmail.com> wrote:
> Ah, and even though SealedBox is not declared final, it doesn't have a
> constructor a subclass could use.

Tyler, Alan, Chip, Bill Frantz, Norm, and I discussed this today. I
have just made SealedBox in the E-on-Java implementation final. I am
not recording this as a bug fix, however, because E-on-Java assumes
that non-TCB code cannot subclass TCB Java code. Should E-on-Java ever
become E-on-Joe-E, we will have to revisit this assumption in general

> I guess this also means the E
> implementation does not allow for the implementation of a crypto brand
> that is polymorphic with the existing E brand API.

Depends what you mean by "polymorphic". For a piece of code like:

    def foo1(box) {
        ... myUnsealer.unseal(box) ...

then it will be polymorphic. But for code like

    def foo2(box :SealedBox) {
        ... myUnsealer.unseal(box) ...

it isn't. This is analogous to the difference between

    def foo3(i) {
        ... (i + 77) ...


    def foo4(i :int) {
        ... (i + 77) ...

Regarding foo3, other objects can be polymorphic with the built-in
integers. Regarding foo4, no other objects can be polymorphic with the
built-in integers.

Text by me above is hereby placed in the public domain


More information about the cap-talk mailing list