NANY 2009 Release: Crush Cryptonizer

[Crush]

NANY 2009 Entry Information

Application Name	Crush Cryptonizer
Version	V1.1b
Short Description	Scramble short files in an absolute super-secure way
Supported OSes	Windows
Web Page	-
Download Link	Crush Cryptonizer V1.1b
Sourcecode	Crush Cryptonizer V1.1b Sourcecode
System Requirements	Pentium 0.01Mhz should take a while but be enough to encrypt. You´ll need a quantum computer to decrypt it if you try to crack a crypted file
Version History	08/12/01 Idea V1.0 08/12/21 Release V1.0 08/12/28 Release V1.1 09/02/27 Release V1.1b (several internal fixes)
Author	Crush

Description
You can crypt/decrypt in an extremely high secure way short files. I´d say there´s currently no harder encryption existing. It´s not based on standard crypting routines like AES, Serpent or Twofish and hashes like RipeMD, SHA or others. The program has exclusive in-built cruelty-cryptonite that makes it unusable for realtime-encryption/decryption!

Features
The strength is its combination of iteration calculations, salt generation, code-shuffle algorithm that gives you the power to decide how long someone will take to decrypt it properly. This means: You can crypt a 4-byte text as example so hard that the decryption with the key could take several years on a Cray XT5 supercomputer if you like - the only problem is: You also need the same time to encrypt 

Technical information:
A number, password or file can be used as input salt. Even if you take the same settings for encryption your encrypted file will be everytime totally different. During the whole process a shuffle-index is recalculated constantly from the results and the actual salt/key. The datas are eored and shuffled with the complete salt. Shuffling means the bytes are changed in the destination datas and the salt itself and so change the next following encryption pass. If the salt is longer than the datas to encrypt it starts at the beginning with this predure - so the start position of the encryption can change every loop. While shuffling it calculates from the actual salt a new shuffle-index in a ping-pong way. This index shuffles the salt itself. It´s because of the nature of the calculation impossible to shorten the encryption in any way. You need to calculate the whole way back with all iterations to get to the original datas and to decrypt all you also need the position where to start in the salt. It´s not even the most imaginable secure way to crypt datas. Additionally it fully supports One-time pads. That is till now with right usage an uncrackable way of encryption (Wikipedia cit.: "The one-time-pad is the only cryptosystem with perfect secrecy... OTP can be used, along with a more standard cryptosystem, in a superencryption scheme).

Planned Features

Usage
Installation
You need nothing special to do - only run the .exe file

Using the Application
Read the readme.txt

Uninstallation
Only delete the file

Known Issues
none at the moment

Screenshot

[Crush]

The first Alpha is online now for tests and suggestions.

Enter Password, Keylength and Iterations. Decrypt after Encryption makes a test decryption to be sure. Set Key Length to Filesize has the words swapped  The Keylength will be set to the Filesize that will be scrambled. Load One-Time-Pad selects a complete File as a Password. This will later set the "Set Key to Filesize" hook active. Crypt let you select the file and starts without waiting. The Crypted file will be saved after encryption and the name gets ended by .cCrypt. Decrypt makes the same to the other direction (deletes the .cCrypt at the end and saves the original filename). Please use this version only for testing, because the Randomizer, CRC and Encryption-Algorithm will be changed by others for the release. If the Decryption not successful the file will not be saved.

[Perry Mowbray]

That's fantastic Crush!

UltraShare picked up that I speak English, so no need to translate 

The programme ran into a problem though:

[Crush]

Thanks!  I haven´t remarked this function is Vista-only. Please try the new file.

[Perry Mowbray]

Works well now... playing now 

[f0dder]

Not to flame you, but...

friends don't let friends use homebrew crypto-algorithms. Personally, I'd feel safer using 128-bit AES than something like this (and in reality, I'd of course use 256-bit AES). You might feel that your algorithm is really fancy and all (I wrote some really fancy stuff back in the early 90es and thought it was supercool and supersecure), but as long as it hasn't gone through intensive cryptanalysis and mathematical torture, I'm not going to trust a new algorithm.

[ewemoa]

Memories of: http://schneier.com/essay-189.html

[Crush]

@f0dder: Thank you for your scepticism. You´re not the first one. Other coders had the same. Alpha1 has changed to Alpha2 with optimized algos. I sent the other my sourcecode and this also didn´t helped, because he wasn´t able to see how it differs to other crypters. If you´re not outstanding good in math and coding you´ll not be able to prove Crytonizer is more or less secure as others.

"friends don't let friends use homebrew crypto-algorithms" -> do you really think most of the Encryption-Algos are not homebrewn? If it would be so no free public encryption would be available.
If you´d take a closer look at some of the coolest freeware programs I bet the most of them are homebrewn.

Please remember: Cryptonizer is no weekend-project. I started with this thing a few years ago and used it in customers software. Later I saw it could be improved. This is what I do now.
The only way to show you it´s no fake is to explain all functions as good as possible.

Good encryption must not mean you need complicate code and mathematical mastership. The results are measurable and comparable with several testing tools from NIST and others. I use Cryptools testing-suite for my tests. That´s the same others did in the past. The tools for encryption are not so rich as it seems.

I know all the open encryptions and how they basically work. All weaknesses of "public" encryption algorithms have been eleminated in Cryptonizer. I´m still working and improving the encryption algorithm itself for even better results in all Cryptool-Tests. Its a funny thing is that I make a comparison especially to AES-256 that you mentioned. All Crypttool tests show at the moment (not the Alpha1 version) that Cryptonizer comparable or better results to AES-256. I suppose this means there is enough security by the entrophy and others.
All encrypting programs use the same ways to get to an aim:
1.) EORing bytes with the password  (adds/subs/rols/rors somtimes also)
2.) Shuffling the bytes (Shifting rows and mixing columns)
3.) Substitution with other datas
4.) Adding the key to the datas
5.) Iterations on the results
6.) Changing the encryption key each run

So do I. -> No big difference till now

Where are the flaws?
The main goal was maximum security with maximum speed.
The Key lengths, the size of the cypher-block and the size of the source-data-block is restricted to a fixed size
All rounds (iterations) are limited by the encoding depth.
There is no real salt inside, because the result block must bev than same as the source and cannot be safed with the datas
Real salt is not existing and can only be calculated from the password itself what is enough for some safety but not enough for higher security.
The key is not changing while coding.
Iterations do not change all input parameters
overall: Too many restrictions trimmed to speed

What does Cryptonizer?
My goal is maximum security - the speed isn´t important.
The Key lengths, the size of the cypher-block and the size of the source-data-block is restricted to the size of 2^32
The iterations are limited to 2^32
Real salt can be calculated in the size you wish or loaded from a one-time-pad or any other files-source you like - they get saved with the datas
The iterations changes the datas, the key, the password and the salt at each run. This is the reason why all must be saved together with the encrypted datas. Cryptonizers algorithm is a one-way-street that can go only back the same way to lead to the original source data without any possible shortcut.
Due to the extremely variable iterations you can create an encryption that takes minutes/hours/days or even years to decrypt even with the same password.

To assure the best possible encryption results, I make tests with a fully zeroed file with a one-byte-zero-filled
one-time-pad and only one iteration. This result is tested with all tests of Cryptool. If the result is cool enough I go to the next testing step.

In this test I take several files and encode them with AES-256 with different password. To be sure I use the same settings in Cryptonizer (32 Bytes Key, the same password and 15 iterations - exactly like AES-256). Then I compare all test results with Cryptool again.

At the moment in Alpha  2 it seams that AES-256 delivers not as good results as Cryptonizer - and I´m still working on the algorithm to maximize results. Besides, some of the tests are not passed by AES-256. Cryptonizer passes all. This shows how hard it is to make a really good encryption! My goal is to have similar results as atmospheric noise at the end. Till now I´m not so far away of it.

Nobody is forced to use Cryptonizer. So if you don´t like it - don´t use it.
I did in the past and will do in the future.

[f0dder]

"friends don't let friends use homebrew crypto-algorithms" -> do you really think most of the Encryption-Algos are not homebrewn? If it would be so no free public encryption would be available. If you´d take a closer look at some of the coolest freeware programs I bet the most of them are homebrewn.

There's a difference between "homebrewn" as in "implementation of a specific algorithm" and "a new algorithm". Your algorithm might be all fine and good and secure, but until it has been scrutinized by cryptanalysts for several years, I'm simply not going to trust it... have to agree with ewemoa (or, really, Bruce Schneier) on this one.

Again, don't take this as negative critique of your work, but when dealing with crypto the sane thing is to stick with tried-and-tested (and bashed-to-death-and-weaknesses-known) algorithms.

[Crush]

Crush Cryptonizer Release V1.0 is online.

[Crush]

Crush Cryptonizer Release V1.1 is online.

[dcm_rush]

Im new to the forum but have been following the site for a while. I downloaded this and intend to mess with it.
As for homebrew algorithms, it seems to me that Crush is correct in saying that all the best code at least starts as homebrew. I also agree that its free and non mandatory. As the above mentioned Bruce Schneider also said -This doesn't mean that everything new is lousy. What it does mean is that everything new is suspect.
Fodder, it seems more like your argument is more against anyone attemting to create a new cryptographic application than ANYTHING about this one or the authors work in this case, which seems to at the very least, solid and worthy of some further testing and research. If, Fodder, you would prefer to wait and take others opinion as gospel, join the masses, and wait. I dont recall seeing the author promoting using this as the most secure means available. Its a start. According to the paper you refer to above, even the tested commercial avenues are to be considered suspect, such as Microsofts. If you can find a better way to test it than to let it go for free and let people find flaws in the application or alg, let me know, but it seems like even way back in 1999 when that was written, they knew the only real way to test it was to give it to the public to chew up and spit out.
A new type of cypher is needed as even 256 AES is no longer as secure as it once was. Read the work on breaking disk encryption by the Center for Information Technology Policy at the University of Princeton. The process that Crush describes would greatly impede the breaking of this encryption.
At first glance, and thats all it is at this point, I would count this *homebrew* to hold up longer than the current 1344 bit 3*BF that someone like Drivecrypt is using, but I will agree that anything you want to know is as secure as is humanly possible, should be encrypted with a tested method, although, anyone who has data that they really NEED TO encrypt, already knows that, or they should be fired or hacked.

[f0dder]

Fodder, it seems more like your argument is more against anyone attemting to create a new cryptographic application than ANYTHING about this one or the authors work in this case, which seems to at the very least, solid and worthy of some further testing and research.

Then you have misunderstood me.

I'm against using a new algorithm until it has had significant peer review. Crush's algorithm might be good, but as for now it's developed by a single person, there's no design document, and neither the algorithm nor source code are publicly available. This means there's no way to tell whether it's good or not (yeah yeah, you can analyze entropy, but meh), and there's no way to have peer review (outside of reverse engineering the application, but who would bother to do that?).

If you can find a better way to test it than to let it go for free and let people find flaws in the application or alg, let me know, but it seems like even way back in 1999 when that was written, they knew the only real way to test it was to give it to the public to chew up and spit out.

Yes, letting it into the wild... including design document and source code. And even then, new algorithms haven't been widely adopted until they've undergone massive testing, beating, analysis etc.

Again, I'm not saying that Crush's algorithm can't be good, but I'm a bit sceptical about claims like "in an absolute super-secure way".

[Crush]

@f0dder:
Entropy is only a very small indicator for security. Try the other tests in Cryptool like the runs or vitany tests. They give much more information about the quality of the encrypted code and special ranges of these tests have been declared as main arguments in the FIPS-benchmarks of NIST to select the winners of their encryption contests. I can only repeat that I know all the other standard encryption-schemes, how they work, that mine isn´t worse and I even declare how it differs to the others. Even different products with the same AES encryption are different in security. Some products are told to contain a backdoor, others that their algorithm isn´t unbreakable. With the use of OTPs you can create unbreakable code. It´s a pity that I don´t have a quantum-line to ensure 100% transfer of the key or the OTP. I really spent a lot of time and great efforts in the development of these algorithms. It seems that you trust too much in open source. Open source is a good thing to show others how to do special solutions or to create free programs for others. In such things like encryption I personally don´t trust very much in the security of open encryption algorithms that everybody can access and analyse. The "open" that is in most cases a good thing is in this case a weak point. Additionally, I perhaps want to make a commercial product out of Cryptonizer with some other new features I don´t want to reveal now and these are the reasons why I don´t want to spread the source everywhere. Some time ago people thaught DES or AES128 would be secure like you do now for AES that seems not to be very secure to me as your guru Bruce Schneier wrote.

During the AES process, everyone agreed that Rijndael was the risky choice, Serpent was the conservative choice, and Twofish was in the middle. To have Serpent be the first to fall (albeit marginally), and to have Rijndael fall so far so quickly, is something no one predicted.

I become a little bit sceptic when I see that NIST and the NSA wants everybody to use AES for public encryption. Would they really want you all to use an encryption they cannot decrypt without big efforts? Organisations that insist and live from controlling, information gathering and knowing everything about everybody doesn´t seem to be a trustful source for hints and tips. But if you trust in public recommendations of the inventors of the gigantic Echelon project , ok - it´s your decision .

@dcm_rush
Thank you for your words not to totally shut the eyes for new developments  . With such an attitude I would never take a close look to other programs like FARR, fSekrit or other cool things you can find here or anywhere else. I posted the code to other programmers that also said to me this could be a too simple way of encryption. After taking a look on it they admitted it´s impossible for them to say something about it´s safety but the principle should work. If someone has questions I will be here to answer them as good as possible. I started to work on this encryption about 6 years ago for granting a very secure user validation to access a delicate program I made for a big concern and I also want to use it for other things I created in the future. You can believe me. It´s not done just for fun over the weekend. If I see other new cool ideas and improvements I´ll try to integrate them into my Cryptonizer algorithm to even make it better.

[f0dder]

I really spent a lot of time and great efforts in the development of these algorithms.

I'm not saying you didn't, and I'm not saying your algorithm is bad, or that Rijndael is the best algorithm. What I am saying is that a new algorithm shouldn't be trusted until it has been through rigorous testing by a lot of people.

It seems that you trust too much in open source. Open source is a good thing to show others how to do special solutions or to create free programs for others. In such things like encryption I personally don´t trust very much in the security of open encryption algorithms that everybody can access and analyse.

Forum regulars will know that I'm not an open-source zealot. But for something as critical as encryption, there's no way I'd ever use a closed-source algorithm - security through obscurity never worked. Without peer review, the only guarantee I have that your algorithm is good is your words. Try seeing things outside your own perspective - would you trust business- or life-critical data to a random guy?

(Please keep in mind that I'm not saying you're untrustworthy or anything silly like that, but I don't have any particular reason to trust you either)

The "open" that is in most cases a good thing is in this case a weak point.

Why? If it's open, multiple people can look for flaws in the algorithm. Of course this doesn't to most people, as it takes a lot of math background to do crypt-analysis, but keeping it closed gets you zero peer review.

Additionally, I perhaps want to make a commercial product out of Cryptonizer with some other new features I don´t want to reveal now and these are the reasons why I don´t want to spread the source everywhere.

You can make a commercial product even if the algorithm is open - there's a lot more to systems using encryption than just the algorithm used. I'd personally never use a product using a proprietary algorithm though, and I'd advice everybody against doing so, too.

Some time ago people thaught DES or AES128 would be secure like you do now for AES that seems not to be very secure to me as your guru Bruce Schneier wrote.

That sounded slightly patronizing... if I was a Schneier I'd probably have been running around in circles promoting Twofish, don't you think? I do believe he often has som very sensible things to say, though.

I become a little bit sceptic when I see that NIST and the NSA wants everybody to use AES for public encryption. Would they really want you all to use an encryption they cannot decrypt without big efforts? Organisations that insist and live from controlling, information gathering and knowing everything about everybody doesn´t seem to be a trustful source for hints and tips.

Ah, don't we love a good conspiracy theory?

Rijndael might have been chosen for backdoors, but I kinda doubt it - part of the focus for choosing an AES algorithm was decent software performance and efficient hardware implementation. Remember that the idea behind AES was finding a standard algorithm that would be widely deployed - and that the process started back in 1997, where processing power was a lot more limited than it is today. While I do believe in being skeptic and find conspiracy theories amusing, I don't believe the NSA is able to break, for instance, 256-bit Rijndael.

As for Echelon... heh. Yes, there's a lot of filtering, data collection and cross referencing going on, and it's scary what kind of information can be pieced together (especially in the .us) - and several countries do run Carnivore software at the ISPs border gateways. But the system is still nowhere near what the media scare claimed, and realtime bruteforcing of all encrypted traffic? Riiiiiight.

@dcm_rush
Thank you for your words not to totally shut the eyes for new developments  . With such an attitude I would never take a close look to other programs like FARR, fSekrit or other cool things you can find here or anywhere else.

I'm not shutting my eyes for new development - agan, I'm only saying that
1) new algorithms shouldn't be trusted until they've been thoroughly tested
2) you shouldn't trust closed-source algorithms

I posted the code to other programmers that also said to me this could be a too simple way of encryption. After taking a look on it they admitted it´s impossible for them to say something about it´s safety but the principle should work.

Not everybody who's a programmer is a cryptanalyst...

[mouser]

As someone who has dabble with encryption (see mircryption) let me just chime in a bit.

First, let's say that coding encryption routines can be extremely fun, and extremely educational and intellectually stimulating.  Crush is no doubt having a great time working on this.  The mathematics of some of the encryption routines (while mostly beyond me) is beautiful.

Second, i think it pays to be humble and cautious when talking about the strength of an encryption algorithm.  As the quotes from schneier point out, even presumably strong algorithms are only presumably strong, until someone finds a weakness.

This is why i agree with f0dder's point about the open sourcing of crypto algorithms if you expect them to be used for serious application.. i think it's largely an accepted position that the best way to evaluate the strength of an algorithm is to open it up to the experts and let them try to tear it apart.  There are so many ways for something to go wrong that it really needs a lot of eyes on it if you want to trust it.

Now on the other hand, unless you are one of the top crypto people, the chances of the pros really studying your algorithm are probably slim, so i'm not sure what practical benefit their would be in open sourcing it unless you really wanted to try to get it more widely in use, but on the other hand -- i really don't think it could hurt either -- the beauty of good encryption is that it's ok to let people see the algorithm and study it.  If that helps them defeat it then the algorithm was flawed in the first place.

[Crush]

Ok, you changed my mind. I decided to release the sourcecode. At the moment I think it could be done much better and I´ll add some improvements to it before. During the last weeks I have a lot of really good new ideas I want to implement. Perhaps I first send the source to Bruce and his friends?

[mouser]

The other thing about open sourcing your crypto algorithms is you'll have to develop a thick skin and try not to be too protective or sensitive to criticism.  In truth, i think this is one of those things where you will get more enjoyment out of the entire process if you view criticism of the algorithm as a positive thing.  I'll bet if you talk to the real crypto pros you'll find that they are probably rarely happier than when someone with some skills tries to find flaws in their work.  It will only make your code and your understanding of the work stronger. 

[Crush]

I´ll start some contacts to cryptography experts. As I see my work seems to get more interesting after the newest events here.

Some very bad news for germans have come up today:

In germany the effords in new encryption method will highly rise after a new law for the police has been introduced after many years of discussion and political fights. From January 2009 the police can send trojans or visit you at home when you´re away to install hard- and software on your computer. They now can force you to give them all passwords or you get in jail for a long time. They even don´t need a special reason if they think you´re a suspicous person. In the past they needed to get the official go from a lawyer before. Now they can decide on their own without asking anybody. Now they have rights like a super police.

This is heavy stuff. So I see the market for high security encryption and tools in germany booming in the next years. They also don´t have to inform you after an unsuccessful investigation about your observation. You´ll never now that the have taken a look at you, what informations have been stored where and who can see it and if the programs are still running they can get a perfect profile of your behaviours in the next years. They´re always talking about possible terrorists but the changes are too much to be believable. Even the german constitution has been changed to reach their goals. All new laws in the last years aim to cut all the rights on privacy of the public. This is a bad development and I want to do something against this farce. The only thing I can do is coding.

[f0dder]

Congratulations on your decision - I really honestly believe it's the right thing to do

And I'm sorry to hear that insane law was passed after all. It's a disgrace that such technologically (and generally too, I'm afraid) people are in any position to pass laws. I hope this will go all the way to your version of supreme court (and if it's there already, it might be time to consider moving to another country >_<).

Kinda scary seeing what kind of laws are being passed recently, I'm not very fond of the decision to force Danish ISPs to block access to ThePirateBay either - not that I care much about TPB (and currently it's only easily circumventable DNS lookup blocking anyway), but it's all one step closer to 1984-style regulation. Great firewall of China, anyone? >_<

[Crush]

1984 has still passed. Now they´re 25 years gone forward to a much higher controlling society than the people could imagine at this time. The control-freaks don´t seem to see any frontier they should stop after they got the taste of the digital master-control-program from Tron.

[Crush]

3 Short News:

Bruce Schneier:
I´ve contacted now Bruce Schneier personally and he told me some things about getting my algorithm tested somehow (this could cost a lot money). I think I have to go on with my search somewhere else to prove my algorithms are as good as I think.

BeRo / Demogroup Farbrausch:
I´ve got an extremely cool selfmade filewiper program from him for Cryptonizer and will include it in the next release that you can be sure not to have any decrypted original datas on your harddisk.

HotBits:
I think I´ll also include HotBits-Support as random-number generator for the salt. Its randomness is coming from radioactive decay.

[wreckedcarzz]

Can I be a pain and ask that you upload the ZIP to DC (via way of attachment)? It is taking me about 45 seconds to load this webpage, and it would be much more convenient to just be able to get it instantly here

Also, in your version history:

28/12/21 Release V1.1

I believe that 28 should be an 08?

[Crush]

Thank you with the date-correction!
In several countries import or export of encryption is not allowed. I don´t want to possibly make problems to Donationcoders. So I decided to store it at a local hoster and who wants it can get it there. The file is quite short so the few seconds waiting for the download link should be ok. Open it in a tab and you can surf elsewhere meanwhile.

[megar]

I think you should stuck to well-tested encryption scheme (like AES-256) than your own. It probably be easier to code, and people using your application would be confident in it.

If you want to develop a new encryption scheme, just do that: work on it, use external consultants (experts). It is costly. It has a very long lag (months, probably more), but it is the way to go.

Coding a app and inventing an encryption is not the same task.
As others said, I won't trust your super algorithm for encryption, and I would prefer to use another program with a clean, tested cipher algorithm.

You, and your peers can't test an algorithm. It has to be external experts. It *has* to be. It is not insulting a dimishing your work.
In the '90s, I also wrote an encryption program, though it was über cool (yes, it involved permutation back then). I really won't trust it now.