And encryption does not automagically provide security. Your naivety here is touching, but dangerous.

What? Encryption does not provide security? Maybe not "automagically", but neither would some security method that he is describing, it would be nothing more than "flock", unless it used encryption.

As far as the windows scheme to do it, I'm only hazarding a guess from memeory, because I don't even boot windows anymore. It's been years. But I remember hacking some registery entries, trying to find some software key, and windows had some sort of "encryption ring" in the registery, where software writers could put id's and keys ( and who knows what else) to prevent people from running programs without authorization. It could( and probably is) used to hide data from unauthorized access.

But considering how easy the crackers come out with patches to bypass all this "security", I would say it's worthless, except to keep the "honest guy honest". It won't stop the person with bad intent.

But proper PGP encryption of data is about as good as you will get, as long as you don't consider Tempest style snooping. (Which is probably more widespread than people want to admit.)

Encryption can form part of a secure system, but regardless of how good your encryption is you still need to manage your data safely, and if you don't manage your data safely your encryption becomes irrelevant. Consider that you need to decrypt your data if you are to use it. You now have plain text, in a variable, in memory, which you are going to pass around a few method/function calls. Plus you have your key, as plain text, in a variable, in memory. You're probably going to pass the data to some code that you didn't write. At this point, you wish that you could somehow set a flag on your data to prevent it being written to a file, for instance - even if you audit all the code, including all its dependencies, are you sufficiently sure you didn't miss anything? Security audits are Hard.

Three years ago there was a tax evasion case in Denmark where the police "broke" the encryption on some files on computers they'd seized. Turns out that they didn't break the encryption at all, they retrieved the data and keys from plain text left on the disks.

I agree with what you say, but you may have missed the point I made in my original reply. My point was:

If ssl is being used to transfer the data over the net securely, why not take it one step further, and use the same techique to encrypt the form data, with another separate public key, which can only be decoded by the receiver with his private key.

Now you have a situation where if the "store" is on a shared server, the decoded param data is still encrypted with the store owner's public key. Now, if the store owner can trust the physical and administrative security of the shared server, he can decode his param data and do what he wants.

But if the store wants to be secure, the actual cc verification and data storage would be done on another machine. The encrypted cc data would never be decrypted completely on the shared server. Now this would allow for you to "farm out" the verification to a third party (who would have possesion of your store's private key, and be held legally liable for it's security), or you could do it on a "secure compter" at your place of business, if you knew how to setup the network.

So all that would be passed around on the network, would be pgp encrypted data, or "transaction number approved" or "transaction number disapproved".

The only thing preventing this type of security is that the main browsers (IE and Mozilla) don't support pgp encrption of form data. It has ssl, but not encryption of the form data itself. It would not be hard to implement at all.