Description: This small article was actually a response by Russ to a fellow programmer on the VISBAS-L Discussion List. I thought the reponse interesting enough to serve as a 'backgrounder' for people who may need this functionality. Russ claims to be no expert on the subject but for those of us just starting out it provides some good background material. Re-printed by permission.
Controls needed: N/A
Level: All

There's several different ways this can be done fairly easily, but it
depends on why the data needs to be encrypted. Anything that is
encrypted also needs to be UN-encrypted later.

If the application is secure at both ends (like for an e-mail program),
you can save the text and then shell to an external encryption program
for the data. No coding necessary, just find whichever program you want
and use it on the files created.

If the data needs to be encrypted so that the user can't view it, you
need to encrypt in your program to make it secure. How safe the data
needs to be is a big question. Any encryption can be overcome by
default, otherwise, nothing would be able to UN-encrypt and use it.

All that needs to be done for encryption to work, is to not let the
unauthorized viewer know HOW it was encrypted. You need to know who will
be trying to decode the data and what their capabilities are.

For keeping your little brother out of your e-mail, you can simply read
each character in and convert it to a number, then add or subtract a
"changing" number to each character so that it's not a *simple* job to
crack it.

The "changing" number is the key for the encryption algorythm. You can
have a set key for your program if every copy of your program should be
able to read every file created. Or, you can ask for the "key" number
from the user who creates the data file to be saved if only certain
users should have access.

For example:

This assumes that you are reading EACH character from the data and
assigning it to the string variable "temp" and that the "key" (or
"password", if you like) consists of 5 integers (array) whose names and
values are key(1) 6, key(2) 14, key(3) 94, key(4) 49, and key(5) is 22.
"temp" is converted to the integer variable "cryptcode" for saving to a
random access file.

----------

NOTE:This code only illustrates the logic behind this 
type of encryption. If you want to try some working
examples check out the Want More? section 
at the end of this article.


   Dim cryptcode, n As Integer
   Dim x As Long

   'Assign key codes here, either coded (this example) or read from a
"password"...

   Dim key(1 to 5) As Integer

   key(1) = 6  
   key(2) = 14 
   key(3) = 94 
   key(4) = 49
   key(5) = 22

   Open "coded.dat" for Random As #1 Len = 2   'Integers take 2 bytes

   For x = 1 to Len(Text1.Text)
      For n = 1 to 5

         'Get next character from Text1.Text and assign it to "temp"
here...
         'Sorry, no code handy to include...

         cryptcode = Chr(temp) + key(n)
         Put #1, x, cryptcode
      Next
   Next

   Close #1

----------

If Text1.Text was "Visual Basic" this would make the file "coded.dat"
*look* like this (to anyone who simply read in the data as integers
trying to see what it was):

   92 119 209 166 119 114 46 160 146 137 111 113

Notice that the "i" and the "a" have the same value in the coded file
because of the formula, yet both the "a" in "visual" and the "a" in
"Basic" have different values. A longer key set will make things more
obscure.

   V   i   s   u   a   l      B   a   s   i   c
   92 119 209 166 119 114 46 160 146 137 111 113

This is a VERY simple method of encryption, but it works. To undo the
encryption, simply read in the integer values one at a time, and (using
the same "key" numbers and method) *subtract* key(n) from the value and
make UNcrypt = Str(temp). Basically the same code in reverse...

Even though it's simple, it can still be extremely difficult to crack,
depending on your formula. It's possible to only use part of the "key"
along with the length of the "key" and even the length of the file to
make things really obscure. Read a value from the Win95 registry. Read a
value from an INI file. You can also RE-encrypt the already encrypted
data with yet another "key" and do it several times (yet another key?)
to make things nearly impossible.

Other things that can make the data safer is to add in "garbage" while
encrypting and take it back out on unencryption. Use the File name,
size, date, or time as part of the formula (note that if they are
changed, you'll never get the data back, even with the proper
UN-encryption). Write the data backwards, or in a coded order. Every
part of the formula adds yet another level of encryption.

Most encryption "hacking" programs simply try all the different
keystroke combinations until they find one that works. For that reason,
you also need something other than the keyboard input "password" to make
the document truly secure. You could poll the task list and make sure
there were no other programs running at the same time to help with this
problem. Disconnecting networks will also make things more difficult.
Change something obscure each time the password fails and use a
different "password" formula. This will cause the key itself to change
each time it fails. You'll need multiple key orders in this case.
Forcing the file to be read from the A: drive and a second "key" file to
be read on a separate disk make it very difficult to automate hacking
the program. Forcing Windows to reboot every time the password fails
would really slow things down.

For VERY sensitive documents, the UN-encrypting program should always
perform CRC checks on itself at numerous points in the code. This will
help keep the program itself from being cracked to make it possible for
the brute force hacking programs to work. If the CRC changes, don't stop
the program from running. Just make it fail the encryption every time.
The hacker will *think* he has cracked your program (because it still
runs), but will never get it to work. If the CRC fails and the program
displays a warning, or erases itself for protection, the hacker will
simply re-install it and start again. He will also know to NOP out that
Call too... Never let the person on the other end know anything that
they can use. Always make them *think* they are smarter than you.

You could even change many obvious things that really have nothing to do
with the encryption to make hacking the program very intense. Make them
spend hours cracking something that doesn't matter. Just don't display
any messages that taunt the hacker. Then it gets personal, which is what
good hackers thrive on. The really good ones don't crack programs to
save $59.95. It takes them hours on end to do it. They do it to prove
they are better than you. Let them believe it. PGP is named "Pretty Good
Protection" for a reason. If they named it "Uncrackable Protection", it
would be a bigger target than Oprah Winfrey's refrigerator.

Just remember that the ONLY thing necessary to crack the encryption is
the formula. Keep it secret and it would cost millions of dollars and/or
thousands of hours to crack a heavily coded document without knowing
that formula. It would be easier to disassemble the program that does
the encryption and hack the formula from that aspect. Use multiple
programs that share key infomation and CRC check each other to avoid
this method of getting hacked.

Make it as simple or complex as you like, but most people can't even
solve cryptoquotes in the newspaper.

Hope this helps...

Russ...