< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


The kind of thing I would probably do is 

Data
Helper::computeCallId()
{
   static Data hostname = DnsUtil::getLocalHostName();
   Data hostAndSalt(hostname + Random::getRandomHex(16));

#ifndef USE_SSL //!bwc! we don't need this code if we're using openssl
#if defined(__linux__) || defined(__APPLE__)
pid_t pid=getpid();
   hostAndSalt.append((char*)(&pid),sizeof(pid));
#endif
#ifdef __APPLE__
pthread_t thread=pthread_self();
   hostAndSalt.append((char*)(&thread),sizeof(thread));
#endif
#ifdef WIN32
WindowsPidTypeWhateverThatMightBeIAmNotAWindowsPerson pid=::GetCurrentProcessId();
   hostAndSalt.append((char*)(&pid),sizeof(pid));
#endif //Of ifdef WIN32
#endif //Of ifndef USE_SSL
   return hostAndSalt.md5().base64encode(true);
}


Calling Data(int) does a int-to-string conversion, which is what I'm trying to avoid. Otherwise, this patch looks good, except for the windows pid type, but that is my fault :P

Best regards,
Byron Campen



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



Attachment: smime.p7s
Description: S/MIME cryptographic signature