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":

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
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
Posted on 2001-06-17 15:33:00 by bAZiK.
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 ...
Posted on 2001-06-17 16:01:00 by BogdanOntanu
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
Posted on 2001-06-17 16:59:00 by bAZiK.
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
Posted on 2001-06-17 17:09:00 by 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!
Posted on 2001-06-17 17:47:00 by Elmenda
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.
0AAAAAAAAh
and
055555555h
and their variants (ie
0a5a5a5a5h
) are popular static values. As already suggested, adding a shift to the source in loop will help add some variety:

;I just like this value for some odd reason :)
    mov  edx, 010011100000111111110000000000000b
crypt:
    ror edx, 1
    lodsd
    xor eax, edx
    stosd
    loop crypt
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.
Posted on 2001-06-18 13:40:00 by bitRAKE
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.
Posted on 2001-06-18 18:13:00 by Larry Hammick
Larry, how is Elmenda's suggestion cumulative? EDX doesn't change in the loop.
Posted on 2001-06-18 21:11:00 by bitRAKE
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?
Posted on 2001-06-19 03:28:00 by [-alloces-]
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 :)
Posted on 2001-06-19 06:44:00 by f0dder
>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!
Posted on 2001-06-19 09:36:00 by bazik
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, hutch@pbq.com.au

; ###########################################################################

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

; ###########################################################################
Posted on 2001-06-19 10:34:00 by hutch--
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)
Posted on 2001-06-19 11:05:00 by bitRAKE
Using half the file as a key is certainly another option, but here is something a little more creative...

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
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
Posted on 2001-06-19 11:47:00 by bitRAKE
Thanx hutch, thanx bitRAKE! I'll try both functions.
Posted on 2001-06-19 14:04:00 by bazik

 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...

Posted on 2001-06-19 14:59:00 by disease_2000
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

.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
This message was edited by BogdanOntanu, on 6/19/2001 4:23:58 PM
Posted on 2001-06-19 16:15:00 by BogdanOntanu
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.
Posted on 2001-06-19 21:31:00 by eet_1024
Sorry for that slip about cumulative what-not, but you get the idea. Anyhow ADD would be a little better than XOR.
Posted on 2001-06-22 06:24:00 by Larry Hammick
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
Posted on 2001-06-26 17:19:00 by bitnaut