Hi all,
For my latest program i decided to write a swapping function which will swap bytes in a file and so making an attack for a partially known plaintext impossible.
The biggest problem i have is that it should be reversable and it should be dependable on the password entered.
I hope this makes some sense ;)
I was thinking of using 4,6 or 8 byte blocks in which the bytes are swapped.
Another idea i had was using the 32-byte hash as a source for picking locations out the file that are swapped.
However, i have a hard time writing the reverse function.
Do you guys have any ideas or examples for things i haven't thought about yet?
THanks!
For my latest program i decided to write a swapping function which will swap bytes in a file and so making an attack for a partially known plaintext impossible.
The biggest problem i have is that it should be reversable and it should be dependable on the password entered.
I hope this makes some sense ;)
I was thinking of using 4,6 or 8 byte blocks in which the bytes are swapped.
Another idea i had was using the 32-byte hash as a source for picking locations out the file that are swapped.
However, i have a hard time writing the reverse function.
Do you guys have any ideas or examples for things i haven't thought about yet?
THanks!
How about this..."rolling encryption".
The user specifies the password, say "abc"
The first byte gets "functioned" (I have done this by just ASCII addition, minimalistic :P ) by 'a', the second byte by 'b', the third byte by 'c', the fourth by 'a', the fifth by 'b', and so on.
This would kinda produce different results for the same input when only a small part (even one letter) in the password would change!
Very basic, I know, hope it helps!!!
(Posted this in a bit of a hurry, leaving it here for idea's sake :D I realized you were asking about a "swapping" function and not "encryption")
The user specifies the password, say "abc"
The first byte gets "functioned" (I have done this by just ASCII addition, minimalistic :P ) by 'a', the second byte by 'b', the third byte by 'c', the fourth by 'a', the fifth by 'b', and so on.
This would kinda produce different results for the same input when only a small part (even one letter) in the password would change!
Very basic, I know, hope it helps!!!
(Posted this in a bit of a hurry, leaving it here for idea's sake :D I realized you were asking about a "swapping" function and not "encryption")
The first thing that came to my mind was to turn the password into a unique 32-bit number that you could use to seed a random number generator (that you wrote possibly). Then swap letters in the original text based on pairs of randomly generated numbers. Since a software based RNG is almost always predictable you'll be able to reverse the encryption given the correct seed.
Spara
Spara
@Spara: I was thinking about just that, but the only problem is.. How do i reverse it?
Suppose the file is 1024 bytes in size.
I would call the generator 1024 times (simply put) to generate pairs.
Now when i want to decrypt i would have to do the same except start with the last ones generated.
This makes it a bit more difficult.
@shantanu_gadgil: i was thinking of this as well, but i need to be able to reverse it and it should be able to produce different output with every byte change. The idea is nice, but i can't get it to work correctly both ways.
Suppose the file is 1024 bytes in size.
I would call the generator 1024 times (simply put) to generate pairs.
Now when i want to decrypt i would have to do the same except start with the last ones generated.
This makes it a bit more difficult.
@shantanu_gadgil: i was thinking of this as well, but i need to be able to reverse it and it should be able to produce different output with every byte change. The idea is nice, but i can't get it to work correctly both ways.
To reverse the swapping first reseed the RNG with the original seed. Iterate through the swapping process again except, this time, push pairs of random number onto the stack. Popping the pairs off the stack in reverse order and swapping will restore the text to its original sequence.
Spara
Spara
That could be a solution, but the maximum filesize would then be limited to 0x0003F3f0
(about 253kb) after that a stack overflow occurs. (at least on my system ;) ).
assuming that you would run it the same number of bytes as the program is in size.
I think it would be better to allocate memory where the results are written to.
The only problem is allocating as much memory as 4x the file size (one dword per byte).
(about 253kb) after that a stack overflow occurs. (at least on my system ;) ).
assuming that you would run it the same number of bytes as the program is in size.
I think it would be better to allocate memory where the results are written to.
The only problem is allocating as much memory as 4x the file size (one dword per byte).
Why not just use slidekey "encryption". Start off with a key, say for example sake "juniper" and use that to xor (or whatever) each byte in chunks. The slide key part is that the "juniper" changes each iterance.
The above code could be used by taking the key string and create a DWORD value from them (for example, add each of the characters ASCII value together) then pass that value as the last argument of the key. Maybe something like this:
Just a note, None of this code has been tested, I wrote it as writing this post to show what my train of thought was. The problem here would be as long as the user used the same characters, the key would end up the same and would decrypt. To go a little more advanced, you could try looping through each character of the key, incrementing each byte, then looping back to the beginning as you work your way through your plain text. This would ensure the key is correct as each character must be in the correct possition to be viable.
Just a question though, why not use an already available encoding system?
Regards,
Bryant Keller
Cipher proc start_of_pt:DWORD, end_of_pt:DWORD, my_key:DWORD
mov esi, start_of_pt ; Address of the plain-text
mov edi, my_key ; Address of the key
mov ecx, (end_of_pt - start_of_pt)
shr ecx, 2
cipher_loop:
mov eax, dword ptr
xor eax, edi
mov dword ptr , eax
add esi, 4
inc edi
dec ecx
jnz cipher_loop
xor eax, eax
ret
Cipher endpThe above code could be used by taking the key string and create a DWORD value from them (for example, add each of the characters ASCII value together) then pass that value as the last argument of the key. Maybe something like this:
INVOKE lstrlen, ADDR szMyKey
mov ecx, eax
lea edi, szMyKey
xor eax, eax
.WHILE ecx
add eax, BYTE PTR
inc edi
dec ecx
.ENDW
push ecx
xor ecx, ecx
INVOKE lstrlen, ADDR PlainText
lea ecx, PlainText
add ecx, eax
lea eax, PlainText
push ecx
push eax
call CipherJust a note, None of this code has been tested, I wrote it as writing this post to show what my train of thought was. The problem here would be as long as the user used the same characters, the key would end up the same and would decrypt. To go a little more advanced, you could try looping through each character of the key, incrementing each byte, then looping back to the beginning as you work your way through your plain text. This would ensure the key is correct as each character must be in the correct possition to be viable.
Just a question though, why not use an already available encoding system?
Regards,
Bryant Keller
Just a question though, why not use an already available encoding system?
Since i want to create something myself.
What i've done so far is this:
1. Generate a 10kb table file which uses the mouse location and GetTickCount() as input to be "random".
2. Take the password entered and hash it to a 32-byte value (using my own hashing function).
3. Use the hash as input for a random number generator with a 32-byte seed.
take a number between 0 and 10kb from the result.
Add that number to the pointer to the tablefile.
This gives a location in the tablefile pointing at one byte.
Use that byte to xor against the first byte in the plaintext.
Repeat from step 3 until all bytes in the plaintext are xor-'ed.
In theory this results in a xor encryption with a key which has the same length as the plaintext.
Of course the plaintext can still be brute forced (if you have enough computer power) if you know some locations of static bytes (like the PE header).
Since i didn't build in a check to see if the decrypted file is the plaintext on purpose, this makes it harder to brute force.
However, with a known location of static bytes it can be brute forced again.
Therefore i want to write a function which only swaps the bytes in the plaintext, not encrypt them, by taking values from the hashed password.
This way it's more resistant against brute forcing.
Your alghoritm would also encrypt the plaintext, but not change it's bytes locations.
So although it's a nice and simple algo, i can't use it in my program.
If you are interested, a working beta version and the sourcecode for this program can be found here.
By your description, you are wanting to look into "Transpositional Ciphers". Once again, I'm coding off the top of my head here, but this is kinda what you will be wanting to do:
This cipher swaps each pair of bytes till the end of the plaintext has been reached. The above code probably isn't the best solution for such a task, but it should work. Also, check into a series of books called "Applied Cryptography" I think there are two of them, but not sure. They are like the bible for cryptologist. VERY good reads.
Cipher proc start_of_pt:DWORD, end_of_pt:DWORD
mov esi, start_of_pt ; Address of the plain-text
mov ecx, (end_of_pt - start_of_pt)
cipher_loop:
mov al, byte ptr
mov byte ptr , al
add esi, 2
dec ecx
jnz cipher_loop
xor eax, eax
ret
Cipher endpThis cipher swaps each pair of bytes till the end of the plaintext has been reached. The above code probably isn't the best solution for such a task, but it should work. Also, check into a series of books called "Applied Cryptography" I think there are two of them, but not sure. They are like the bible for cryptologist. VERY good reads.
I think you made a mistake in your code :D
It doesn't swap anything...
What you meant probably is:
I've read a few books on cryptography, including one of those, but the biggest issue i have with those books are the mathematical formulas.
I haven't got a clue what all those strange characters are.
once the same formula is written in C or assembly i do understand how it works.
I really should improve my math ;)
I just finished writing my own algho... It was a real pain (took me almost the complete day to get it to work both ways)., but here it is attached.
This function:
takes the inputfile as first parameter, then the password for which it creates a 32-byte hash by calling HashPassword.
Then it takes a 10kb tablefile as third parameter which it uses to pick bytes from to select which byte is going to be swapped with another.
as fourth parameter is takes a TRUE / FALSE entry in which it selects in which order the rounds are ran.
I'd like to know your opinion of it.
btw, the full implementation can be found here.
It is implemented in TableCrypt v0.3 Beta
It doesn't swap anything...
What you meant probably is:
Cipher proc start_of_pt:DWORD, end_of_pt:DWORD
mov esi, start_of_pt ; Address of the plain-text
mov ecx, (end_of_pt - start_of_pt)
cipher_loop:
mov al, byte ptr
inc esi
mov byte ptr , al
inc esi
dec ecx
jnz cipher_loop
xor eax, eax
ret
Cipher endpI've read a few books on cryptography, including one of those, but the biggest issue i have with those books are the mathematical formulas.
I haven't got a clue what all those strange characters are.
once the same formula is written in C or assembly i do understand how it works.
I really should improve my math ;)
I just finished writing my own algho... It was a real pain (took me almost the complete day to get it to work both ways)., but here it is attached.
This function:
EncryptSwap proc inputfile:DWORD,inputpass:DWORD, inputtable:DWORD,encrypttrue:DWORD
....
ret
EncryptSwap endp
takes the inputfile as first parameter, then the password for which it creates a 32-byte hash by calling HashPassword.
Then it takes a 10kb tablefile as third parameter which it uses to pick bytes from to select which byte is going to be swapped with another.
as fourth parameter is takes a TRUE / FALSE entry in which it selects in which order the rounds are ran.
I'd like to know your opinion of it.
btw, the full implementation can be found here.
It is implemented in TableCrypt v0.3 Beta