GnuPG uses hybrid encryption. Content is already encrypted with
symmetric encryption, and only the randomly generated symmetric key, 16
or 32 bytes large usually, is encrypted asymmetrically to the recipient,
possibly twice as OP mentioned two customers.
Since symmetric mode of GnuPG uses passphrase stretching, I doubt that
would be faster anyway, though I haven't tried this.
The problem appears to be somewhere else. However, I think the OP should
provide more details. File sizes, specifications of the computers it
runs on, software versions...
My first instinct is: there is insufficient randomness, and GnuPG is
blocking waiting for more to become available before it can do any work.
On Mon, Feb 19, 2018 at 01:30:06PM +0000, Green, Ian wrote:
> Firstly, my knowledge of GPG is very weak and I am not a UNIX administrator, so my access and knowledge are rather limited.
> I have been asked to set up file encryption / decryption of files
> transferred between our SUN OS servers and two customer's servers.
What are the customers running? More SunOSand/or Solaris or something
> One customer is using a basic 2048 size key, the other a 3072 key.
> GPG has been installed and I have created my keys per the
> requirements of the clients and imported their keys without issues.
> I can encrypt files for them Ok and can decrypt the files they send me.
> However, the time taken to encrypt and decrypt each file is colossal
> - between 6 (2048 key files) and 15 seconds (3072 key files) per
How big are the files and what kind of files (as in file type rather
than business use case)?
> I have set this up on two different local servers (same OS) and get
> the same results.
> The server details are: SunOS ioponnet-kn-t1 5.10 Generic_142909-17
> sun4v sparc sun4v
It's actually SPARC? Not UltraSPARC? That hostname is hinting
towards a T1. Is it really or is it something else?
Also, which filesystem(s) are you running? ZFS or something ancient?
Are you trying to do this across NFS? Are there also either a SAN or
NAS involved, if so, which (and did it come tith the Sun kit or was it
hooked in separately.
Well, may as well try the easy bit first ... run this as root:
Check the drives for collisions, if two of them are reporting massive
numbers of collisions then one is dead and the other is on the same
bus and is getting overloaded by the redirected traffic (which will
slow the rest of the array down).
That's the usual problem, but if it's not then we'll see. Still
Solaris 10 has lots of nifty diagnostics tools to narrow things down
> Can anyone suggest anything to help reduce the time to something
> more viable?
Plenty, but I need to know what the system specs are before I can
determine what's actually feasible with that model.
The Solaris patch version indicates it's several years old as it is
and I'm guessing they're out of the warranty period. Or maybe not, it
could just be that now that Oracle have fired all the old Sun
engineers there's no one there who can help ... and the fact that the
E25Ks and the M9000s are truly doomed is such a damned waste, but I
Don't be too disheartened if the model was produced prior to Oracle's
acquisition of Sun either, most of those systems were still well ahead
of any of what we called "x-boxes" (i.e. the X-series or anything with
an x86-64 architecture; IIRC they were all AMDs). Besides, if it's
pre-2009, then I'll have at least a decent portion of the old SunSolve
handbook for the model in archive. Yes, that is the massive trove of
Sun documentation that Oracle took offline in the first 3 months or
so; and no, it's not the whole thing (which was *huge*), just the