Show Posts
176
N.A.N.Y. 2009 / Re: NANY 2009 Release: Crush Cryptonizer
« on: February 27, 2009, 10:02 AM »
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.
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.
(a must see for any Amiga-fan!).
