On Tue, Dec 03, 2002 at 06:28:47PM -0500, Thor Lancelot Simon wrote:
> On Tue, Dec 03, 2002 at 02:46:52PM -0800, Jonathan Stone wrote:
> > 
> > .... I hate to blow my own trumpet here, but I do have some expertise,
> > (even some professional reputation), in this area.
> > 
> > 
> > I'd really appreciate it if someone could take the time to explain
> > just what the application-level goal is, here: what uses this
> > ``signature'' is expected to be put to, and what threats
> > (non-malicious errors during data transmission? Malicious modification
> > and recomputation of a matching CRCs?) the application is, or is not,
> > expected to protect against.
> > 
> > I'm afraid I've lost track of that, amongst all the heat and noise.
> > 
> > If we can refocus on what's really wanted, on what threats are inside
> > the scope of the problem and which are outside, then it'd be
> > relatively straightforward for a number of the regulars here to
> > recommend an appropriate algorithm.  And even to explain why other
> > algorithms aren't quite so appropriate.  
> > 
> > So... what *are* we trying to accomplish? 
> 
> Bang just wants a unique identifier for a given shared object file that
> has the property that it depends on the file contents (I already
> recommended a 128-bit random number, but evidently people want to be
> able to naively diff their "stamped for prebinding" .so files and
> see that they are the same).
> 
> Even a perfect 32-bit identifier isn't good enough, by itself.  I strongly
> suspect that a 32-bit identifier stamped into the file, plus information
> from the metadata, probably is, in the real world.  The 64-bit identifier
> that Bang is using now, consisting of the CRC-32 of the file followed by
> the Adler-32 of the file, is probably good enough all by itself but it
> seems silly to not use the file size and metadata to further reduce the
> chance of collisions no matter how the identifier is chosen.

Last night I must be too sleepy (and you and Jason were right ;-) Okay, I
will use the file size as well.

So I will use the following values for identification:

 - 32 bit CRC32
 - 32 bit Adler32
 - file size
 - base address (determined by ld.elf_so for each process)

> 
> The sole purpose of this identifier is to ensure that ld.so does not
> mistake one legitimate .so file for another.  Deliberate attempts to
> generate hash collisions are beyond the scope; this is not a security
> function, we simply want reasonable assurance that the prebinder will
> not hand you the symbols for the wrong shared object file because they
> happened to have the same unique identifier computed from their contents
> and stamped into them.

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>