dshaw at jabberwocky.com
Tue Feb 20 06:23:07 CET 2007
On Mon, Feb 19, 2007 at 09:20:44PM -0500, Christian Bienia wrote:
> I'm a computer science grad student at Princeton University and
> assistant instructor for the course COS 598A "Parallel Architecture &
> Programming". We're considering to offer GnuPG as a parallelization
> project to the students this semester.
> Our idea is to let a small number of students parallelize GnuPG with
> pthreads with some help and guidance from my side. After the
> parallelization, GnuPG will support encryption / decryption of a single
> stream with multiple CPUs (instead of mere thread-safety or
> multi-processing). Obviously, some cipher modes add dependencies between
> blocks which would make it very difficult to parallelize them
> efficiently, so the work would mostly focus on cipher modes such as CTR
> and stream ciphers. The goal of the project is to get a version of GnuPG
> which scales well up to 64 CPUs. We can submit the changes so they can
> eventually be merged with the GnuPG main distribution if there's
> interest in them.
> Before we can recommend the project, I wanted to get some feedback on
> the plausibility and feasibility of the project. How difficult would it
> be to implement the changes? And is there need for a parallel GnuPG?
The main problem that jumps to mind is that (speaking about the 1.4
branch of GnuPG for the moment), GnuPG is an OpenPGP program. The
OpenPGP standard only specifies a variant of CFB mode, which is
obviously not easy to parallelize. Changing the cipher mode (even as
an option) would make GnuPG not compatible with OpenPGP any longer
when that mode is used.
There are some things that can be parallelized, such as encrypting and
hashing at the same time for a signed+encrypted message, but this may
not be what you're looking for.
More information about the Gnupg-devel