GPG with GPUs
mailinglisten at hauke-laging.de
Sat Jun 16 19:54:46 CEST 2012
Am Sa 16.06.2012, 08:15:05 schrieb Aaron Toponce:
> We use GPG at work for internal passwords. There are 3 XML files based on
> the role that they employee fills at work (techs, domains, admins). With
> about 50 exmployees' GPG keys, encrypting the 3 files is a bit daunting. It
> takes a few seconds to complete. Not too terribly inconvenient, and it's
> fully automated, but enough to be annoying when the XML files get updated a
Are these files huge? It's hard for me to believe that this takes seconds.
What I would easily believe is that the system gets an entropy problem. The
delay would not be related to CPU performance then. So maybe a hardware RNG
improves your situation.
> There are other purposes I use GPG for, where the work that needs to be
> done takes long enough to notice, such as signing 100 keys after a key
> signing party, or generating a new throw-away symmetric key.
> Anyway, just curious if offloading the work to the GPU is something that is
> being considered, or has already been discussed.
This reminds me of something I never dared mention of this list because
obviously certain people may freak out...
If the same file is quite often encrypted, decrypted, encrypted again one
might question the value of generating new session keys every time.
I would really like a feature like --override-session-key but not for
decryption but encryption. OK, this alone would not solve your performance
problem. Additionally it would be required that the session key packet could
be reused. This raises the question whether it is possible to create just the
encrypted data packet (without the pubkey enc packet). This is not possible by
gpg I guess but perhaps by gpgme. Shouldn't be hard to add an option which
does this to gpg as no new operation is required but just the leaving out of
If you get the data part created you can combine it with the old pubkey enc
packet. Symmetric encryption can easily be optimized for such hardware but
considering how many MiB per second you get through a simple CPU based hard
disk encryption I really doubt that this may be a bottleneck.
So you would save the time waiting for entropy and the time of the asymmetric
encryption. This would leave optimization potential for the signing process
(if you sign the files).
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users