Thanks for the interesting piece. I think you may be coding this the hard way. You can simply cast a byte to an int without using an ascii table. Also, you don't need a lookup table as the values required can be calculated directly. So the encrypt method becomes simply.
C#
byte[] fileContent = File.ReadAllBytes(@"C:/temp/Test.txt");
byte[] passwordArry = Encoding.ASCII.GetBytes("MyPassword");
byte[] encryptedText = new byte[fileContent.Length];
for (int i = 0; i < fileContent.Length; i++)
{
int intValue =fileContent[i];
int intKey = passwordArry[i % passwordArry.Length];
encryptedText[i] =(byte)((intKey + intValue) % 255);
}
It's not a good idea to go in for 'do it yourself encryption'. It's better to use tried and tested methods.
This is an interesting article that looks like you are attempting to learn some things.
However, I just encrypted three different files.
Each of those files contained only one letter.
File 1: a
File 2: b
File 3: c
The resulting bytes are : 0xd1 (for a)
0xd2 (for b)
0xd3 (for c)
Do you see how that is problematic and leads to a cracker being able to decrypt your "encrypted" text?
Instead, try using a created encryption algorithm like AES to encrypt bytes.
if you were to create files with those same bytes using AES it would look more like:
24 da de e8 73 b6 d0 c1 80 a8 94 82 fb 5f f6 fa (for a)
(where each two chars are two hex values of the byte)
f8 4e 00 7b 2d 74 da ea 04 43 6c 7e 9f 3c 67 ee (for b)
27 ba 9c fb 10 fa 2b bf ad 8b b6 fe ec f0 3a d4 (for c)
See how different all of the byte are?
1. They are not just incremented and
2. the cracker cannot determine the length of the message from the number of bytes output in the ciphertext.
You do not need such "Code for User Select Encrypt or Decrypt" methods. When an user click on a radiobutton, the opposite one becomes unchecked automatically
Last Visit: 31-Dec-99 18:00 Last Update: 11-May-24 20:04