NANY 2009 Release: Crush Cryptonizer

[Crush]

I found a place where experts could take a closer look. The first thing they need is a detailed description. I´ll do that. Don´t forget that the most encryptions are told you by a group that work very intensive together with the NSA. Even Bruce Schneier (that I´ve also contacted for informations) doesn´t trust very much in AES-256. Why the heck do others then?
The most encryption rules that are used in well-known encryptions (especially AES-256) are also included in mine - perhaps a little bit simplier but at least same or more effective by breaking some of the NIST rules like size and rounds and some "forbidden" things like random salt and OTPs. I have test-programs that show me similar or better results in encryption compared to other programs. After describing the algorithm and releasing the sourcecode I hope to get constructive comments on whats wrong or ok with it. Payed Expertices by professionals costs too much money for a nearly free program (you can donate if you like). I can only assure you that I made a lot of efforts to get its actual state and I´ll continue doing all to get more people trusting in an in my opinion new powerful encryption.
I invested most of the time (98%) in developing and testing the algorithm (my first idea to it came 5-6 years ago I think) not the app (2%).
Coding was the main part of my live in the last 30 years. I´m not a high-schooler that creates only simple Dialogs. I´ll still continue with or without people that use it - because I´ll use it for my own products.

[f0dder]

Only one thing to say:

[Andr3w]

I'm really fascinated by your program! 

Just one question: You decided to realease the source-code ...
But where is it downloadable?

[Crush]

Thank you for using Cryptonizer! 

I´m still working on many code improvements like a more effective encryption algorithm (there have been some little flaws and especially a bit self modifying algorithm depending on your password), an included memory and filewiper, a new random-number generator, an OTP-Password combiner and I ´m also keeping contacts to other crypto-coders changing ideas. Don´t expect something incredible big from the sourcecode ... I like it simple - you´d be astonished how short it is (take a look at the main enryption loop of Cryptonizer 1.1 in the spoiler - I removed notices, Traces/Testers and alternative code). Don´t think your password/key contains the original OTP/ASCII-code - it´s changed by the random number generator. The code for the key/salt/PW generation is much bigger than this. I know you could make it much faster using modulo masking but then you´ve to use 2^x fixed ranges and don´t take care of odd divisors that makes it easier to bruteforce-crack code. You can read the most important functions in the technical description at the beginning of this thread. I´m actually starting a company and don´t have much time to work on it - but Cryptonizer has a high priority because I also use it for my commercial products licence generator. It´s also taking a lot of time to measure the encryption-strength with crypto-testing-tools. So the new release could take a while.

If you´re a coder: I´m open for each new idea and suggestions!

One thing you should know is that the new version will not be compatible with the actual one.

A little thing I didn´t mention till now and haven´t included in the standard settings:
If you use Cryptonizer for sensitive datas you can improve the actual security by selecting an odd and rather big Key length - this isn´t influencing the encoding/decoding time too much compared to more iterations and the security rises with every single extra character.

Spoiler

for (itercnt=0; itercnt < iteration; itercnt++)
{
 for (int x=0; x<loop; x++)
 {
  swap(ptxt[x % len], ptxt[u % len]);
  swap(ptxt[x % len], Key[u % Keylen]);

  ptxt[u % len] ^= u>>ror1;
  ptxt[x % len] ^= u>>ror2;
  Key[x % Keylen] ^= u>>ror3;
  Key[u % Keylen] ^= u>>ror4;

  ptxt[x % len] ^= Key[(x+u) % Keylen];
  ptxt[x % len] -= Key[(x+(u>>ror9)) % Keylen];
  ptxt[x % len] ^= Key[x % Keylen] ^ u;

  swap(Key[(x+(u>>ror6)) % Keylen], Key[(x-(u>>ror7)) % Keylen]);

  Key[x % Keylen] ^= ptxt[(x-(u>>ror8)) % len];
  Key[x % Keylen] -= ptxt[(x-u) % len];
  Key[x % Keylen] ^= ptxt[x % len];

  u ^= ((unsigned int)Key[(x-iteration^(ptxt[x%len])) % Keylen] ^ PW[((x-Key[x % Keylen]-PWlen) % PWlen)]) * 7 / 3 ^ PW[x % PWlen];
  _asm rol u,ror5
 }
}

[Andr3w]

I wouldnt call me a "coder".
I'm a well-interested student ^^, so I know few/some crypto-techniques.

My main-interest in reading the source-code is that cryptonizer needed 50% of my RAM-capticity 30 minutes after the last encryption. (No critisism =) ) And I don't really want to know how the encryption is done, but more how you coded it/implemented it in the program structure.

Would be nice of you to post/send/upload the source code.
Thank you.

(I'm sorry for my english, I'm german.)

EDIT: I was too stupid to see the quote! Found it ^^
Thanks

EDIT: But, like menshioned above, the complete code woudl be nice.
Greetings

[Crush]

Thank you for your hint, Andr3w! I´m only a funcoder who wanted to release just in time some small utils for the NANY challenge and in this phase codechanges can result in problems like this. Coders are still human.
Why don´t you tell me in your first post about this memory-problem ?

After decoding for checking the results I forgot to release them again ... a rather silly error that didn´t influenced the functuality or security, because I filled it with zeroes. I repaired this now in the new release Crush Cryptonizer V1.1b and inserted some other small fixes and security features like the standard keylength setted to a prime number, a shorted output message (only the first 256 Bytes of the file datas are shown). The OTP now deactivates the password field and doesn´t stays in memory till direct deletion. In further releases the OTP can be combined with it. If you selected an OTP and want to release the password field again you only have to press escape in the OTP fileselection dialogue or endecode something with it.

When you aren´t a coder why are you so hot on looking at the full source? Your most important questions should be answered with the encryption routine. I´d say the source declares all impotant by itself. Some variables are created with the dialog and are static as long as it´s not closed again. Functions fill them with file information and endecrypted code. Other tables like the random-number-table of random.org or the calculated salt are directly allocated with new and delete, capsulated in an own class that is directly created before and after endecryption. There´s no magic inside the code

I also don´t think I created something new ... all you see is still standard encryptions like +-*/ xors, swaps and shifts .. nothing special, right? I decided not to use fixed slide and coding matrices (that are much faster compared to this with the focus on realtime cryptography) to get some other advantages that I´m paying with a rather slow speed. I only broke all predefined rules of standard encryption routines and so rise the ladder of security.

[Andr3w]

I want to look at the full source code because I think I could learn much about implementing the mathematical structure of cryptography in the structure of a "normal" program code. Which means the GUI and so on...

I hadn't remarked the memory problem untill my second post ...

If you don't want to realease the source code just say it =), i will stop asking you instantly. ^^

Greetings

[Crush]

I posted the sourcecode now, please write back if you have any suggestions or ideas!

[Joel Mayer]

Dear Mister Crush-
In addition to decrypting a message encrypted by your software. Does your software decrypt messages encrypted by other means (algorithms)? Could I feed it a page of encrypted text, wait for a while, and then see decrypted text?

[f0dder]

Dear Mister Crush-
In addition to decrypting a message encrypted by your software. Does your software decrypt messages encrypted by other means (algorithms)? Could I feed it a page of encrypted text, wait for a while, and then see decrypted text?

-Joel Mayer (May 02, 2010, 02:23 PM)

Not possible when (proper) encryption is applied - unless you have patience to wait more than the lifetime of the universe

[Crush]

Dear Mr. Mayer - the Cryptonizer is neither using standard encryption algorithms nor can it be used as a cryptfile-cracker. It can only handle files that have been treated by itself. It´s a Cryptonizer - not a Decryptonizer  
If you are interested in the theory of encryption - I only know one really good program for this: The Cryptool
I think you´ll find what you´re searching for there or nowhere. Don´t forget to try all 3 versions - they differ from each other.

[TaoPhoenix]

"Multiplex Wide Method Encryption?"

Okay I made that term up, but just suppose we have a fresh new crypto program here. To be provocative, I WILL say that "security as obscurity" MAY work just a little when it costs more for a world class crypto-genius to break a code, when abusing the courts is so much easier!

All these Crypto discussions are about "Pure In and Out Math". What about multiform crypto? What about the real text data steganographically attached to a "salt" DC code file split into 4097 parts, which parts are digitally rearranged, which is then saved as a txt file, and then THAT is encrypted through this program? I'll bet $128 no one would bust that with anything less than 3 months and $100,000 of services. Aka. Never.

[f0dder]

I'll bet $128 no one would bust that with anything less than 3 months and $100,000 of services. Aka. Never.

-TaoPhoenix (December 15, 2011, 05:43 PM)

Yeah.

[TaoPhoenix]

Yep! I was thinking of that classic strip when I made my post!

However it would be funny if the computer then "lost" the password, and would only reveal it on a time delay later.

Heh - the next strip becomes "Curses! Foiled by a Time Capsule! Well, beating him with the wrench is fun, let's just do that over beer."