I am frustrated with encryption.. 1

Mansii,
Couple of questions for you:
1) How "Secure" an encryption are you seeking? If you just need simple encryption, you can use any number of algorithems to encrypt/decrypt your data.
2) Is it really necessary for you to encrypt your data field names? If not, than option 1 is still very vialbe option for you.
3) VFP8 has the same _crypt.vcx that VFP7 has. (I've checked them, they have the same date, and file size). So, don't hold your breath. Again though, I'd say, what level of encryption do you really need?

I have provided an encryption function in one of my previous posts, and if you rearrange the order of the lcCode characters, you have a reasonably secure encryption method that no one else can use, unless they decypher your replacement string (and that's 255 chracters long, with non-ascii values, so good luck!)

I took a look at _crypt the other day, and it is very complicated. I have not yet had a chance to sit down with it, and pound out what it will do. However, I don't think it's going to provide the same type of encryption as Cryptor. In that, it will still result in showing you the field headings. (Don't know for sure yet, but it looks like field level encryption to me, not table level).
I'll give it a play tonight, and see if I can come up with something else. In the mean time, consider my previous code. Simply drop it into your common procedure file (whatever you SET PROCEDURE TO <filename>) and place that in your startup. That places the function into use anywhere in FoxPro. You can then simply pass: lcValue = ENCRYPT(Database.Filed,'E') to encrypt, and lcValue = ENCRYPT(Database.Field,'D') to decrypt.

Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

Mansii,
Okay, I've played with it a bit, and have gotten it to work. The code I'm stealing here is from the Solutions Foundation class example, which you can take a look at as well, but it is pretty straight forward.

There are a number of ways that this API works. The two key being Stream, and Block encryption. The only difference between the two is, one encrypts based on the size of the item to be encrypted, and returns an encryption string the same length as the item. The other is Block encryption, and that always returns a block, regardless of how long the item is, as you specify the block size. The size of the block has to be at least the same size as the item to encrypt.

In this example:

* Determine if the API is installed and registered
*Put this in your Form's INIT.

IF !THIS._cryptapi.GetIsInstalled()
MESSAGEBOX('Crypto API is not installed properly. Ensure it is registered with your OS.')
RETURN .F.
CANCEL
ENDIF

* Put this on your Encrypt routine:

LOCAL lcEncryptedStream,lcPassword,lcKey
lcEncryptedStream = ''
lcPassWord = THIS.Parent.txtPassword.Value
lcKey = THIS.Parent.txtKey.Value
IF THISFORM._cryptapi.EncryptSessionStreamString(lcPassWord, lcKey, @lcEncryptedStream)
THIS.Parent.txtPassword.Value=&quot;&quot;
THIS.Parent.txtPassword.Value = lcEncryptedStream
ELSE
MESSAGEBOX(&quot;Error: &quot;+MESSAGE())
RETURN
ENDIF

It uses stream encryption. What you do is, create a form, and drop the _crypt.vcx onto the form. This will place the FFC (FoxPro Foundation Class) onto your form for use. (Or, you can create an instance of it in code, if you're not using a form).
Next, on whatever &quot;Magic&quot; function you'll use to encrypt the data (like a click event on a button), the above example encrypts a string of text when the Encrypt button is clicked. The parameters passed to the _cryptapi give it the string to encrypt a &quot;Password&quot; used to encrypt/decrypt the value, and the type of operation to perform (stream encryption).

You can easily adapt this code to encrypt/decrypt fields in a table as they are read/written.
In the &quot;Solutions&quot; project (which you can run, and demonstarte how this works), there is also code on how to utilize it for public/private key encryption (as apposed to &quot;Password&quot, and how to do block encryption, among other things.
Now, unfortunatly, it is NOT a table level encryptor, so as I had speculated before, your field headings will still be visible in a brows window, though the data in your table will look like a jumbled mass of junk. Which, is in most cases, more than adequet.

Hope this sheds some light on the _crypt.vcx for you, Mansii. If you still have troubles, let me know, and I'll try to help some more.
Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

Hi Scott!
Yes, I have tested the _crypt.vcx too but it doesn't satisfy my need.

Your previous code is so great, tricky, and useful (You deserve a star for this, and for your effort!). Hope that you don't mind if I ask you some explanation about your code someday.

But, the situation is that I want a table level encryption so users can't see or edit it's contents from anywhere outside the system. For example: users can't browse the table from the main VFP window. Only the system allows the users to browse the table.
So, the fields doesn't need to be encrypted as long as the table is encrypted. Am I right?

Any suggestion on table encryption?

Thank's for beeing patient with me.

Regards.

mansii

Mansii,
Well, the beauty of either the _crypt or my encryption code is, you control when it gets decrypted, creating exactly what you are looking for. Let me explain:
If you encrypt the table's data, (field by field, or on mass with something like

REPLACE ALL FNAME WITH ENCRYPT(FNAME,'E')

If a user then just comes along and &quot;Browses&quot; that table, the data will appear (and is) encrypted.

Unless you have some application that decrypts the data in between so that it can be &quot;seen&quot;, it will appear encrypted to anyone outside the system. In order to get my code to work, you would have to actually have a copy of it, with the right replace stream.
_crypt, to be honest, is much safer than my algorithim, so if you want so real beef behind it, use it. It would then also require that you have the password, or public keys, depending on what you use.
In either case, you than create your application to be the &quot;thing&quot; that decrypts it, only when you are looking at it through your application, or a special utility that you build for doing special maintenance on it. I think this will be very effective for you. This is exactly why I created the encryption algorithem I use, becasue I needed to keep passwords encrypted, always. The beauty there is, I never actually decrypt the encrypted password, I simply encrypt the passed in password, and match that to my encrypted value. The prevents packets with the &quot;Decrypted&quot; password from ever getting sent around. Very sneaky, and very safe.

Oh yes, and many thanks for the star!

Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

REPLACE ALL FNAME WITH ENCRYPT(FNAME,'E')

Scott,
I think that this method works best on small records or in password encryption. My table has approximately 30,000,000 records, 20 fields. Wouldn't you think that it would spend some time in processing that line? Regarding to it's size, what about a crash that might happend in the middle of the process so that the table is half encrypted? Too dangerous for me.
Again, file level encryption is my major need. If there isn't any, I will consider your suggestion then.
Or you have other suggestion? (I know that you do. But you choose to save the best for last ). Surprise me!

Thank you for your time, Scott. And beeing so patient. Please stay until the problem solved.

Regards,
mansii

Mansii,
It is easy to mitigate your &quot;File crash mid-way&quot;. First, make a copy of the table. Then encrypt the whole thing. Once you've done it once, you will only need to encrypt/decrypt records as needed.
As for speed, the _crypt.vcx is VERY fast. Extremely fast, in fact. (Much faster than my routine.) 20 fields is not a great deal of stuff to encrypt/decrypt on a pre record basis. Yes, it will take some time to encrypt 30,000,000 the first time, but I have worked with my encryption on 6,000,000 record table, with more that 40 fields, and, at a transaction level, it is very fast. (And this is even on VERY old 486 machines some years ago, using FoxPro 2.6 for DOS. SO, I'm not too worried about the speed).
If you need to decrypt millions of those 30million records at a time, then, yes, I'd be worried.
So, once you have the whole table encrypted safely, you can then remove your existing table, and rename the new one to the old one, with no fear of data loss.
Outside of Cryptor, I don't know of any other &quot;Whole Table&quot; encryption solutions. And eveny Cryptor isn't necessiarly perfect. To encrypt the whole table under Cryptor, you still have to go through a process of encrypting the whole table, so you've got that either way.
If you have a nil budget, I'd recommend spending some time with the _crypt.vcx, play with a copy of that table, or a big piece of it even, to see what the speed will be like, and make your move from there. It truely is probably your best choice. Also consider whether or not you really need to encrypt every field. This may sound odd, but it may not be necessary. Once you have the key &quot;Identifying&quot; fields encrypted, the rest just becomes irrelevant data.
For instance, I may only need to encrypt my customerid, my customer's first and last name fields, before the rest of the data become irreliveant. If I can't tell who is 6' tall, and who has had a kidney transplant, than knowing those details really won't be of any use to me without know who that information belongs to. It just becomes useless information. Even address and phone number information becomes irrelivant if I don't know who it belongs to. So think about your strategy of the full need to encrypt every field in your table. It may not really be that critical. This will certainly save you processing time.
Some jobs will just require it. But, I think if you've got a table with 30mm records in it, you've been opperating for along time without encryption, so any improvment is at least better than your current position today. Accept an 80% solution for the moment while you either determine a better way, or get funding to secure another product. In either case, you're in better shape than you are full exposed.
Mansii, I'll stay with this thread as long as you like, and as long as I can continue to offer help, my friend.

Cheers

Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

Scott,
Thank you for your explanation. I realize in what situation I am now.
Let's assume that my problem is solved. Gotta establish the whole project until I find another problem.
Thank you for your precious time, Scott, and for patiently staying with me.

Till then, my friend.
mansii

Hi Scott, I'm back!
This time, I am asking you to take a look at
{ }.

Is this a kind of data encryption? If yes, what level? Table or field? Would you please use the easiest words to explain it to me.

Suggestions are invited.

Thank's a lot.
mansii

mansii,
Why not download it and see if any documentation is provided?

Rick

Rick,
I have downloaded it and tested it.
There's no such documentation in it. When I run one of the PRGs, it just shows some values on the screen. And I have no idea about these values.

Now I need some expert's explanations.

Regards
mansii

Mansii,
I had a look at this, and it is very much like _crypt.vcx, it just completes it's encryption in a slightly different way. I would say, it's probably slightly more secure the _crypt, but both are strong solutions. It is not a table encryptor like Cryptor, however. So, you are still working at a transactional level, or field level, as all the other products.
I still think, while it would take you some time to do, though with the right sub-class of the controls, you could build it in once, and forget about it, that you could implement any one of these types of encryption, not lose speed, for the most part, and still accomplish what you are after.
I will, of course, keep looking for you.
-Scott
Best Regards,
Scott

&quot;Everything should be made as simple as possible, and no simpler.&quot;

Got it Scott!
I think I'd better start writing down my codes now.
Glad to have you arround.

Regards,
mansii