EnRUPT – The Simpler The Better

I am a bit surprised that so far there were no comments on the list of static Skype supernodes that Sean O’Neil has published along with his Skype RC4 code. It contains a list of 200 IP address and port number pairs hard-coded into every binary of Skype to be used as initial Skype supernodes. A simple analysis of those IP addresses using DNS and whois lookups sheds some interesting light on Skype’s business model:

Only seven out of the 200 default supernodes have an IP address registered to Skype, whereas 84 belong to the academic institutions, most of which are renowned universities, and the remaining 109 are registered to ISPs in various countries.

It is conceivable (and in the case of one Danish ISP even very likely) that among the latter ones, a few might belong to hosted severs in fact run by Skype. However, the vast majority are clearly cable and DSL connections assigned to residential or small business customers.

In particular, the extensive use of computers at universities as fixed supernodes should lead to some raised eyebrows to say the least. While it is not entirely impossible that a few of those installations might have been deliberately set up as part of research studying network traffic, most if not all should be simply Skype clients run on workstations by unsuspecting university employees or students. In any case, it is safe to assume that none of these universities, if they are aware of what is going on at all, gave permission to Skype to use their network and server resources as part of Skype’s service infrastructure.

Since universities typically have a large amount of public (i.e. not firewalled) IP address space with often minimal restrictions and rather excellent connectivity, they can be expected to form an important part of Skype’s network infrastructure. For example, out of the nine static Skype supernodes located in Germany, eight are on university networks.

I provide a spreadsheet (in OpenOffice, PDF, XHTML and plain text formats) with location information so everyone could take a closer look.

Georg Schwarz

We are about to launch our new online service: locating Skype users. At first, it will only report their IP addresses, both external (routable WAN address) and internal (LAN address if the user is behind NAT, proxy or a firewall of any kind).

If it becomes sufficiently popular, we are planning to develop it fairly quickly into a full-blown secure service maintaining a properly encrypted list of Skype users to monitor providing complete reports of each user’s online presence, even if they are “invisible".

Our question is, what do you think would be the most convenient to you way for us to support this service? Small pay-per-search or a flat monthly fee? Or maybe you would like to donate us enough to provide this (and many other) Skype services for free? We are open to suggestions. Please write to us using the text box below.

Sean O’Neil, CTO
VEST Corporation

PS: If you would like your message to remain private, let us know.

While it’s a holiday season, we are giving away another freebie as we have promised. One of the ways to identify the skype user from intercepted traffic is by its Skype update request.

Skype checks for a new version on startup. The HTTP request looks like this:

Connect to ui.skype.com

GET /ui/0/4.2.0.169./en/getlatestversion?ver=4.2.0.169&uhash=1c1cda2a959fc2926d25b5a852fc6468b

Where “c1cda2a959fc2926d25b5a852fc6468b” is MD5("Skyper” + username). Just ignore the 1 in front of it. For instance, if the Skype username is adrian.skype99, the MD5 hash of “Skyperadrian.skype99″ is c1cda2a959fc2926d25b5a852fc6468b.

While it does not provide a direct way to “decrypt” the intercepted hash values, a searchable list of hash values for all possible/probable skype usernames is simple enough to precompute.

Sean O’Neil

There seem to be some questions that a lot of people want answered urgently, as our post has caused a lot of stir and confusion:

1. No, we did not take our blog offline since the last post. We are not hackers and we have nothing to be afraid of. Our database simply got DDoSed on top of all the extra heavy traffic it could hardly handle. I wonder what hackers we may have pissed off…

2. My name is in fact Sean O’Neil. It is not a monicker, not a pseudonym and I am not known under any other names, maybe online nicknames like everyone else. If someone at Skype has confused me with somebody else, that can happen. Nevertheless, I am still just me. I do not know anyone at Skype. I’ve only had the pleasure of talking to its new CISO or at least to someone calling himself Adrian who knew how much RAM I had on my computer and where I was located - Skype discloses all that information along with a hash of your Windows serial number to its servers on every connection.

3. I am not Mother Theresa, but no matter how much dirt people may find on me, the simple fact is, all the ciphers I have reverse engineered and published [anonymously until now] for everyone’s benefit were correct. I will tell which ones at the conference. The world could replace them with real or at least better security. Most people just didn’t know who to thank for it and the corporations who had cheated their clients by [always knowingly] selling them fake security didn’t know who to try to sue for exposing their dirty secrets. Now they do. My reputation as a reverse engineer - all those algorithms - speaks for itself. No one can destroy that.

4. I am not a hacker despite some news articles calling me that. I am not a spammer either. I hate spam like everyone else. I don’t know any spammers either. Ew! I am a cryptologist and a reverse engineer, and as you can see, I am good at it.

5. The published Skype RC4 IV expansion algorithm is ALL one needs to decrypt the traffic between Skype clients and supernodes. There is no key. I repeat, there is no secret key to break. It doesn’t matter if this algorithm is secure or not either. That’s all there is. It’s an *obfuscation* layer. Its “security” was mere securing an impossibility for others to design Skype-compatible applications by making sure no one can encrypt or decrypt Skype packets without the algorithm we have published. That is why it was so heavily obfuscated inside Skype binaries, better protected than anything I’ve ever seen in my career - it was protecting Skype monopoly. Yes, it is a monopolstic tactic. But it will not work anymore. Do not worry if Skype changes the protocol. It did not take us 10 years to reverse engineer it out of Skype, only a few days. If they ever change it, we will publish the update immediately.

6. This publication was not meant to harm Skype security. It doesn’t. On contrary. It will allow antivirus and firewall companies to add ability to scan Skype traffic for vulnerability exploits. The compression algorithm required to complete the decoding of Skype packets will be published in December this year at 27C3. Our work and all these publications are perfectly legal. Everyone’s ability to provide compatibility with other products is their legal right, at least according to the competition law. Skype will also benefit financially from all the network administrators no longer being afraid to use it on their networks because their firewall and antivirus software can finally see inside the packets and they can finally put it under control - monitor it, throttle it or even block it if necessary.

7. Our publication does not affect privacy of Skype calls, messages or file transfers. They are still encrypted with AES with 256-bit secret keys negotiated using 1024-bit RSA algorithm authenticated with a 2048-bit RSA key of the Skype server. It is all quite secure. Do not panic.

8. We will publish a little more next month, maybe a little demo program that can decrypt Skype UDP packets and check their CRC-32 checksum.

Cheers!

For eight years, Skype enjoyed selling the world security by obscurity. We must admit, really good obscurity. I mean, really really good obscurity. So good that almost no one has been able to reverse engineer it out of the numerous Skype binaries. Those who could, didn’t dare to publish their code, as it most certainly looked scarier than Frankenstein.

The time has come to reveal this secret. http://cryptolib.com/ciphers/skype contains the greatest secret of Skype communication protocol, the obfuscated Skype RC4 key expansion algorithm in plain portable C. Enjoy!

Why publish it now? - It so happened that some of our code got leaked a couple of months ago. We contacted Skype reporting the leak. Only weeks later, our code is already being used by hackers and spammers and we are abused by Skype administration. I do not want to go into any finger-pointing details here, but naturally, we do not wish to be held responsible for our code being abused. So we decided that the time has come for all the IT security experts to have it. Why let the hackers have the advantage? As professional cryptologists and reverse engineers, we are not on their side. Skype is a popular and important product. We believe that this publication will help the IT security community help secure Skype better.

However, for the time being, we are not giving away a licence to use our code for free in commercial products. Please contact us if you need a commercial licence.

It is not all security by obscurity of course. There is plenty of good cryptography in Skype. Most of it is implemented properly too. There are seven types of communication encryption in Skype: its servers use AES-256, the supernodes and clients use three types of RC4 encryption - the old TCP RC4, the old UDP RC4 and the new DH-384 based TCP RC4, while the clients also use AES-256 on top of RC4. It all is quite complicated, but we’ve mastered it all. If you want to know more, come to Berlin for 27C3 to hear all the juicy details on how to use this function to decrypt Skype traffic.

With best regards,
Skype Reverse Engineering Team

Yes, www.enrupt.com has been down for months. Many of you have been wondering if it will ever return. Well, here is your answer. Yes, we are back. Will EnRUPT algorithms ever be updated or improved to produce for the world a simpler and faster all-in-one algorithm that is also invulnerable to related-key attacks? - Yes they will. But not yet. Securing block ciphers with arbitrary block size without a complex key schedule turned out to be a very complex task… Give us time.

We were working on a few exciting secret projects. We still are. Some of our results will remain secret, some be revealed at the upcoming conferences and some will appear on this web site in only a few short minutes. Stay tuned.

After a long analysis and due consideration, we have decided to propose EnRUPT/8 for all three 64-bit variants: EnRUPT64x2-256/8, EnRUPT64x2-384/8 and EnRUPT64x2-512/8 as our updated SHA-3 submission.

In simple terms, the same security parameter s=8 is chosen for different sizes due to the fact that the most effective [linearized collision] attacks cannot break a greater number of rounds for the larger sizes with their much higher security levels that allow for much more expensive attacks. Since the more expensive attacks cannot break a greater number of rounds, the attacker’s control is limited equally for all the different sizes, most probably by the word width equally limiting the attacker’s control. Therefore, an equal number of rounds is sufficient for the different sizes, while the higher security is achieved by increasing the size of the state. Although we firmly believe in the cryptographic resistance of s≥5 and we are working on a proof of its resistance to linearization attacks, we propose s=8 to establish a sufficient margin from the best known attacks (2x) to ensure a lasting public trust in the algorithm.

The latest improved 64-bit C and the new Intel Assembly implementations also bring the speed of EnRUPT/8 from 10 to 7.8 CPB (Core 2 Duo, with minor variations on different CPUs) placing it somewhere between Tiger and SHA-1 by speed.

We will publish and submit the updated specification including the updated optimized implementation soon.

With best regards,
The EnRUPT Team

While we are working on determining the best value for ïrRUPT security parameter, we do not have much time for watching the news, but this is something we thought is worth your attention because of its irony:

The US is outraged that India restricts symmetric encryption to 40-bit security.

We think it is truly hilarious. The US has gone a long way from banning strong encryption to developing standards for it to enforcing it and enforcing it more and now… to forcing others to allow it. It looks like the US officials are beginning to realize that the benefits of secure communications far outweigh the losses since the vast majority of the population are NOT criminals. We do not remove the seat belts from the cars just because they would save lives of the terrorists, do we?

I wonder if India has access to the AES-256 encrypted Skype chats, calls and file transfers or if Skype S.A.R.L. has deposited some sort of an Additional Decryption Key with their DOT to avoid getting themselves banned from the second largest country in the world?

PS: Apparently, that PTI News article got deleted without an explanation.