Polymorphic Cascade Cipher

hmm interesting ... i did not know that ... this makes a lot of posts more easy to understand.

He did provide sources of his software.. forum members have even reverse engineered his software and algorithm before that.

I've tested his software , and used many actually used passwords,
did a heuristic brute force attack, i was impressed.

Of course i don't believe that the current algorithms will soon be broken,
but if i look at the passwords that people actually use, the success rating with a mentioned attack is very serious.

64 chars is nice, but is not something most people use, any sysadm can confirm that, they simply can't remember that.
And so they use very simple techniques to be able to remember these passwords. (just a few heuristic rules)

So if they use a password of 6 to 8 chars like most do,
A Cascade cipher like this, will certainly make it more difficult for these attacks.

A good example is a company that provides his coworkers with TrueCrypt on their notebooks, guess what the average password length was ..

 

Very nice!
"Hungry Man" must actually be a group of people (8000 posts in 19 months, that's some 14 posts day by day.
My approach is obviously well understood. Also that things can be realized this way or another.

The goal is important: Make attacks difficult and costly. Especially the latter.
As a matter of consequence, lots of RAM is needed during key setup. The function bootstraps the cipher by introducing pseudorandomness gradually. The function pointers to the hash functions and to the encryption/decryption functions are frequently exchanged, so that an attacker cannot assume that a certain function is executed at a certain point of time. This makes the construction irreducible, even if a flaw in one or more base functions was found.
A processor on a modern GPU chip has not sufficient RAM available in the cache, so that the bottleneck is the data bus and the 2nd level cache or the DRAM. The cipher itself is although not "big" enough to generally prevent the use of hardware acceleration through parallelization. It's although by far better than Anubis or Twofish or AES Rijndael alone.
The key setup function is intentionally designed to require many millions of CPU instructions.
When enrypting data, the sequence of ciphers in the cascade is unknown as well as the cipher contexts that are actually used. Too many variables that make life of an attacker difficult and that cost lots of valuable chip space (for parallelization).

The cipher itself can easily be modified. You will have realized this when you've looked at the source code. An e-mail client may use one variant of the cipher and a video communication software might use another.

Everybody in the group "Hungry Man" will know quite well that it's difficult to attack a construction that is highly variable. As an example, in order to successfully mount a meet-in-the-middle attack, it is pretty mandatory for the cipher not to change.

 

Remember in a real scenario, the 'bad guys' will use heuristic brute forcing,
or use botnets, or there might be countries behind the atack with large datacenters as we have seen in recent hacking attacks,
the stakes might be much higher.

Although in theory there might be just as much possibilities for passwords as there are stars in the Universe or the grains of sand on all the beaches of the planet Earth.
But most people will have to choose a password they can remember.
and the average person can remember (max) 7 items on his/hers grocery list .. ..+/- 2 to be precise.

 

I post literally 10x that much across various forums. It's amazing what 5 minutes worth of typing throughout a day can do.

Yes, I saw this on your site after. Have you tried it on a GPU though, regardless? Or multiple GPUs?

Which was my next question. Just recently there was this big 25GPU cluster using oclhashcat. It's a few thousand dollars of hardware, so naturally no one on this forum is going to use it. But authorities might. In this case do you plan on making your function more memory hard? And, again, have you tested on GPUs or clusters? Or do you know if anyone has? I'd be interested in seeing the speeds.

64Kb of L1 cache per GPU. The recent parallelized GPU cluster has much more than enough to attack without major slowdowns.

The reason I'm focusing on this is because you're trying to make attacks more expensive but the types of attacks we see and hear about today are about using multiple GPUs. Look at bitcoin farming - GPUs are cheap and easy to cluster, you don't even need to be a gov't entity to have this massive amount of power. Your method seems to be very good at preventing shortcuts/ skipping instructions but I think a memory hard approach makes more sense for todays attacks.

So in a world where we have bcrypt/Scrypt for key derivation what makes yours stand out further? I can see potential advantages over bcypt, but nto really for scrypt.

@Tuatara,

7 items with an average of 4 characters per item "milk, eggs" is 28 characters. More than enough for even MD5 (with MD5crypt).

 

Not saying I am an expert on ciphers but I was unable to break it. I did notice some odd things in the program though. Like how it refuses to run in a VM. I also have had no time as I am launching a start-up.

I will say at least there were no stupid issues that alot of "unbreakable ciphers" have. Like truncating passwords, not hashing passwords, padding keys etc. Again I didn't look to much at it so take it with a grain of salt

Good luck though and Merry Christmas/Happy Holidays.

 

I just read specs from time to time. This kind of chip here could be worth looking at:
http://en.wikipedia.org/wiki/Intel_MIC

64kB of L1 cache per processor is insufficient to mount a parallel attack effectively on a GPU cluster, but 64kB come close to what was needed to make all 32 compute units on a HD7970 run in parallel. I guess that a cluster of 1024 GPU chips could very well be realized for a few million US-$ and an attack on my new cipher with reduced hunger for RAM would take approx. 32000 times less than on one desktop PC microprocessor.

Looks as if it would be a good idea to add bcrypt as well as scrypt to the key setup function.

Especially for readers that are pretty unfamiliar with microelectronics: The typical SHA-1/AES or SHA-256/AES hash/cipher combination easily fits into the local RAM of each of the 32 microprocessors (compute units) on your graphics chip! Your graphics board is thus able to (roughly) try 32 million password combinations every second without the need to access any DRAM. Professionals can solder 4 or 8 such chips on one PCB, immerse that in Fluorinert (a pretty expensive liquid with high dielectric strength, low dielectric constant and good thermal capacity) and run hundreds of such PCBs in parallel to try and break passwords (which are typically 6 or 7 characters in length).
Even worse for ciphers like AES: AES Rijndael only requires approx. 50.000 transistors if implemented directly in hardware. One million AES code breaker processors thus fit on a single 8 inch silicon wafer !!! A single wafer can try approx. 10^12 passwords per second. That is scary!!!

@x942: It might refuse to run on a virtual machine as that cipher (with a highly variable block length up to 256 megabyte) requires enormously much RAM. The memory allocation function might fail because of that. The 32 bit x86 code won't run on 64 microprocessors because of the very same reason. That polymorphic cipher definitely does not fit on a GPU, which is a plus for the user.

@Hungry Man: The Polymorphic Medley cipher uses as many hash functions as are available. It cannot be compared with bcrypt or scrypt. It could although use those algorithms if they were freely available. Are they?

 

The challenge has ended and apparently nobody was able to break the cipher.

 

I've had to find out that hardening the key setup function so that each processor core produces a large number of cache misses is much more difficult than I initially thought.
A cipher that does not address this issue is bound to be quite vulnerable. If the internal state is anyways huge, then this is no issue, but in case of AES and likewise, it's really tough to harden the construction. But maybe I'm missing something...

 

The improved Polymorphic Medley Cipher is available and a new code-breaking challenge has started.
The improved cipher is better protected against attacks that involve general-purpose graphics processing units (GPGPU), which are generally a threat as they can be programmed to break any conventional cipher using extensive sieve.

Here's the PR:
http://www.pressebox.de/pressemitte...r-receives-4428-ounces-pure-gold/boxid/578748

The cipher may be regarded by some programmers as a suitable upgrade to AES as it's open source, royalty free and as it involves a number of trusted ciphers. I guess it's the final version of this cipher.