Encrypting 1

[rgw]

I've been trying out an encryption routine from an old Data Based Advisor article (using the foundation class in VFP). On a Windows 2000 machine running VFP9 seems to work fine--i encrypt the data and am able to bring it back as expected. Problem occurs when I run exactly the same routine on an XP or a Vista machine. I enter the password and the same key produces a different value so it will never be found when I try to find it. Bit of a nuisance as the application runs at work on both 2000 and XP.

I suspect I'm doing something silly but any help would be much appreciated.

rgw

 

[white605]

Bit of a nuisance as the application runs at work on both 2000 and XP"

Does it run correctly at work on XP machines?

wjwjr

This old world keeps spinning round - It's a wonder tall trees ain't layin' down

 

[rgw]

White 605

The XP and the Vista machines (both at home) generate the same result. The 2000 machine (at work) generates a different result. They run exactly the same code with the same key.

rgw

 

[Mike Lewis]

Rgw,

I wonder if this is a code page issue.

Are you storing the encrypted text in a character or memo field? If so, it could be that VFP is doing code page conversion on it. If so, try storing the text in a binary field instead.

If that doesn't help, can you reduce the problem to the minimum reproducible code, and post that code here.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[rgw]

Mike

I dug up the original article and there is a comment in the code: "the default provider in Windows 2000 is different than the default provider in Windows XP. Your data may encrtypt/decrypt differently depending on the provider". The author used Windows 2000.

I'll see what happens at home where I have machines with all three operting systems.

many thanks
rgw

 

[rkolva]

If this is the article that uses the crypto class wrapper around the MS Crypto API calls I would suggest you look for another encryption option. I tried the same approach years back and I think it was Craig Boyd who alerted me to some underlying problem in the Cryptographic Service Provider that occasionally resulted in inconsistent encryption results.

I only discovered the errors after encoding and decoding thousands of records on test runs.

I believe Craig Boyd has an encryption/hash dll available on his Blog that works well.

http://www.sweetpotatosoftware.com/SPSBlog/SearchView.aspx?q=crypto

Sorry I can't be more specific on the specific issues but it was several years ago and once I came to the conclusion that I was wasting my time I quickly tried to forget about it.

Ralph Kolva

 

[rgw]

Ralph

I believe it was. I didn't have any trouble when it was machine specific--it encrypted/decrypted many thousands of records without a glitch. But it does make you wonder.

rgw

 

[Mike Lewis]

Rgw,

... the default provider in Windows 2000 is different than the default provider in Windows XP

That's almost certainly the root of the problem.

Clearly, it is not a good idea to use any technique that is OS-dependent. As Ralph says, there are other encryption tools available. The one I use is Milan Kosina's CryptPak.VCX. I don't have a URL for it, but it should be easy to find.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Olaf Doschke]

You can solve the OS dependancy by not using the standard provider, but specifically choosing one, that's avalaible in all OSes.

Bye, Olaf.

 

[Olaf Doschke]

more specific:

If you change the cProvidername property of _crptypi class in _crypt.vcx of the ffc classlib folder to "Microsoft Base Cryptographic Provider v1.0", this will work on all OSes.

The default is .F., which means at Init the cProvidername is set to empty string, which means the class uses the standard provider of the OS.

For already encrypted data that means decyrpting on the OS it was encrypted with the standard provider, then reencrypting with "Microsoft Base Cryptographic Provider v1.0".

Bye, Olaf.

 

[crabgrass]

This last post is the key. I had the same problem years ago when we moved into XP from 2000. I did it this way in the class definition.

procedure init
  this.oCrypto = newobject  ("_cryptapi", ".\classes\_crypt.vcx")
  this.oCrypto.cProviderName = "Microsoft Base Cryptographic Provider v1.0"
  this.cKey = "whatever"
endproc

 

[rgw]

Thank you all for your very helpful comments on encryption--it all seems to work very well using the _crypt.vcx. Zips through thousands of records encrypting/decrypting as required on 2000 or XP machines but...

I have a shiny new laptop running Vista and thought I'd try it out on the routine. Problem is that I can't seem to subclass the _crypt class. According to the class browser I have a missing or invalid _crypt.vct. I have reloaded VFP9 from the CD and get the same result.

The rest of the application seems to be as expected. I'd imagine I'm doing something stupid but any ideas would be appreciated.

Once again many thanks for all your help.

RGW

 

[Olaf Doschke]

The simple problem is restricted access in vista. Try turnign off UAC or work on a copy of ffc to the projects folder.

Bye, Olaf.

 

[rgw]

I thought the Vista problem was solved as I was able to drop the class onto the form but when I go to compile the application I get an error telling me it can't find the wincrypt.h file.

Any advice much appreciated.

RGW

 

[rgw]

Seems that I forgot to copy the wincrypt.h file over to the user directory. All well at the moment.

 

[Olaf Doschke]

simple rule in Vista: a normal user can't write in the programs folder. SP2 doesn't change that, it's intended and so there's nothing SP2 can or should do about that, it may be sufficient to be the main user of a computer, you may need run vfp as administrator or give your windows account write access to the vfp home dir.

In fact working on copy of ffc isn't the best solution, as some code uses home() to locate dependant libraries/classes. I think _crypt.vcx is rather self contained though.

Bye, Olaf.