So I wrote an encryption algorithm and I have no clue how strong it is. As with all algorithms it's maths-based and the algorithm itself is quite easy.
I'm not a mathematician or by any stretch a professional cryptographer. I just figgured it'd be fun to create a custom algorithm and see how it holds up against people trying to crack it.
>The first one to crack it will receive €20 to his paypal. I know it's little, but it's something. I guess you should do it for the fun of it or whatever.
The zip contains 3 files: A PDF describing the algorithm, CrackMe.cow which is the encrypted file to be cracked and secret.lock (which is also encrypted and needed to decrypt CrackMe.cow).
No, the files aren't infected with virusses... Go ahead and run a gazillion scanners on it if you want to, I really don't care.
That's the easiest way to keep someone from cracking it.
But, if I'm going to encrypt my secrets, I wouldn't be satisfied that the encryption is strong just because it defeated people motivated by a 'legit' offer of 20 not-dollars.
Robert Walker
Not my problem if you think it isnt legit. I will pay. And I just want to know if it is not comoletely worthless. I dont want to proof it being strong as it probably isnt.
Isaiah Sullivan
I won't have a chance to look at this in depth for a few days, but I am intrigued. From the description I'd like to comment on steps 11 and 13. step 11, why would you not loop the master password? the resulting array will have a relationship between the result and the clear that will limit possibilities. step 13, why do you need to store the primary key encrypted, why cant the key just be a part of the password and treated as such (shared in secret)?
I'm sure the code will clear it up for me, but the description could be stronger for the arrays, how are they created, what they are, name them first. like: this method uses three arrays of 100 bytes each for encryption. Then go on to explain how they are generated, where and when they are used and for what. Also the length usage and purpose of the master password? and the possible input range for the clear? any byte? how about multi byte characters?
Jason Taylor
please OP i want to participate but right know i don't know anything about that so keep making this challenges please please please
Ethan Cook
>Why do you not loop the master password? This will also distort the primary key, but it will leave behind data that is easier to trace back. Different patterns might show up from which both the masterkey and the primary key can be deducted. I added an image to the post that shows what I mean if you'd XOR an image. What I did is sort of a CBC-XOR.
>Why do you need to store the primary key encrypted, why can't the key just be part of the password and treated as such? Currently the algorithm requires primary, secondary and tertiary keys of a character-length of 100. In the algorithm itself there is no looping yet, so should (and this is especially a problem with the primary and secondary key) the keys be any shorter then it might happen that there aren't enough bytes to fully decrypt the next key/password. It is not part of the password as this would require a password that has a length of atleast 100. What I could do here though, is that I use the password as a seed/IV for the primary key. I'll look into this.
>How are the arrays created I created them with Math.random() in Java. I set it up in such a way that it generates numbers from 0-16 and then all numbers >= 10 are converted to an alphabetic character (A-F). After the three keys have been generated like this, they are converted to a byte-array of their UTF-8 representation.
>Why are they used Each character in the key is a parameter for the encryption. This is explained in the "Character-map" where numbers 0-9 are basic operations and characters A-F are slightly more complex calculations.
>How about multi byte characters? Currently the encryption method only allows for byte-arrays up to a length of 100. If it can decrypt it succesfully, it can decrypt it succesfully (I provided decryption code in the .java files so people can play around with it).
Luis Jackson
Help me understand step 4. only the first use of it for now. There are three different data used, lets name them: A "Encrypt byte n" B "with byte n-1" C "character n from tertiary key"
C is self explanatory. i understand it to refer to the operation used as defined in character map. the randomly generated tertiary key holds values referring to the operation to be used for each byte.
B and A however, what is the original cleartext? We are told to "encrypt byte n from the password"? so is A the password, and B the cleartext?
And in character map: D Encrypted byte E passwords byte F previous passwords byte
i understand D to refer to the result, But E and F? which is the password and which is the cleartext for the first usage of the procedure described in step 4?
I may have misunderstood something.
Jayden Fisher
>A "encrypt byte n" Byte n is the byte at index n of the cleartext that you want ten crypt.
>b "with byte n-1" n-1 is the cleartext-byte prior to the current cleartext byte that we are encrypting.
>E password byte This is the same as A, I should have been less ambiguous here. My apologies. So E = A = the byte of the plaintext that should be encrypted.
>F previous password byte This is the same as B. Yet again, my apologies for being ambiguous. So 'previous password byte' is the plaintext byte prior to the plaintext byte that we are encrypting currently.
I hope that clears things up :)
Nicholas Clark
>that you want ten crypt. = that you want to encrypt.
Cooper Kelly
I uploaded a more detailed and less ambiguous Algorith PDF explanation. It's along with all the other files again. I updated the .java sources so that it will be the same across all platforms.
Is it a mistake that the encrypted primary key has a length of 117 bytes. Should it not be 100? Exactly what is the first operand for xor after all 100 bytes of the primary key are used up?
Ryan Evans
I should have mentioned why this is;
The primary key gets stored in a file with all other primary keys. The application I wrote works in such a way that you can protect multiple keys with 1 single master-password. The file I have provided you only contains 1 key which is formatted like this:
@KEYNAME|KEY@
So if I would put, lets say, 3 keys in the file: Key1: 1532ACA Key2: 1B53EFF Key3: 9A9A9FE
Then the plaintext would be: @Key1|1532ACA@@Key2|1B53EFF@@Key3|9A9A9FE@
I assume that the 17 additional bytes come from 2x @, 1x | and some name for the key. Ironically I lost the original plaintext & master-password so for me it's also a challenge to figgure out what it was again.
Joseph Howard
In addition to that: this is solely the way it is done in the secret.lock file for this specific challenge. You can also simply output the encrypted primary key's bytes to a file without additional formatting.
Matthew Brown
Uploaded a new .zip with the secret.lock file only containing the primary key, no formatting, no @'s, no |'s and no names. Also the .java sources have been updated.
NOTE: This new version also has a different CrackMe.cow file. The files in this version are not compatible with previous files.
Encryption happened the exact same way, so you can chose whichever .zip you want to use.
Benjamin Richardson
should most bytes in secret.lock be the result of the xor operation between two possible values of the primary key cleartext? possible values for xor operation among values 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 are 0 1 2 3 4 5 6 7 8 9 a b c d e f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f but most values in secret.lock are not part of this set. What am i not understanding?
Angel Clark
looked at the new file, this seems to have been corrected, but now i can see the length of your password (39 characters) from the result values.
Tyler Rivera
I'm not sure if I understand your question correctly. What I can explain is this:
In Java, bytes are encoded with two's complement (so they have a signed bit). The value ranges from -128 to +127 in a byte.
Lets say we have a byte that should represent the value/UTF-8 character A then we would have: 0-1-0-0-0-0-0-1
If we would XOR this with a byte that should represent the UTF-8 character 5 which is represented as: 0-0-1-1-0-1-0-1
If we XOR A and 5 in their UTF-8 representation then we would get:
I am not sure if this helps you out, but I hope it does.
Charles Nguyen
This is correct. How do you see that it is 39 characters long though?
Wyatt Scott
I suppose this is due to the sudden shift of values from anywhere between 20-100 to only 100?
Jackson Lee
Yes, that clarifies it. I picture it in unsigned binary since we are talking about bitwise operations. the picture shows the possible values in hex of the xor operation between hex values (second row and second column) of chars (first row and first column)
it is wise that you removed the formatting @ and | from the data, at least it should not be encrypted, since the clear for those bytes would be known.. It is nice to work with the restriction of only having 16 possible values for any byte of the keys. Thank you for an interesting challenge.
Jason Cox
>Thank you for an interesting challenge.
No problem haha :) The challenge can be approached from 2 sides really: You try to crack the secret.lock file so that you get acces to the primary key and you decrypt the CrackMe.cow file, or you immediatly go ham at the CrackMe.cow file by finding weaknesses in the algorithm :)
