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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users