Skype Encryption (Partly) Revealed
TSHTF writes "Just weeks after Skype unveiled a public API for the service, a group of cryptographers led by Sean O'Neill have successfully reverse engineered the encryption used by the Skype protocol. Source code is available under a non-commercial license which details Skype's implementation of the RC4 cipher." The linked article cautions, however, that "initial analysis suggests that O'Neill's publication does not mean that Skype's encryption can be considered 'cracked'. Further study will be needed to determine whether key expansion and initialisation vector generation are secure."
It is proprietary, centralized, bloatwared, closed, and bandwidth intensive. Simply fixing one of this is not an improvement on the situation.
Unless you happen to be one of the unfortunate souls whose boss requires all communication to be on skype, then maybe a non-crashy linux client will be your savior.
On the Wikipedia page http://en.wikipedia.org/wiki/Skype_protocol I see presentations from 2004 and 2006 about reversing Skype, including its encryption. What's new here compared to the previous work?
Writing a good, easy to use, high quality SIP client is quite easy these days. Half decent free SIP and RTP libraries exist. Decent free codecs exist. You basically just have to write UI (and not even a complicated UI at that).
The problem is NAT. To make it work 100% of the time you must always have one leg (or an intermediary carrying the traffic) that isn't behind NAT. If you are behind NAT, Skype routes your call through someone who isn't. In other words, you will be using somebody else's bandwidth for your call. And that someone probably doesn't know you are doing it. Up until this point, there has been no free software author willing to do what Skype has done. Basically, because it is unethical in many people's minds. And free software authors tend to work based on ethics.
With current routers and UPnP, a lot of the problems can be avoided, but you are still going to run into some situations which you can't really solve point to point. It has occurred to me to have a voluntary bandwidth usage. This should work reasonably well if the software were popular enough and you could limit the amount of bandwidth used.
I have the skills to write such a thing, but alas I'm busy with other things at the moment. Maybe later...