Parallel Encryption Revisited

[Yushu Yao]

On Fri, Feb 3, 2012 at 1:22 PM, Yushu Yao <yao.yushu at gmail.com> wrote:

> Hi Experts,
>
> 5 years ago there was a post asking about parallel encrypting and got
> blasted with a series of concerns:
> http://lists.gnupg.org/pipermail/gnupg-devel/2007-February/023654.html
>
> Now, for both data exchange and backup purposes, many people are trying to
> encrypt Terabytes of data (1 big file), on a parallel file system. Clearly
> the 1 thread/process sequential encryption is not optimal, and paralleling
> can save a lot of time!
>
> I have very limited knowledge of Cryptography, my question is: from what I
> observe, "gpg -e" reads in a file, massages it a bit with the public key,
> and output another file. What is the reason why it can't split the input
> file to 5 pieces, let 5 processes massage each piece with the same pub key,
> and then concatenate the outputs to one big output?
> (I guess the question is whether gpg is doing an "all to all" correlation
> on the input file?).
>
> If above can't be done, maybe people can split the file 1st then encrypt.
>
Just to add that in this case it's very hard to use because I'll need to
reconstruct the file 1st before I can look into file. E.g. when I have a
tar file that's encrypted, I can simply do " pgp -d myfile.tar.pgp | tar
tzvf"; If I split it first then do gpg, I'll need to re create the whole
tar file on disk, then do tar tzvf. Which needs time and space.


>
> Thanks
>
> -Yushu
>
>
> +-------------------------------------------------+
> | Yushu Yao
> | Ph:1-510-486-4690
> |
> | Lawrence Berkeley National Lab
> | Mailstop 50B-6222
> | 1 Cyclotron Road
> | Berkeley CA 94720-8147 - USA
> +-------------------------------------------------+
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120203/264c18a4/attachment.htm>