Is it possible to decrypt only a portion of a gpg encrypted file?

Question

I have very large encrypted files that I need to process in a highly parallel fashion (the files are composed of distinct records of data). Currently, the process begins by first decrypting the data, then starting the parallel work with each worker seeking to it's assigned file offset. I already have a way of aligning to record boundaries, so don't worry about that.

My (limited) understanding of GnuPG encrypted files is that the data is encrypted using a symmetric algorithm and then the key is encrypted with the public key of the recipient. Since I am the recipient, I understand that my public key can list algorithms I support.

Can I make use of this so that when the file is encrypted, I will be able to interpret it in a chunk-like fashion? For example, I could piece together a valid decrypt-able chunk by reading a certain number of bytes preamble of the file and then seeking to a calculable valid offset and continuing my reading and ending at a calculable valid offset?

Thanks!

Answer 1

Yes, it should be possible to decipher a chunk of a large RFC 4880 / OpenPGP file (without deciphering the bulk of what's before), assuming the (private or symmetric) key necessary for sequential deciphering is available, and the entity that prepared the enciphered file did so without using the file format's compression feature (even though using it is the default and most common). There is an attribute in the public key format allowing the recipient to require that compression is not used (see RFC 4880 section 13.3.1), thus what's asked should be possible.

However

• The integrity of the separately deciphered chunk can not be ascertained; it seems that as a bare minimum, the file should be integrity-checked once (e.g. the signature by the alleged sender verified) before starting to decipher it as chunks.
• There is a risk that some untested implementation (or one predating the OpenPGP spec) does not honor the "don't compress" flag correctly (that is, compress even though one of the intended recipients forbids). An option in this case would be to sequentially decipher then re-encipher the file without compression for future direct access.
• Usual libraries implementing OpenPGP decryption are not designed with direct access in mind, and will need to be modified, as follows.

The general idea would be to process the beginning of the file as usual, up to the point where the symmetric key and algorithm used for encryption of the bulk of the data is known; then (when the chunk to decipher is not near the beginning of the file) seek to an appropriate location considering the block size (8 octets for 3DES, 16 octets for AES). OpenPGP uses a block cipher in CFB mode with a slight modification at the beginning, thus we must skip two octets and an appropriate multiple of the block size, then decipher as in normal CFB, using as IV the ciphertext block immediately before the ciphertext block containing the first octet of the chunk to be deciphered.

Note: In the above, "chunk" is used as in the question, for some large portion of the useful data in the file. And "block" designates the amount of data at the input and output of a block cipher; that's 16 octets (128 bits) for all variants of AES. RFC 4880 also uses "block" for that meaning, and occasionally others (e.g. in "block of text"). RFC 4880 consistently uses "packet" to designates a section of the file with a certain format; see section 4 for the general format of packets, section 4.3 for the various kinds, and section 5 for details. "Blocks" in the sense I use live in a Symmetrically Encrypted Data Packet.