Hi all, I need a simple and fast encryption routine. It should scramble about 5-10 MB binary data as fast as possible. Currently I use this "encryption":
I know, that isn't very secure :rolleyes: I've already searched the Forums for a good encryption. But I don't want to use something like DES :D Thanx in advance, bAZiK P.S.: Size of encrypted file must stay the same. This message was edited by bAZiK., on 6/17/2001 3:42:48 PM
invoke ReadFile, hFile, pMem, hSize, addr hRead, 0 ;// datei in speicher lesen mov esi, pMem ;// buffer mov ecx, hSize ;// grösse mov al, 123 ;// mit was xor'en xorit: xor , al ;// eine super encryption :-) inc esi loop xorit
One simple improvement that i can think of is to change the fixed value for the XOR stuff with a random generated number (well pseudo random of course) such as when an area from your data is full zero or constant .... one hacker can not easy get your XOR 8 bits key ...
BogdanOntanu, yes, you're right. I'll give it a try. But, if someone has written a better encryption, with a good performance, please post it here :D
Add some RORs or ROLs: rotate the bits with a random number, or rotate each byte with the index of the byte (first byte has index 0, second one index 1 and so on) ANDed with 31 or something. These operations can be reversed easily and encrypts the data a bit more. Thomas
invoke GetTickCount ; pseudo-random number mov edx,eax ; edx= key lea esi,start mov esi,edi mov ecx,size encrypt: lodsd xor eax,edx ; same for encrypt & decrypt stosd loop encrypt bye!
XOR can be seen as flipping the bits of the destination that are set in the source. So, I tend to use an arrangement of bits that covers the 32 bits of a DWORD.
and their variants (ie
) are popular static values. As already suggested, adding a shift to the source in loop will help add some variety:
I wouldn't be concerned with speed - the memory bus will be the bottle neck. What would help speed wise is to compress the data first, then encrypt.
;I just like this value for some odd reason :) mov edx, 010011100000111111110000000000000b crypt: ror edx, 1 lodsd xor eax, edx stosd loop crypt
If the data contains chunks of zeros, the cipher key will be apparent in the enciphered material, unless perhaps you use a cumulative xor-key as in Elmenda's suggestion. But for speed, use dwords rather than bytes, surely.
Larry, how is Elmenda's suggestion cumulative? EDX doesn't change in the loop.
some of you said to take a random number, but how to decrypt the data again? don't you need the same values again? could somebody explain that a bit more to me?
I suggest you take a look at TEA. It's a small and efficient algorithm, it's fast, uses simple instructions, is easy to implement in assembler, and even pretty secure. I don't have any links for you, but searching on google yields results very fast. I'm currently working on a variant of the algorithm, using a few tricks - and will probably end up with a *very* fast version of TEA. Just gotta finish my final 2nd-year exams first, though :)
>some of you said to take a random number, but how to decrypt the data >again? don't you need the same values again? could somebody explain >that a bit more to me? Yes, I did something similar now. I just created a little Header, wich stores the random Numbers. And the Header is encrypted with a static Number. To encrypt it, I read the Header, decrypt it and then decrypt the remaining Exe File. regards. bAZiK P.S.: You can also compress the Header with aPack, if there are a lot of numbers :-) P.P.S.: Thanx to all for their replies! P.P.P.S.: @alloces: Du kannst mir auch auf deutsch mailen, wenn du weitere Fragen hast!
bAZiK, This procedure is a component of an encryption system, its strength is that it will take any length key up to the length of the source. It reads through the key one byte at a time and XORs that byte with the BYTE in the source string. The longer the key, the harder it is to break. By itself it probably could be broken if you took long enough but where you are after reasonable speed and reasonable security, it may do the job for you. Try a key length over 1k in size and that should keep most of your opponents honest. :) Regards, email@example.com
; ########################################################################### XorData proc lpSource:DWORD,ln:DWORD,lpKey:DWORD,lnKey:DWORD LOCAL lref :DWORD ; counter reference for key char position LOCAL pcnt :DWORD LOCAL bvar :BYTE push ebx push esi push edi mov eax, lpKey mov pcnt, eax add eax, lnKey mov lref, eax mov esi, lpKey mov al, mov bvar, al ; put 1st byte in bvar mov ecx, ln mov esi, lpSource mov edi, lpSource xsSt: mov al, ; copy 1st byte of source into al inc esi xor al, bvar ; xor al with next byte in bvar ; ====== This code gets the next byte in the key string ====== ; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ push eax push esi inc pcnt ; increment byte address mov esi, pcnt ; put it in esi mov al, inc esi mov ebx, lref cmp pcnt, ebx jne @F mov edx, lpKey ; put key start address in edx mov pcnt, edx ; reset pcnt to ariginal address mov esi, pcnt ; put original address in esi mov al, inc esi @@: mov bvar, al pop esi pop eax ; ============================================================ mov , al inc edi dec ecx cmp ecx, 0 jne xsSt pop edi pop esi pop ebx ret XorData endp ; ###########################################################################
fOdder that's a nice little algo. Here are some links for the Google challenged. :) Paper & C source Many Links & Many Source Codes (16-bit ASM)
Using half the file as a key is certainly another option, but here is something a little more creative...
Of couse, this could be faster without PROC. I've edited this so many times that I haven't a clue what's going on. ;) Okay, I think I fixed it. :P This message was edited by bitRAKE, on 6/19/2001 1:52:34 PM
XorHalf PROC Buff:DWORD, Length:DWORD mov ecx, Length mov edx, Buff lsr ecx, 3 je bye push ebx ;this really scrambles things up :) push edx push ecx lea ebx, lsl ecx, 2 push ecx invoke XorHalf, edx, ecx pop ecx invoke XorHalf, ebx, ecx pop ecx pop edx dec ecx @@: mov eax, xor , eax dec ecx jns @B pop ebx bye: ret XorHalf ENP
Thanx hutch, thanx bitRAKE! I'll try both functions.
this is something i'm not sure. but if you try to encrypt your data (when your data 00) your a- ctual key will shows up...
Hi Use a pseudo random number generator, actually all random number generators are pseudo random (just do not use the above GetTick because u will not get it again, but can use it to choose an initial SEED...below) because they start to repeat after a while (the longer the better) and they also produce the same sequence given the same starting point (called SEED).. so choose a SEED, generate your random key, XOR to encrypt data then at decrypt use the same seed to reget the original key (pseudo random numbers sequence) here is a sample random number generator, i guess i've got it from somewhere on the web, credit to original autor SEED is the random_number variable
This message was edited by BogdanOntanu, on 6/19/2001 4:23:58 PM
.data random_number dd 15 .code get_random_number: push ebx push eax mov eax, mov ebx,31421 mul ebx add eax,6927 mov ,eax pop eax pop ebx ret
Last year I wrote a chat room in perl that used xor encryption for the id numbers. But instead of one key, I used 16. The 4LSB's were used as an offset to the key array, and the keys were choosen as to not disturbed the the offset contained in the data.
Sorry for that slip about cumulative what-not, but you get the idea. Anyhow ADD would be a little better than XOR.
Simple encryption using XOR and PRNG, from a long ago book: -user picks a password -treat the password (or the first 4 bytes of it) as the seed for the pseudo-random number generator -for each character in the password, do this: *walk N numbers into the PRNG stream, where N is the ASCII value of the character *XOR the current random number with the next byte in the data you want to encrypt *move to the next character in the password and repeat -when you've worked your way through the password, just start over There is no danger of the password showing up in places where the original data is a string of zeroes, since it is not actually XORed with anything. *If* the random number generator is a good one (see Whiz Kid Technomagic for one example of a good one) then you will be _reasonably_ safe from decryption using pattern analysis. Still, I would advise using the longest practical password, just as with other systems. The guy who wrote this claimed it was unbreakable, but I have my doubts; anything using PRNGs is supposed to be susceptible to pattern problems eventually; it just might take a *very* long time to find them. cheers, bitnaut EDIT: Decryption is exactly the same algorithm as encryption. This message was edited by bitnaut, on 6/26/2001 5:25:37 PM