Encryption questions...

I'm trying to do a little encryption program, but I want the whole public-algorithm-but-still-unbreakable-without-the-key deal.

First of all, please don't tell me anything except the exact answers to my questions because I want to make this thing with mostly my own creativity, I feel like a freeloader getting information and I would feel even worse getting ideas.

That being said, I can get to my questions.

If I encrypt something based on the password and it is totally unique to that password (no other password can be used to unencrypt the message) then am I not revealing the password in the encrypted file?

Is encrypting the message based on the message itself a possibility?

The whole idea of a public algorithm encrypted message being (virtually) unbreakable is based on the fact that the password is pretty long, and the more characters the harder to crack, right?

I wish I had more questions but for now I'm fresh out, thanks for any help.

Quote:

---

If I encrypt something based on the password and it is totally unique to that password (no other password can be used to decrypt the message) then am I not revealing the password in the encrypted file?

---

The answer here is a qualified no. If the encryption method (but not the key) is known, a horrendous amount of computing power might be able to determine the key. The code-cracker tries every possible key, checking the results for intelligible words. The key becomes known when "clear text" results from the process. You can see that in a very limited sense, the key can be determined from the encrypted message. Ten or so years ago, NSA (the Code Crack Agency) recommended an encryption method to the Bureau of Standards for commercial use. It used a method that they had the computing power to crack. Somebody blew the whistle, and the method was not recommended to industry by Bu Stds.

Quote:

---

Is encrypting the message based on the message itself a possibility?

---

I am 99.99% certain that the answer to this is no, unless you can be certain that the encryption method is guaranteed to be secret(an assumption not usually made). There are methods used to assure that the message has not been altered. These methods use the message itself to generate a code which is appended to the message. The message is readable (not encrypted) when sent. One place this is used is in financial transactions where secrecy is not important, but you would not like somebody intercepting the message and changing something. Like you want to direct a funds transfer (soon to become public knowledge), but you want to make sure that neither the amount nor the recipient is changed. This is a generalization of the "Check digit" concept.

Quote:

---

The whole idea of a public algorithm encrypted message being (virtually) unbreakable is based on the fact that the password is pretty long, and the more characters the harder to crack, right?

---

Wrong if you are referring to "Publicly known Key" decryption. Right if you are referring to "publicly known method" decryption.

Thanks for the reply Guv! On that last question, I was talking about the public method. Just out of curiosity, what would be the point of a public key? Wouldn't it be better to not have a key in the first place?

Earlier from Guv:

Quote:

---

quote:

If I encrypt something based on the password and it is totally unique to that password (no other password can be used to decrypt
the message) then am I not revealing the password in the encrypted file?


The answer here is a qualified no. If the encryption method (but not the key) is known, a horrendous amount of computing power might be able to determine the key.

---

Okay. Let's say I have a total of 50 characters I can use to represent other characters to write to what will be the encrypted file. (i.e. Uncrypted 'E' = Encrypted 'O') Doesn't that mean that I have a total of 50 passwords that could be used to make the encrypted file unique to that password?

For example, if I only had the 50 characters but used 100 passwords, each message could be unencrypted by a total of 2 passwords, right?

If I wanted to make each message encrypted unique to a single password, then I would have to use a method that would let me have as many ways of representing a character as there were possible passwords, correct?

BTW- Is there a difference between unencrypted and decrypted? Is one more "correct" than the other?

Also, I know I'm kind of dragging this out but I'm really interested and having fun learning about it and an encryption post a couple of weeks ago got over 70 replies!

If done correctly using only 50 chrs you can have a total of 50^50 passwords (8.8817841970012523233890533447266e+84)
or is it 2500?
You could encrypt it with a 32bit file crc before or after compressing the file. You could also process the file more than once (although you would want to change the password dynamicly for each process)

I know this was just an example but you don't really want to use the E=0 method as that can be decyphered by the human mind easily, in fact they have a game of that design.

Oh well, learn lots and have fun...

I do not think that any one uses the term "unencrypted." I think this would mean "never been encrypted." (Usually called "clear" text). Decrypted refers to clear text resulting from a decryption process.

I think some of your comments refer to substitution methods, which are considered totally insecure.

First, consider the purpose of encryption. There are two possibilities: One for completely private purposes; Two for communication with others. I do not think there has been much effort expended on methods for the first purpose. I guess there are techniques possible which are probably uncrackable and not too difficult to use.

Practical considerations come into play when considering encryption for use in communication with other people. The main problem is informing the other person(s) of the method and the key. It is not practical to devise a scheme with a huge number of keys and methods which vary often. If the method is to be reasonably safe, you need a computer program to do the encryption & decryption (safe methods require more effort than possible without a computer). Every time you change the method, you must transmit a new program. If you think the current method is not safe (why else change the method or the key?), then how do you send the new method and/or key? Sending it encrypted using the old method/key is supposedly not secure. The military, spook community, & the diplomatic service refer to this as the "down stream loading" problem. They solve it by sending a man with a gun, a cyanide pill, and the new method/key in a booby trapped briefcase.

Due to the down stream loading problem, frequent change of method is considered impractical. Keys changes can be scheduled in advance. Id est: Use Key-1 for the next month, then switch to Key-2. The first message sent using Key-2 contains the key to be used when Key-2 expires. It is generally assumed that the encryption method will become known to potential crackers. Hence most efforts are directed toward the use of methods involving a key long enough to be safe from trial & error cracking methods. For example: A 512-bit key requires 2^256 attempts to obtain a 50-50 chance of cracking the code. If you could make a billion tries a second, it would take about 3.67E60 years to get your 50-50 chance. Using multiple computers (or array processors) can cut the time down some (NSA computers have a thousand or more processors working in parallel).

The "Public Key" methods use mathematical processes referred to as "Trap Door" Functions. The term refers to processes easy to work in one direction but difficult to reverse (Easy to fall though a trap door, but tough to climb back out). The down stream loading problem is solved because the key used to encrypt messages can be known without compromising the messages. One scheme uses the product of two large prime numbers. You tell the product to anyone who wants to send you a message (You could go on talk radio and broadcast the product). One might say that you solve the down stream loading problem by sending a key upstream. The process uses the product to encrypt messages. The decryption process requires knowing the two prime factors. I have read about this scheme, but do not know the actual method. At any rate, factoring 200-600 digit (or longer) numbers is a tough problem I do not think the spooks use this because they are afraid somebody will discover a way to factor big numbers. If I wanted to encrypt stuff, I would use the method, because I know that any mathematician solving this problem would publish immediately: Then I would stop using the method.

Not intuitively obvious is the fact that public key methods can be used in reverse to authenticate the sender of a message. If you can figure this out, you really understand the public key encryption concept.

You seem to really know your encryption, Guv. I enjoyed reading your response and understand the public key encryption better now.

About Glacius's reply, to anybody and everybody:

So are you saying if I used up to 50 characters per unencrypted character I would have 50^50 combinations? I could see how this makes sense. It would be an "inflation" utility with up to 50x the file space needed but I guess that's just the way it works.

You've gotten me confuzzed Glacius!

What do you mean by "encrypt it with a 32bit file"?
What does "crc" stand for? (character...recognition...oh I give up)
Define "dynamicly" as used with changing the password.

I realize the E = O idea would be pathetic, but (and I'm afraid to ask this) what about the E = EAsciiCode - PasswordAsInteger type idea where it is basically the same thing but it bases the encrypted character on the password? Would this work, theoretically?

Now that I think of it, it just might.
Follow this kind of like code section...

A = Unencrypted Character "E"
B = Password Character "G"
C = ((Int Value of B - A) * 7.5) Encrypted Character "O"

I used 7.5 just to follow the E = O example, and I realize it would need a little work, but it seems correct.

So Mr. Evil Cracker Maniac who wants to get my encrypted "E" character so he can access the nuclear missle silo will not be able to get it unless he runs through every key because he has to know what the original message was to be able to reverse the process and get the password! It's late (I'm not an all night programmer (well, not on a regular basis)) and I'm not sure if my brain is working so please tell me if my above realization is crap or on the right path.

And before I go- Here's some food for thought!

People can only remember a password that's however long, right? A sentence would be considered a pretty long password to remember. And right now all that's holding encryption together is that it is only breakable if you check every key. So what happens when computers get faster and faster but brains stay pretty much the same? All passwords up to a sentence long could be checked in say, 30 seconds or so, and encryption would no longer work! Could this be another Y2K no one sees coming? One of two things would happen if encryption basics stayed the same. 1) Computers would have to be stopped from getting faster by staying around a steady 20 ghz and making owning a faster computer punishable by neutering or 2) Our brains would be forced to memorize increasingly longer and longer passwords, artificially "evolving" our memory at an accelerated rate and the children's game in which you must memorize which animal is on the bottom of each card to make a match would be upgraded to be played with a grid of 3000 cards. If encryption did cause our memory to become ultra-powerful, our intelligence would have no choice but to follow, and humans would soon become smart enough to survive on other planets, travel to far away galaxies, and rule the known universe, all thanks to encryption!

Stick a fork in my cerebrum. It's DONE.

[Edited by krah on 09-10-2000 at 03:17 AM]