GPG encryption and decryption takes excessive time.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GPG encryption and decryption takes excessive time.

Green, Ian

Hi

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.

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 file.

 

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

 

I have tried recreating the keys locally, but no change.

The other party says that encryption / decryption at their end takes in the order of 50ms per file.

 

Can anyone suggest anything to help reduce the time to something more viable?

 

Thanks

Ian

 

 

 

______________________________________________________________________________________________________________________

This message and any attachments are private and confidential. If you have received this message in error, please notify us and remove it from your system without copying or distributing.

Cartesian Limited is registered in England and Wales with number 3230513. Registered office: Descartes House, 8 Gate Street, London, WC2A 3HP.

www.cartesian.com


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: GPG encryption and decryption takes excessive time.

Dashamir Hoxha
On Mon, Feb 19, 2018 at 2:30 PM, Green, Ian <[hidden email]> wrote:


Can anyone suggest anything to help reduce the time to something more viable?


Try symmetric encryption / decryption. 

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: GPG encryption and decryption takes excessive time.

Peter Lebbing
On 19/02/18 21:06, Dashamir Hoxha wrote:
> Try symmetric encryption / decryption. 

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.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPG encryption and decryption takes excessive time.

Peter Lebbing
On 19/02/18 21:54, Peter Lebbing wrote:
> Since symmetric mode of GnuPG uses passphrase stretching, [...]

Obviously I meant key stretching.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>



_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPG encryption and decryption takes excessive time.

Ben McGinnes
In reply to this post by Green, Ian
On Mon, Feb 19, 2018 at 01:30:06PM +0000, Green, Ian wrote:
> Hi
> 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
else?

> 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
> file.

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:

    iostat -En

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
beyond that.

> 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
digress.

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
portable version).


Regards,
Ben

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (235 bytes) Download Attachment