Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
quote:
An exception occurred when executing a COM method. The cause of this exception was that: AutomationException: 0x80004005 - Memory allocation error in 'Nsdpgp3Lib.PGP.1'. The error occurred in C:\Inetpub\wwwroot\EAMEDASHBOARD\pgp.cfc: line 319
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
Copy link to clipboard
Copied
One of the simpler things I tried for this is to use the BonCode PGP implementation from RIAForge.
It only implements a simple subset of PGP functions using armored files. Thus,
the examples given use armored/compacted files. These files have an .asc extension.
You can generate those using your PGP Desktop software and read the results with it.
For your simple example you pass in your content, your public key path to a function and it will encrypt it for you.
If you want to decrypt it you use another function passing in the key file location (the path to your key files you generated with PGP Desktop). It will need your private key path, your password, and your content to decrypt.
Copy link to clipboard
Copied
Not a very good title but check out my cookbook entry on how I handle PGP on my win server with Coldfusion.
http://cookbooks.adobe.com/post_How_to_execute_a_Windows__bat_file_-16396.html
Copy link to clipboard
Copied
CF has some "pretty good" encryption routines of its own which you might be able to use ... unless you had to use PGP.
Quite frankly, though, I think that encryption is often used too much. If, for exmple, you know that you are talking over an "https://" secured link, then you already have very strong encryption of the entire conversation between the client and the host ... even though all of it is entirely invisible to you. There is no incremental benefit to further encrypting the data that you are sending over an already-secure channel.
The built-in CF encryption routines are, of course, based on the underlying Java library implementations. If you need to encrypt data in a database, you might be able to use them. But once again, your database might already provide an encrypted store, in which case there is no incremental benefit to a cumbersome additional encryption layer of your own.
Anytime you "roll your own crypto," you run the very great risk of having a false sense of security. "If it's difficult to do, then it must be secure." That may well not be the case.
Copy link to clipboard
Copied
There is no incremental benefit to further encrypting the data that you are sending over an already-secure channel.
Sorry I but have to correct this, as this is just not true. The major difference is HTTPS is only point to point, using key pairs you ensure end to end security.
Copy link to clipboard
Copied
If you are dealing with a "man in the middle" situation, yes, you have to send encrypted material in such a way that it remains secure even if it is sent via carrier-pigeon.
It is extremely difficult, though, to ensure truly secure communications and message-integrity in such a situation, where the messages must make "an intermediate stop" or be entrusted to a potentially un-trustworthy third party message handler (such as e-mail). And once again, there might be a protocol such as S/MIME that would provide a "secure channel apart from the web-app itself."
So... if you can possibly avail yourself of "a secure channel apart from the web-app," one that goes without-interruption directly from source to destination and provides blanket protection to "anything and everything" that is sent along it, the situation will be much stronger than any other. Without it, any one of the applications can be "the weakest link."
A penetrator willl never attempt to hijack your system by breaking through the encryption directly, knowing that this isn't possible (unless their company name is NSA or MI6). They'll look for holes and weaknesses in how you handled your data, or for residual files left behind by your methods, or exposure of your private keys. They'll also learn a great deal from where the messages are going and coming. But if the only thing that they can touch is a channel, where everything in the channel is encrypted, they're in a much more difficult situation.
An encrypted channel also brings other benefits: message integrity, no "man in the middle," and so on. All invisibly and at no charge to you.