EnRUPT – The Simpler The Better

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.

EnRUPT has been presented at the First SHA-3 Candidate Conference. The good news for EnRUPT is that NIST has allowed tuning the tunable parameters in the first round. The recent collision attack against ïrRUPTx2 is only effective for s = 1 to 4. EnRUPTx2/5 and higher are not affected by this attack. Although differential trails such as:

0000009000000000 - 2102
00000090000BFF40 - 2110
00000BD0000BDBD0 - 2109
0000090000026D90 - 262
0000000000000000 - 20

or

4924924920822492 - 278
A0A8000000000000 - 2110
000200000AAA0000 - 262
A0200000028A0000 - 259
0020000002080000 - 277
80880000028A0000 - 295
2022000008200000 - 257
8000000000000000 - 225
6924924920002492 - 20

do exist for the linearized ïrRUPT64x2-256/6, it is not clear if they can be exploited at all with only 64 bits of freedom the attacker has in every input. The probability of an ADD=XOR approximation existing for the first two rounds is much lower than what the 2⁶⁴ possible pairs of inputs can satisfy on each step. Unfortunately, our computational resources are insufficient to prove either way. As it stands, ïrRUPTx2/5 is currently the fastest unbroken variant for any security level.

As we have also mentioned at the conference, the discovered colliding pairs for ïrRUPTx2/4 have little to no effect on the real life data. Any difference more than one word away from the collision generating input set would spread to a half of the state bits after one more input word pushing complexity of this attack well beyond the brute-force (2^h/2) as almost every bit of the state difference adds one bit to the complexity of this attack. Thus it does not allow generation of colliding messages at the same low cost unlike the Merkle-Damgård collisions.

We believe that EnRUPT/8 provides a sufficient security margin away from the best attacks, while EnRUPT/H is the simplest although the slowest choice and EnRUPT-256/8,-384/10,-512/12 offers provable security against linearized collisions. Please vote for your preference. We have until June to make a decision and choose the best security/performance trade-off. Currently, the vote is leaning towards EnRUPT/8 as the best choice… Please write to us. We appreciate your input.

The slightly corrected slides (including memory requirements) are available at www.enrupt.com/EnRUPT_2009.pdf and their b/w printable copy at www.enrupt.com/EnRUPT_2009_bw.pdf.

Say hello to full disk encryption! All six major hard disk manufacturers have finally agreed on a single open specification for full encryption of hard drives with proper secure management of passwords and encryption keys. The painfully complex specification supports SHA-1, SHA-2 and the AES in proper secure modes of operation and seems like a lot of good work that the world must be very grateful for, including the little additional side effect: the stolen hard drives have no value anymore as they will not even power up.

Thank you, guys! Great job! I hope that you all got well paid for it. You deserve it.