need help for GPG 1.2.1 binary for REHL 5.8

[Henry Hertz Hobbit]

On 08/20/2013 09:43 PM, Snehendu Ghosh wrote:
> Hi Peter,
> 
> Thanks for your reply. 
> 
> In brief, the background is that we are replacing an existing
> iHub system which acts as a router for files transfer to and
> from Oracle EBS. In current system, for inbound interfaces,
> encrypted files come from third parties to iHub and being
> decrypted before sending to EBS. Similarly for outbound
> interfaces, files come from EBS, being encrypted in iHub
> before sending it to third party system.
> 
> Now the problem is the existing iHUb system is very old and it
> has 1.2.1 version for encryption/decryption. We are assuming
> all the third parties are using same old version for
> encryption/decryption in their side. And there is no issue with
> encryption/decryption in existing system. It is much stable.
> 
> We are not expecting any of the third party will make any
> changes in their side. That is the reason we want to go with
> the 1.2.1 version to minimize the risk.
>  
> Now assume a scenario, where we implement 1.4 version in our
> to-be system, encrypt a file with 1.4 version and send it to a
> third party. We are not sure if that third party will able to
> do decryption using a lower version.
> 
> We are working from Sydney, Australia. I don't know which time
> zone you are working in.
> 
> Can we set up a tele-conference with you today so that we can
> explain you our requirement ? 

I wish you more knowledgeable people would answer first.

I can not speak for Peter Lebbing but I believe there is a way
you can test this if you have two spare Linux machines and
something (your iHub?) with an existing 1.2.1 GnuPG on it.  You
want something with the 1.2.1 that you can control it manually.
This is sort of similar to what you do in creating a network on
a test rack before you roll it out.

1. Machine 1 - your old system
Backup the ~/.gnupg folder on the existing system with the
older gpg 1.2.1.  I have this desire to be able to put things
right back the way they were.  You will be adding a key you will
not keep.  Generate the public keys as usual for import on
machine 2.
	$ cd
	$ tar -cvf gnugp.tar ./.gnupg
	$ mkdir save.gnupg
	$ cp -frp .gnupg/* save.gnupg
	$ gpg [-a] --export...

2. Machine 2 - Linux system with the latest 1.X GnuPG on it.
Create dummy new keys on this system.  Import the public keys
exported from machine 1.  lsign them or sign them as desired.
Export the public side of your secret keys on this system and
import them onto machine 1 and lsign them there.  Note that
you CAN have pre-existing key-ring on this system.  If you
don't want to use its keys in the test do:
	$ cd
	$ zip -r9 gnugp.zip ./.gnupg
	$ mv .gnupg  save.gnupg
	$ gpg --gen-key ...

Do some tests of PK enciphering on machine 1 and deciphering on
machine 2 and then enciphering on machine 2 and then deciphering
on machine 1.  If these work your battle is almost over in seeing
whether it works or not.

3. Machine 3 - new Linux system with the latest 1.x GnuPG on it.
Again like machine 2 if you have a pre-existing ~/.gnupg you
won't be using it so set aside for a while:
	$ cd
	$ zip -r9 gnugp.zip ./.gnupg
	$ mv .gnupg  save.gnupg
Somehow copy that gnupg.tar file from machine 1 onto this system
and untar it into the user you are using's top level folder.
Be sure to delete the ~/,gnupg/random_seed file to force it to
create a new random_seed file.  Import the public keys from
machine 2 and lsign just the way you did before.

Now do some tests of PK enciphering on machine 2 and deciphering
on machine 3 and vice-versa.  I don't know whether these scripts
will make things faster or not. Put them in ~/bin and make sure
you change the key number to yours:

http://www.securemecca.com/public/GnuPG/
http://www.securemecca.com/public/GnuPG/pcrypt.txt
http://www.securemecca.com/public/GnuPG/decrypt.txt

Once the tests are all done you can put things back the way
they were:

Machine 1:
	$ cd
	$ rm -fr .gnupg ; tar -xvf gnupg.tar
	# remember you have a second  ~/.gnupg backup: save.gnupg
	# I always like multiple ways back from a disaster

Machine 2::
	$ cd
	$ rm -fr .gnupg
	$ if [ -s gnugp.zip ]
	then
		unzip gnupg.zip
	fi

Machine 3:
	Same as machine 2.

If all the enciphering and deciphering tests work you almost
invariably won't have any problems.  But these tests will give
you a fairly good feel for it before you dive in.  Just don't
take the machine with GnuPG 1.2.1 down just yet.  The tests
wtth machine 3 can give you a pretty good idea of whether or
not you can just keep on using your current keys on the new
system with a newer version of GnuPG.  I do know I have continued
using keys generated with an older 1.x version with subsequent
newer versions with no problems.  That rather than the PK
enciphering and deciphering with different versions MAY be more
of a problem than enciphering / deciphering and signing using
the old keys created with an older version of GnuPG

No conference call with me is necessary.  You may want one with
Peter.  Depending on whether the GMT line is to the east of you
and the International Date Line is to the west of you or vice
versa we may not even be on the same day.  Now you know why so
many militaries shifted to using Zulu time in World War II.

Better safe than sorry.  You take even greater precautions with
creating networks and can still have a disaster so there you
need a way back to what you had.  IOW, what I did here was just
the test rack.  But by just doing it you will get a pretty good
feel for whether you will have problems or not.

HHH