Endpoint Encryption

I have a PGP open standard public key that I can't encrypt to.  All low hanging fruit has been explored, i.e., the key has been signed by me and is verified.  I've attached the key here.  I was able to encrypt to this key with another PGP service that is different then the third party program used to create the key with no problems. 

Any help is greatly appreciated.

Attachment(s)

D18A6B26.zip   1 KB 1 version

I was at first also unable to encrypt to this key, and thought the problem was due to it not having any ciphers enabled.  However, I just looked at the key again and saw that it was disabled.  After manually enabling it, I was able to encrypt to it.  So, I think this is probably the problem:

By default, PGP will check the Global Directory to periodically update any keys you have that have been associated with the Global Directory.  The key becomes associated with the Global Directory when they are placed there by the owner of the key.  If you still have the key server synchronizations set on the Keys tab of PGP Options, and if the key has been removed from the Global Directory, PGP will interpret this as the owner of the key no longer wanting it used, and will therefore disable the key on your keyring so that it will not be used.

If this is the problem, you should be able to resolve it by either having the owner of the key place it again on the Global Directory, or you disabling key synching, and then right clicking on the key and selecting the Enable option.

I have the key enabled and I've disabled key synching and I still can't get it to work.

Is your computer date set correctly?

What PGP version are you using?

Can you use other public keys okay?

Are you just trying encryption to just this key, or perhaps have PGP set to also always encrypt to your key (set as a Master Key).

1.  Yes.

2.  PGP Desktop 10.3

3.  I can email to other PGP keys to include yours.

4.  I'm just trying to encrypt to this key.

This is probably a silly question, but does the public key's User ID have the email address that you are sending to?

Is there some kind of error message when you attempt this encryption?

Can you encrypt a file to this public key?

What does the PGP Log indicate when you attempt this email encryption?

The user has a different email address but same domain.

I don't get an error message, simply, key not found.

When I attempt to encrypt a file I do not see the key as an option on from the 'all keys' keyring.

Below is the log when I attempt to encrypt email:

16:54:16 Email     Info    Processing outgoing message from [me] with subject: test
16:54:26 Email     Info       Message has been blocked by sender
16:54:30 Email     Info    Processing message from <System Administrator> with subject: Undeliverable: test
16:54:30 Email     Info       Decrypting AES256-encrypted message with key [me] (0xDA537975:0xAF731359).

The PGP email proxy selects the public key for encryption by the email address you are sending to, so it must be the address in the key's User ID.

That's not the problem since the email address is the same.

You mentioned encrypting a file earlier but that key doesn't show up as an option to even encrypt a file.  This is something more fundamental about PGP not recognizing the key.  Attached is the screen shot from my keyring if it helps.

I'm seeing the same Key Properties, but I'm able to encrypt a file to it.  Maybe try deleting it, and re-importing it, then signing it, and enable it.

.

I've tried that a few times but I still can't get it to work.  One note, after I import and sign it I already see it marked as enabled.  I have tried disabling and re-enabling it but that doesn't help either.

Does this have something to do with me running the trial version of the software?  Tom, do you have the same version as I have?

I have a different version, but am pretty sure I just found the problem.

When I said I could encrypt a file to the key, this wasn't actually correct.  I was using the Current Window option to encrypt Notebook text, and this does work.  But actually, it shouldn't.

When I try encrypting a file with PGP Zip, the key is not availble for encryption.  And it turns out that it shouldn't be.

For any recent version of PGP, the key's User ID has to have a valid self signature.  This is automatically done when recent versions of PGP generate a key.  I had checked before to see if this key did, and it does have a self signature.  But with my current review of the key's properties I see it's description as "RSA signature corrupt."  So the problem is that somehow the required self signature of the key has become corrupt. 

This might possibly have occured in the public key being copied, or during Internet transfer of it.  If the cause was something like this, having it sent to you from the owner again, might take care of the problem.  If the key's owner has his/her key with the corrupt signature, the problem should be resolvable by now signing the key's User ID by the key itself; just as he/her would sign any else's key he/she wants shown as Verified.

Tom,

I've had him send me the key twice so I know it most likely isn't becoming corrupt during transmission.  Howver, I'm going to check with him to see if he can signed his own key and resend to me.  I'll let you know soon if that does the trick.

Tom,

Specifically - which parts of the key is their app failing to process?  The signatures are correct as far as I can tell and I used 2 different PGP implementations to verify them.  What is causing their app to ignore the settings in the primary signature when other PGP apps recognize them just fine.

John

In All Keys, go the the View menu, select Columns, and enable Description.

Click the + to the left of Sergey's name.

Click the new +

Click on the User ID (Name & Email address)

In the Description column, see "RSA corrupt signature"

The key's self signature is corrupt. It needs to be signed again.

Tom,

In my view it doesn't say "RSA corrupt signature" but that might because I signed the key myself.  If I did sign it I shouldn't have these problems correct?

John

Sergey's signature should display in the Description as "RSA signature," instead of "corrupt RSA signature."  Your signature will show that you believe the User ID is valid, but it is his signature that shows that no one had altered his User ID.  As I've said, the key must have a vailid self signature, and it does not.  The answer remains that he needs to again sign his key, just as he would anyone elses, and as you have his.

Were you able to try the key with it having a valid self signature?

It looks like the key was generated using an Open PGP standard client as evidenced by the key block data showing this:

Version: iPGMail (1.45)

I found their website here:

http://ipgmail.com/

It looks like the developer has his own key. Found here:

http://ipgmail.com/support/

Interestingly enough, his key (generated in an older version of the client)

Version: iPGMail (1.14)

When I access his key with Symantec Encryption Desktop 10.3.0 client works fine. All the key properties look correct. see screenshot attached. I suspect maybe a bug in the way the key was generated on their application side or maybe a new signing feature introduced in this 1.45 iPGMail version that is not working with our product? Can you generate a new key in the application and duplicate the same behavior?

using dpgdump.net to view the packet information of both keys. It looks like the key that is not working correctly has some different attributes on the signing key:

New: Signature Packet(tag 2)(316 bytes) Ver 4 - new Sig type - Positive certification of a User ID and Public Key packet(0x13). Pub alg - RSA Encrypt or Sign(pub 1) Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Mar 29 16:15:33 UTC 2013 Hashed Sub: key flags(sub 27)(1 bytes) Flag - This key may be used to certify other keys Flag - This key may be used to sign data Flag - This key may be used for authentication Hashed Sub: key expiration time(sub 9)(4 bytes) Time - Thu Jan 1 00:00:00 UTC 1970 Hashed Sub: preferred symmetric algorithms(sub 11)(3 bytes) Sym alg - AES with 256-bit key(sym 9) Sym alg - AES with 192-bit key(sym 8) Sym alg - AES with 128-bit key(sym 7) Hashed Sub: preferred hash algorithms(sub 21)(5 bytes) Hash alg - SHA256(hash 8) Hash alg - SHA1(hash 2) Hash alg - SHA384(hash 9) Hash alg - SHA512(hash 10) Hash alg - SHA224(hash 11) Hashed Sub: preferred compression algorithms(sub 22)(2 bytes) Comp alg - ZIP <RFC1951>(comp 1) Comp alg - ZLIB <RFC1950>(comp 2) Hashed Sub: features(sub 30)(1 bytes) Flag - Modification detection (packets 18 and 19) Hashed Sub: key server preferences(sub 23)(2 bytes) Flag - No-modify Sub: issuer key ID(sub 16)(8 bytes) Key ID - 0x64D95104D18A6B26 Hash left 2 bytes - 08 00 RSA m^d mod n(2048 bits) - ... -> PKCS-1

The key points that are different from your key and the Developers key that i found on their site is that your key has a SHA256 hashing algorithm. I would try generating a SHA1 key and see if that helps (this is typically the default still used today). Maybe there is an issue there?

The other strange part is that it shows the signing key expired in 1970.  I have seen similar features in our product related to a key that never expires having an older date like that.  Maybe it has to do with this RFC:

http://www.ietf.org/rfc/rfc1991.txt

Just in case, when you generate a test key, try no expiration date and also an expiration date in a year or so and see what the differences in the keys look like on pgpdump.net and then Encryption Desktop

at any rate, I like Tom's recommendation of self signing the key also. as this should get around that issue. Did that seem to work for you as well?

it looks like iPGmail is not following RFC 4880

http://tools.ietf.org/html/rfc4880

According to 5.2.3.8 and 5.2.39 as well as 9.4. If the key is self-signed.

They MUST be defining an hashing algorith as SHA1 at least and they MUST allow NO compression on the keys as well.  On the primary key they are not showing NO compression as a preferred compression algorithm. From pgpdump.net (of the public key you attached guten_tag)

Hashed Sub:

preferred compression algorithms(sub 22)(2 bytes)

Comp alg - ZIP <RFC1951>(comp 1)

Comp alg - ZLIB <RFC1950>(comp 2)

Hashing algorith on the Signature Packet:

Hash alg - SHA256(hash 8) Hashed Sub: signature creation time(sub 2)(4 bytes) Time - Fri Mar 29 16:15:38 UTC 2013

This appears that it could be a problem with the way the key is generated. but we have had similar reports from customers on keys generated by bouncy castle who claims to support RFC 4880 also. So I'm opening a query on our side with development to see what they have to say about this.

Your interpretation of the RFC is incorrect.

Section 9.4 only says that an IMPLEMENTATION (i.e. GnuPG, iPGMail, Symantec PGP products) must implement SHA1, it places no restriction on the hash algorithm that the generated keys must use as their default.  SHA256 is perfectly acceptable, especially given the weaknesses in SHA1.  My app will support the use of SHA1, especially when verifying a signature generated from somewhere else, but it creates signatures using the stronger and more preferred SHA256.

http://tools.ietf.org/html/rfc4880#section-9.4

5.2.3.8 and 5.2.3.9 also place no restriction on the hash or compression algorithms that must be used, they only state that those fields are only present in a self-signature, which is exactly the kind of signature in question.  

http://tools.ietf.org/html/rfc4880#section-5.2.3.8

-Will (aka  @ipgmail)

Hi,

The public key is not appearing as available key on PGP Desktop V9.8.3 but were able to import it. Please advise a resolution for this

Please look into the screenshots where in  PGP key is imported properly but were unable to list out the key for encryption. please advise