Decryption Challenge. Who is willing to try?

Some thoughts.

As far as the cryptographic aspects of this are concerned: Gary S.-W. Yeo and Raphael C.-W. Phan present attacks on WinRar, in their 2006 paper, entitled, "On the security of the WinRAR encryption feature." In the abstract, they state, "Our results, compared to recent attacks on WinZip by Kohno, show that WinRAR appears to offer slightly better security features." Tadayoshi Kohno presents attacks on WinZip in his 2004 paper, entitled, "Attacking and repairing the WinZip encryption scheme." Here's a link to the full paper by Tadayoshi Kohno, entitled, "Analysis of the WinZip encryption method."

In reality, though, as I've admittedly beaten to death and beyond, whenever cryptography fails in practice, it's almost always because of the implementation -- not the cryptography. As such, don't worry about the cryptographic primitive; worry about its implementation. All in all, there are usually easier ways at getting at plaintext, as opposed to going through the cryptography itself; it's usually the strongest link of a system. Furthermore, in cases where cryptography is an afterthought -- such as this one -- the likelihood of a failure being implementation related is all but set in stone.

For a plethora of reasons, folks tend to deprive cryptography of its due credit, while ignoring the more realistic risk of implementation failure. Bear in mind that experts design cryptography, but non-experts deploy it. Sure, experts can still get it wrong, but a non-expert is more likely to. If confidentiality and integrity are really important to me, I'm going to go with a solution that's built with cryptography in mind, from the get-go. I have little faith in products that tack on cryptographic functionality short of cellophane and shelving.

 

What are you talking about? Can you break my password or not?

 

Re: Some thoughts.

Can you please elaborate on and explain to me what you mean exactly when you talk about "implementation failure"?

I understand the first part you said, the encryption of that Winrar I made is very solid and nobody can break it, for if it was possible, you or the other guys would have mentioned the "secret word" I have in the text file.

But the second part confuses me a bit. When you talk about "implementation failure" are you reffering to a flaw in the way Winrar would encrypt files? And that flaw or weakness could open the winrar file? If so, did you download my file and see if there is any such implementation weakness?

 

Hi

I'm not sure why you seem to be obsessed with getting a Wilder's person to break your password.

I am not working for an intelligence agency or a malware writer or anything like that. But I'm saying people more knowledgable COULD be able to do it.

For example, maybe you have an un-encypted copy of that file in a temp folder or something, which would be much easier to get.

 

Re: Some thoughts.

Hi

I think he means WinRAR could have been coded incorrectly so there is a flaw in the implementation. This would make it significantly easier to crack, but probably still very difficult using normal computers (i.e. not supercomputers or something like that).

 

If you think someone can break my winrar file, then send it to that person and get them to tell you the "secret word" within the text file.

 

If that is a secureity issue, how can it be disabled? Is there a downside to having it disabled?

 

Hi

OK. I'll try to make this even clearer. I am not working for an intelligence agency or am a malware writer or someone with supercomputers at my disposal, nor do I personally know of anyone who is. However, many of those people do exist in this world.

 

Thank you LowWaterMark. Your comments made a lot of sense. Cheers.

 

Here is how the attack works: If your system has windows running and it's in a locked workstation mode, programs are still running in the background, you just can't access them through the keyboard and mouse without entering in the password. This lock is superficial. A USB drive with auto-run can have a program on it that simply kills the screensaver/lockout window. Same with a CD / DVD or Firewire device. Unfortunately, the firewire device can do this even with auto-play disabled. So when not in use, disable service to your firewire port.

 

Honestly you raise a good issue about Winrar, but you shouldn't be challenging people all the time. this is like the 3' rd time you issued a challenge this month ^^;

 

I can easily reveal your encrypted WinRar file but first i would need you to take some time to go thru my patented human mind sifter detector that can record everything your eyes have seen within the past 60 hours while also probing your physical memory synapses.

 

All-out struggle.

LowWaterMark's contribution was spot on. I'm referring to the likelihood of programming mistakes being a stack of magnitudes greater than the likelihood of cryptographic breaks. Even if the programming is impeccable, the cryptography being implemented must match the appropriate threat model; not only that, but it must be composed properly. Sometimes, programmers forget that whenever they encrypt, they need to authenticate too. We encrypt for confidentiality, and we should authenticate for integrity; if we forget the latter, it can often lead to the compromise of the former. That's not all, though. Here's an example.

Let's say our programmer, Ace, is on top of his game. He hasn't made any programming mistakes. He's aware that he needs both encryption and authentication for the threat model he's working under. However, he must also realize that the order of encryption and authentication makes a huge difference. We'll be generous and assume he knows that Encrypt-then-Authenticate is the most conservative composition (i.e., IND-CCA2 /\ INT-CTXT secure). By going this route, he preserves the confidentiality and integrity of the data, but -- woops -- he forgot about the metadata, which is still sitting in plaintext.

Our programmer did everything right, but faltered when it came to the subtleties of how the cryptography should have been implemented. These subtle mistakes led to information leakage, as well as complete loss of the security guarantees inherent in the generic Encrypt-then-Authenticate composition. This scenario is taken from the paper I linked to, by Tadayoshi Kohno, where he looks at this very problem within the context of WinZip. What is apparent from his research is that implementing cryptography is an all-out struggle -- especially when non-cryptographers are doing the implementing.

From general programming flukes to specific cryptographic intricacies, there's no shortage of things to trip you up. Don't worry about the cryptography doing its job; it's going to be hard enough to get all of the implementation details right so it can do its job. Unfortunately, I don't have a copy of Gary S.-W. Yeo and Raphael C.-W. Phan's paper on WinRAR, but, for whatever it's worth, they claim it offers "slightly better security features" over WinZip.

 

Here is the NSA's take on aes-128 They don't seem to think that it is all that secure. Clasified but not top secret docs protected by it..

 

Not true at all. This is my first and only challenge ever.

Can you break it?

Can you tell me the word that is written in the text file?

 

Well, put your money where your mouth is. Simply break my Winrar file that is available for download and tell me the word within the text file.

You say NSA doesn't think that it is at all that secure. So break my simple Winrar file then. Or ask anyone at all from NSA to break it

I come across people all the time about this topic. They talk and talk and talk about how Winrar and/or AES 128 is not that secure. And then they keep talking and talking and talking, but no action.

So no more words, only actions.

Many people make wild claims such as:

Winrar can be broken

Winrar is not that secure

AES 128 is not that strong.

Etc. etc.

Yet not one of these people making these claims have been able to break my simple little Winrar file. I wonder why? I rest my case

Full of talk, no action.