[reSIProcate] [PATCH] Add more and better salt values to callid computation

[Aron Rosenberg]

________________________________

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Tuesday, January 23, 2007 1:22 PM
To: Aron Rosenberg
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] [PATCH] Add more and better salt values to
callid computation

 

            We should determine whether openssl has this problem. If it
does not, we could avoid this extra work when we have compiled with
openssl. I do agree that we need to patch the code to generate a longer
sequence of hex digits (or, at the very least, make it configurable).

 

Anyone know off the top of their head whether openssl has this
reentrancy problem?

OpenSSL does not have the concurrency problem. Their random number
functionality is available through <openssl/rand.h>, but that still
requires seeding and can have starvation issues if you request too much
data. On different platforms they make use of all sorts of tricks
including what I was doing above.

 

Also, it would take a lot less CPU to just append the raw bits to the
hostAndSalt than to do an int-to-string(Data) conversion.

 

Does this look a little cleaner / more efficient? If so, I will submit a
revised patch.

 

Data

Helper::computeCallId()

{

   static Data hostname = DnsUtil::getLocalHostName();

   Data hostAndSalt(hostname + Random::getRandomHex(16));

#if defined(__linux__) || defined(__APPLE__)

   hostAndSalt += Data(getpid());

#endif

#ifdef __APPLE__

   hostAndSalt += Data(pthread_self());

#endif

#ifdef WIN32

   hostAndSalt += Data(::GetCurrentProcessId()) +
Data(::GetCurrentThreadId());

#endif

   return hostAndSalt.md5().base64encode(true);

}

 

Aron Rosenberg

SightSpeed Inc.

http://www.sightspeed.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070123/066a64dd/attachment.htm>