[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Jonathan S. Shapiro]

On Mon, 2005-12-05 at 09:38 -0700, Christopher Nelson wrote:
> > >It is sufficient if the type code
> > >discourages collisions.
> > >
> > >Further, type codes are not selected by the application. We use the 
> > >least 32 bits of the SHA-1 hash of the interface name. I have 
> > >considered going to 64 bits, and with the new interface this is more 
> > >reasonable. We may do it.
> > >  
> > >
> > I think that qualified name is better approach because it can 
> > ensure that there are no collisions between well done 
> > interface definitions. In Java such approach worked quite 
> > well. There is usually no conflict between namespaces of 
> > _useful_ libraries. In your approach, if there is a problem, 
> > the problem is forever and it is unfixable and it is not 
> > possible to determine in advance whether there is a conflict. Note: 
> > there is usually no problem with distinguishing garbage 
> > object from garbage object.
> 
> By definition, a secure one-way hash has no collisions.  That's the
> whole point of its existence.  In practice a secure hash has fewer
> collisions the more bits you provide.  A 64-bit SHA-1 has astronimical
> probability for collision.

I think you mean "astronomically low probability..."

What you say is not quite true. A secure hash has a 100% collision rate
when executed on identical input. The problem here is that module names
and interface names must be human recognizable, so it is fairly likely
that the module names will collide unless some "political" convention
becomes established.

However, the political convention cannot prevent malice. In consequence,
neither can the cryptographic hash.

> > 
> > The name clash is avoidable if both authors of interface 
> > definition follow some well defined policy. In hash approach, 
> > no policy for conflict avoidance is possible.
> 
> None is needed.  The hash provides the policy in that it automatically
> generates non-colliding values from differing bit-strings.

In this case, this is incorrect. The hash is only as good as the
non-colliding policy imposed on the input strings, and no policy for
that exists that is both (a) human readable and (b) non-colliding in the
face of malice.


shap