[LLVMdev] How to deal with potentially unlimited count/length symbol names?

Robinson, Paul Paul_Robinson at playstation.sony.com
Thu Jun 20 08:45:37 PDT 2013


> > On Wed, Jun 19, 2013 at 3:39 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sean Silva
> > > Sent: Wednesday, June 19, 2013 11:45 AM
> > > To: edA-qa mort-ora-y
> > > Cc: <llvmdev at cs.uiuc.edu>
> > > Subject: Re: [LLVMdev] How to deal with potentially unlimited count/length symbol names?
> > >
> > > On Wed, Jun 19, 2013 at 1:04 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote:
> > >
> > > > The problem is that if I derive the name from what the type contains the
> > > > length of that name is essential unbound. So how does one generate
> > > > names?  I'm thinking of just using a long hash and hoping I don't get
> > > > accidental collisions. Surely there must be a better way?
> > >
> > > Just a cryptographic hash (e.g. SHA1) to avoid the need to "hope" that there are no collisions.
> > >
> > > -- Sean Silva 
> > Cryptographic hashes don't guarantee you get no accidental collisions;
> > their goal is to make it super hard to produce a collision _on purpose_.
> > What you need is an algorithm designed for string inputs, with good
> > uniformity, and an adequate output size; there are many.
>
> It's obvious by the pigeonhole principle that there must be collisions. 
> The point of my statement that OP doesn't have to "hope" that it avoids 
> collisions: crypto hashes are designed (and depended on across the globe) 
> to make collisions vanishingly unlikely; 

Please do not conflate the uniformity property (vanishingly unlikely to
trip over collisions by accident) that applies to all good hashes,
with the collision-resistance property (computationally difficult to
intentionally produce an input B with the same hash as some input A)
which is the key _additional_ property of secure hashes that are depended
on across the globe.

OP requires good uniformity and an adequate bit-width to get vanishingly
unlikely accidental collisions.
OP does not require collision resistance.

Sorry to be picky but I spent a dozen or so years building secure systems
and this kind of misunderstanding is a bit of a sore point with me.
We can continue this off-list or at the next Bay Area social if you wish.

Thanks,
--paulr





More information about the llvm-dev mailing list