File Encrypted with Primary key

[Scott Linnebur]

Thanks everyone for your help on this.  While I believe this is still an issue it wasn't the issue I was having.  Apparently MoveIT was using the lowest level encryption algorithm allowed by my public key.  I regenerated the key and removed the lower levels as options and all is fine.  Thanks again.

Scott Linnebur
IT Solutions Architect
(303) 846-6176 Desk
(720) 334-5206 Cell
slinnebur at redrobin.com


-----Original Message-----
From: David Shaw [mailto:dshaw at jabberwocky.com] 
Sent: Monday, August 22, 2016 4:13 PM
To: Scott Linnebur <SLinnebur at redrobin.com>
Cc: gnupg-users at gnupg.org
Subject: Re: File Encrypted with Primary key

On Aug 19, 2016, at 11:56 AM, Scott Linnebur <SLinnebur at redrobin.com> wrote:
> 
> I have an issue that I just cannot figure out.  What I’m trying to do is move a file between two organizations using two different transports while encrypting the file.  On one side they use ipswitch movit to encrypt the file and post it to a sftp site.  Then from my end I use camel to pick up the file, decrypt it and place it where it needs to go internally.  What I have done is generate a key pair with GPG and have given the other company my public key to encrypt with as well as imported the key rings into Camel.
>  
> Testing…
> They post the encrypted file and when my camel process pull is down I get the error “exception creating cipher”.
> If I manually pull down the file I can decrypt it fine with GPG.
> If I encrypt a test file with my own public key and feed it to Camel it decrypts fine.
>  
> This is where I think the problem is but I can’t figure out a way to prove it.  When I generated the key pair with GPG, it created a primary and secondary keys.  Primary has usage set to SC and secondary set to E.  When I look at the file they sent me, it’s encrypted with the primary key.  That file fails in the camel process but is successful in a manual GPG decyption process.  When I encrypt a file with GPG it uses the secondary key and I can decrypt it with Camel or manually with GPG.  I have a suspicion that is the cause but I can’t test it.  I can’t find anyway to force the primary key to encrypt and I can’t figure out how to generate a key pair without secondary keys in it.  Any ideas how to troubleshoot this?  The secondary party is not helpful and they are using their standard process with moveit to encrypt it and aren’t likely to change that, especially if I can’t prove that’s what’s wrong.

I have seen this before - basically the Moveit code is using a buggy/older OpenPGP engine that does the wrong thing and ignores key flags.  Your key has an RSA primary key, and their engine sees that and concludes that since it's RSA, it can encrypt to it.  GPG properly respects key flags so uses the subkey.

There is only one fix for this, but two workarounds:

1 (the true fix): Get Moveit to fix their OpenPGP engine.  That's likely not an easy task since Moveit most likely purchased it from an upstream vendor (I'm going to guess Symantec - I have a vague recollection the previous time I saw this was with the Symantec code), so the actual fix would need to be from the upstream vendor, then Moveit would have to integrate it, and then whoever you're communicating with would have to update Moveit.  Given that this problem still exists in 2016, I'm going to guess that a fix here is not going to happen any time soon!

2 (workaround A): You can generate a key that explicitly permits encrypting to the primary key.  Then both GPG and Moveit will encrypt to the primary and everyone can interoperate.  This is not ideal as it is best practice to split the signing and encryption capabilities, but should solve your immediate problem.

3 (workaround B): Don't use an RSA primary key.  Instead of generating a RSA primary key with an RSA subkey, generate a DSA primary key with an Elgamal subkey (or for that matter, an RSA subkey - what matters here is the primary is DSA).  This pretty much forces the Moveit code to encrypt to the subkey since there is no way to encrypt to a DSA primary key (it's a signature-only algorithm).

My advice would be to try workaround B first.  If they're using the same engine that I saw before, it was smart enough to handle that case and would properly use the subkey.

David