-
Hello!
I'm making a texteditor with encryption, and I wonder if the technique I'm using risk to get cracked.
Since special characters under 32 (Ascii code) creates problems to change I let the program skip all these and just go on to the next character.
This means that all letters (and numbers etc.) are completely changed, but new lines, tabs and stuff like that remains. This means you can see on the encrypted text where there are linefeeds and so on.
Does this make the encrypted text more easy to crack? Or is it a risk I can afford?
If anyone knows, please post here.
Pentax
-
The encryption would be probably slow, because you encryption method need a longer algoritm to not allow the specific characters to be returned in the encryption. I don't think there's a security problem with having specific characters unencrypted, there's more depending on the algoritm. If you use keyencryption you wont need to worry about the cracking part with a enough long keyword. Also why do you need those specific characters unencoded? If you wan't it in text form, you will have problems with chr(0) returned as they will cut of you text in a textbox. Also if you just use text characters it's easier to crack.
-
Yes, it is unfortunately quite slow.
The problenm is that if for instance I change the ascii of a character to eigth, and eight means Backspace.
Before, I encrypted everything, and I couldn't decrypt properly again, but I can now.
Pentax
-
A fast way of encryption would be Xor encryption. It is a well known method of encryption so it can be "cracked" easily... But if somebody really wants to crack your algarithom, they'll do it anyhow.
-
Xor is definetly fast and enough secure if you use keyencryption
I have the encryption on my homepage
-
Encrypt to Binary file.
VB6, Windows 98
If you are encrypting MicroSoft Word, Corel WordPerfect, or some other computer file, I would suggest the following.
Write a program to read the file as a binary file (I have never done this, but it cannot be hard to figure out). Encrypt the data using binary operations (Xor would be good), send the encrypted file as an attachment. Write decryption code to recreate original file. Sender and receiver might have to manually change file types to make this scheme work, but it should be doable.
This approach would not have to worry about control data embedded in the original file. A Key consisting of 5 or more Longs should be secure if the type of file and length of Key are not known to some one trying to break the code. If the type of file (EG: MS Word) is known, that data could aid in determining the Key, due to known fixed information in the preface to various standard files.
Xor encryption is as safe as anything, if the Key is long enough and kept secret. The big deal about "Public Key" encryption techniques is the fact that the encryption Key used can be publicly announced. In the world of Spooks and the military, "Down-Stream Loading" (How do you get a new key to an agent in enemy territory or on a remote battle filed?) and other practical problems caused all sorts of trouble, making Public Key methods important.
-
Well, Xor is said to be safe, until you comes to xeros.
Since 0 xores to 0, with a string of zeros somewhere (and there are many in e.g. a Word document) the keyword can be made to appear.
I'm using the fact that VB, given rnd (-1) and then randomize [number] gives the same string of random numbers (well, not really random, but close to), every time you give the right number.
This way the user only have to kno the number, but the enemy must try all numbers possible, which takes to much time and computer power.
The advantage of opening files sequential is that it's easy to work with textfiles that way, simply loading them into a rich textbox.
Pentax
-
Zeros Xor to Key
Sure a string of zeros Xor's to the key. Code cracker would have to know that the original message contained a string of zeros in a specific place in order to recognize the Key, which should look like garbage surrounded by other garbage.
It is important to minimize the data available to the code cracker. If he knew, for example, that original file was MS Word document, it would help him a lot.
The preface to MS words files are similar, if not identical. A clever code cracker might recognize the pattern associated with MS Word documents, even if he did not know that he was looking at encrypted MS Word documents. If always encrypting MS Word documents, it would probably be worthwhile to have a systematic way to scramble the file either before or after encryption. For example: On days divisible by 5, read file backwards; On days divisible by 5 with remainder 3 read every other 32 byte chunk going forward to create first half of file, and read remaining chunks backward; On days divisible by 5 with remainder 1, scramble in some other way; et cetera.
Avoid obvious mistakes. For years, NATO & various embassies (US & others) encrypted formal letters, each with address and return address in standard places, giving code crackers one hell of a head start when they noticed the pattern.
-
Riskless XOR encryption
Well, you should use both random encryption and key encryption xored against your data, and then store the random seed somewhere
Code:
rnd -1
Randomize seed
This is for starting seed
Code:
Key XOR RND XOR DATA
and this is basically how to encrypt
You could XOR date file created or harddisk serialnumber or whatever you want, but random seed should make it secure enough.
-
Well, since I'm using random seeds I think it should be safe enought then. And of cource, I don't think NSA is interested in my plans of murdering the president...
(This was a JOKE! I did NOT mean it, in case someone thinks so!).
And as for the zeros, since there can be quite a lot of it in a file, it's not like looking for garbasge surrounded by garbage. It's really quite easy to crack the key, as long as you don't use randomness.
Pentax
