Endpoint Encryption

I am using PGP Netshare 10.1 and am getting this message when I attempt to decrypt a file from a client. Can anyone tell me what the problem is?

How is the client encrypting the file?  If he/she is using PGP, what version is it?

OpenPGP Encryption Facility for z/OS V1.2.

I am downloading the file from an FTP site in ASCII mode. The original testing went fine, we discovered that if I download in binary mode, when I try to decrypt the file I would get a "bad packet" message, but when downloading in ASCII mode we were able to decrypt just fine. We've exchanged several test files with no problem.

The file we are attempting to decrypt now is returning that "an error has occurred: encrypted session key is bad" message. The client is stumped, and I am too. And I am under the gun from management to get this file processed. Which finding my way around the forum is not helping.

If necessary I could attach the file, but it's a 27 megabyte file.

In OpenPGP, data is encrypted to a symmetric key (typically a 256-bit AES key).  This is the session key. The session key in turn is encrypted to your public key.  This data block (session key encrypted to your public key) is in the file.

"Encrypted session key is bad" means that there was an encrypted session key block in the data, and the encrypted session key was encrypted to the KeyID of your public key, but when the session key was decrypted using your private key, the result wasn't a valid session key for the encrypted data.

Why might you see this error?  Some possibilities include:

- The data was corrupted somehow.

- There is a bug in the sending software, whereby the session key was encrypted to a key other than your encryption subkey but the encrypted session packet information listed your KeyID.

Something you could try is to download the sources to pgpdump (http://www.pgpdump.net/about.html) and dump out the file to see if all the packets parse properly.  (You could also download a trial version of PGP Command Line and use "pgp --dump-packets [filename]".)  You may also want to verify that the file you have is identical to what the sender created, by running a checksum (md5 or sha1 hash) of the file and comparing the values each of you get.

I'm not familiar with OpenPGP Encryption Facility fo rz/os, so don't know if it might use a hash, encryption algorithm, or compression that is not compatible with PGP.  There is a chance that downloading this particular file in binary mode might make a  difference.  If it is signed, sending it unsigned may make a difference.  If you are using an RSA key, your use of a DH/DSS key may be more successful.

If you are decrypting it by double clicking on it, or using the right click context menu, it may help to use the Open a PGP Zip file option in the PGP Desktop GUI.

When attempting to open the file from the PGP desktop using the Open a PGP Zip file option I get a message that the file may be corrupt. Download the file in binary mode produces a "bad packet" message. We tried that during the testing process. Another thing is that the testing was done with them manually encrypting the file, but what I am getting from the client is they are using Java to automate the process and I bet that has something to do with it.

How do I run a checksum on the file? That may be a good place to start. Thank you for your help.

Ok, I'll try downloading the file to pgpdump or try the commandd line version of PGP and see how that goes. While I know what a checksum is, what's a good software to use to run a checksum on the file?

Thank you!

There are a number of tools you can use to verify the integrity of the files.

- You could try digital signatures.  Your customer would sign the .pgp file after it is encrypted, and send you the signature; you then verify the signature using PGP Desktop.  A detached signature would work best here.  Given that you are having trouble exchanging encrypted .pgp files you may not have any more success exchanging signatures.

-  There are a variety of tools to compute checkusms.  On Windows, a simple tool is the Microsoft File Checksum Integrity Verifier, available at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=b3c93558-31b7-47e2-a663-7365c1686c08

Other tools exist such as openssl (run it as "openssl md5 [file]" or "openssl sha1 [file]").

I do not know what standalone tools exist on z/OS to calculate md5 or sha1 hashes, though the cryptographic facilities to do so are there.