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

[Byron Campen <bcampen@xxxxxxxxxxxx>]

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?

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.

Best regards,

Byron Campen

The following patch address several issues. The first is a multi-thread, multi-cpu race condition with the current callid. If you have several separate instances of dum, the same call-id can be computed on a multicore/processor machine. To solve this, the patch adds process and thread-id to the salt value.

 

The process / thread id is currently implemented on Win32, Apple, and Linux. On linux, getpid() returns a different value for each thread. The other platforms use the respective calls for getting the process id and thread id. I did not implement other platforms since I don’t have access to them.

 

To address other concerns that the call-id does not contain enough randomness the patch increases the number of hex digits chosen to 16. This should massively reduce the collision space of call-ids as people have reported on the mailing list previously.

 

 

Aron Rosenberg

SightSpeed Inc.

http://www.sightspeed.com

 

<resiprocate_thread_random_callid.diff>

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel@xxxxxxxxxxxxxxxxxxxx

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

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