First of all sorry for my bad english, but i'm still learning this language :)
I'm working on dll library which includes few encryption algorithms and i have problem with xor encryption. It doesn't back good results ( well sometimes it back good results, but it depends if input source is number, big or small letter ). If you have any idea on how to solve this problem, I'll be very grateful.
xor_szyfr PROC PUBLIC we:DWORD, ilosc:DWORD, key:DWORD, wy:DWORD
LOCAL ileWY :DWORD ; how much to output
pushad
mov esi, we ; input source
mov edi, wy ; output source
mov ebx, klucz
xor ecx, ecx
.while (ecx < ilosc)
mov ah, byte ptr [ebx]
.if (ah == NULL)
mov ebx, key
mov ah, byte ptr [ebx]
.endif
mov al, byte ptr [esi]
xor al, ah
mov byte ptr [edi][ecx], al
add ebx, 1
add esi, 1
inc ecx
.endw
mov ileWY, ecx
popad
mov eax, ileWY
ret
xor_szyfr ENDP
Hi icro,
Wlcome on board. have a look at the XOR based excryption algo in the masm32 library, you need to provide a large key for it, larger is better but its both fast and reliable.
i think he means he can't xor the the crypted data back to its original form. This is an issue with any encryption alg, can xor a byte into a 0 which would prematurely end your string etc...I forgot the answer with xor but if you're using numbers as key should be over 114 or somthing, over any chars you're use in your strings perhaps it is.
Hello, I started converting your routine to GoASM syntax so I could test it, but am unsure what "klucz" is. Apparently this word is Polish for "key", but there is already a "key"...
xor_szyfr FRAME we,ilosc,key,wy
USES esi,edi,ebx
LOCAL ileWY ; how much to output
mov esi,[we] ; input source
mov edi,[wy] ; output source
mov ebx,[klucz]
xor ecx,ecx
a: mov ah,b[ebx] ;.while (ecx < ilosc)
or ah,ah ;.if (ah == NULL)
jnz >b
mov ebx,addr key
mov ah,b[ebx]
b: mov al,b[esi]
xor al,ah
mov b[edi+ecx],al ; [edi][ecx],al
add ebx,1
add esi,1
inc ecx
cmp ecx,[ilosc] ;.endw
jge <a ;
mov [ileWY],ecx
mov eax,[ileWY] ; returned val
ret
xor_szyfr ENDF
XOR encryption is straightforward. Any sequence of bytes, XORed twice with the exact same stream of hash data, will result in the original data. Typically where problems arise are in handling data length and string termination. Therefore, it may be a better idea to store the length of the data, and pass this to the encrypt/decrypt routine so that it knows exactly how much data to process.
Sorry about the typos, I knocked over a glass of water and my keyboard misbehaved for a while.
I suggested the library algo as it takes any key characters across the range as a pad to encrypt the data against. Use a pad the size of the data to encrypt for the best results and if you are designing national security techniques, ensure an encryption standard unique random pad for each piece of data.