| Code snippet (encryption) |
| VBBR | When will the Code Bin open? I'm already full of small code snippets that I would like to post!
Now for the next one... encryption! Just look at that:
[code]Public Function Crypt(Source() As Byte, Dest() As Byte, Key() As Byte) As Boolean
On Error GoTo Error
Dim i As Long, i2 As Long
ReDim Dest(LBound(Source) To UBound(Source))
For i = LBound(Source) To (UBound(Source))
Dest(i) = Source(i)
For i2 = LBound(Key) To UBound(Key)
Dest(i) = Dest(i) Xor Key(i2)
Next i2
Next i
Crypt = True
Exit Function
Error:
Crypt = False
End Function[/code]
Source is the source array of bytes.
Dest is the destination array.
Key is the key array.
The function returns False if an error occured, otherwise True.
See, I think this is as simple as encryption can get. But then you may say "wait, isn't XOR encryption easy to break?". It depends. If you just XOR each byte with another it is. But here you can XOR everything to how many bytes you want. Of course, the longer the key is, the harder to break. So you can create a key of up to 2,097,152 bytes in size (the upper limit of a Long if I'm not mistaken. If you analyse the code you will see that you can lift this barrier just by adding another counter variable)
If anyone has questions or comments about this... please post here.
Oh yeah I just forgot. Since this is XOR encryption, the ENcryption and DEcryption functions are the same, so I posted a generic "crypt" function that can do ENcryption and DEcryption. |
| Brykovian | quote:
Originally posted by VBBR
Since this is XOR encryption, the ENcryption and DEcryption functions are the same, so I posted a generic "crypt" function that can do ENcryption and DEcryption.
Actually, that's only true if the key is a single byte. If the key is multiple bytes, and you encrypt by going from the key's lower bound to its upper bound, then you need to decrypt in reverse order.
Or doesn't the order matter?
-Bryk |
| VBBR | It doesn't matter, I have tested this code for both string and file en/de-cryption with around 20-byte keys and it worked. |
| VBBR | Oops, I just found a small detail: the buffers size also can't get bigger than 2,097,152 bytes or an overflow error will raise. But I think you could divide the buffer if it's the case.
Is there any way to define an integer greater than 2,097,152? |
| Eric Coleman | actually, an Integer (vb6) has an upper limit of 32,767. I'm not sure where you got the number 2,097,152 from. Also, your method of using the entire key for one byte is the same as using a single byte for the "key".
A(n) = A(n) Xor A(n+1) evaluates to the same number every single time. It's like saying Dest(n) = Dest(n) + Key(m) for every "m". You might as well sum (xor) the Key before you start the loop. Using a constant value for Xor over the entire string is a very trival thing to decrypt. No matter how large and complex your "key" is, there are only 256 different possible combinations. |
| Sr. Guapo | quote:
Is there any way to define an integer greater than 2,097,152?
A long is 2^32, or 4,294,967,296, and when signed is from -2,147,483,648 to 2,147,483,647. There might also be 64 bt integers, I know they exist in VB.NET: 2^64 = 18,446,744,073,709,551,616 (almost 20 quintilion!), or signed from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Seems a little overkill, though. |
| VBBR | Eric, I meant an "integer" number, not an "integer" variable. I meant a signed Long (VB6) if it's the case. About the unsafetyness, you made me realize it is true... now I'm thinking a way of making it better. Maybe XOR the first byte of the buffer with the first byte of the key, the 2nd with the 2nd then repeat if it's needed? I think then the person couldn't manage to decrypt this easily without knowing the key lenght? Also what you meant with XORing the key before the loop?
Sr. Guapo, I'm using VB6, so the longest integer I can get is the Long datatype (that is signed, thus the upper limit is around 2 millions). The 2^64 number seems something around the exabyte, by the way. (byte, kb, mb, gb, tb, pb, eb) This looks enough for a buffer size [:)] |
| Sr. Guapo | quote:
(that is signed, thus the upper limit is around 2 millions)
I think you mean 2 BILLION (see above post). 2,097,152 is 2^21, which most likely is not any kind of normal datatype. I think you just forgot some didgits... |
| VBBR | Oh, this is right. It looks like I just pressed 2, then X then kept pressing = in the calculator ultil I got a number starting with 2.
So bad it was 2 millions and not billions. [:D]
So let me correct now. 2,147,483,647 is the upper bound for a Long. This means the biggest size for the buffer can be 2 gigabytes. I guess this is reasonable.
Or does anybody out there want to encrypt something larger than 2 GB? |
| Eric Coleman | This is equivalent to your code.
[code]
Public Function Crypt(Source() As Byte, Dest() As Byte, Key() As Byte) As Boolean
On Error GoTo Error
Dim i As Long, i2 As Long, PreCalcKey As Byte
For i2 = LBound(Key) To UBound(Key)
PreCalcKey = PreCalcKey Xor Key(i2)
Next i2
ReDim Dest(LBound(Source) To UBound(Source))
For i = LBound(Source) To (UBound(Source))
Dest(i) = Source(i)
Dest(i) = Dest(i) Xor PreCalcKey
Next i
Crypt = True
Exit Function
Error:
Crypt = False
End Function [/code]
No matter how large your Key, it will always evalute to the same number which will be in the range 0 to 255. Using a constant set of numbers for every byte will always return a constant result for the Xor operation.
As for buffer size, I think Windows limit's file sizes to 2GB, at least on 32 bit versions of windows. |
| VBBR | Hum, this does make sense since the Long is a 32-bit integer.
I will work more on this function. (XORing each byte of the buffer with the corresponding on the key) |
| Eric Coleman | quote:
(XORing each byte of the buffer with the corresponding on the key)
this fails as well, especially for well known data. For example, if you were to ecrypt a bitmap file then I could easily find your key by combing sections of another bmp file with the encrypted data and your key will be exposed. You may want to consider using a well known encryption function instead of making your own. |
| VBBR | Oh good then. I was just trying to find an easy encryption method... |