GPG with GPUs

[Hauke Laging]

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

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

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


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120616/b8ddfdc1/attachment-0001.pgp>