3 ms·
From my last job working on SIP and encrypted SIP I found a flaw in the PJSIP library where they were generating keys using only ASCII characters and not the fu
by kruhft 15y ago
From my last job working on SIP and encrypted SIP I found a flaw in the PJSIP library where they were generating keys using only ASCII characters and not the full range of the unsigned byte type. I found this in a client application phone using PJSIP, informed the developers of the application; I don't know if it ever got back to the PJSIP developers. This was about 3 months ago and I don't know if this has been resolved in PJSIP, but I would be worried about SRTP key strength in this application.
- n8fr8 15y agoPerhaps we should audit: http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/transport_srtp.c?rev=3191#L352 http://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/... and http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/include/srtp.h http://svn.pjsip.org/repos/pjproject/trunk/third_party/srtp/... ?
- kruhft 15y agoMight be a good idea. After a quick look at the first link, the key is passed in the opt structure. It's generated before the call to pjmedia_transport_srtp_create. I'll keep looking and see if I can find where it's actually generated.
- kruhft 15y agoMight be a good idea. I took a look at the latest 1.* and 2.* version; they look to be using the libsrtp prng for their key generation, so it should be good. The behaviour I was seeing was that the keys coming from the client I was testing with did not ever have any null characters in them, which lead me to believe the keys were only in the ascii range. I'm not sure what type of freedom pjsip gives for key generation; maybe it was a problem with the client I was testing. Looking over the pjsip code it looks to be ok (see generate_crypto_attr_value in trannsport_srtp.c to see the key generation using crypto_get_random).