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

["Aron Rosenberg" <arosenberg@xxxxxxxxxxxxxx>]

---

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Tuesday, January 23, 2007 1:22 PM
To: Aron Rosenberg
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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