On Aug 19, 2016, at 11:56 AM, Scott Linnebur <slinne...@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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to