**Yes**, it should be possible to decipher a chunk of a large [RFC 4880 / OpenPGP][1] 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][2]), 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) skip an integer multiple of the block size (8 octets for 3DES, 16 octets for AES), starting reading and decryption where that's necessary. This must account that OpenPGP uses a block cipher in [CFB mode][3] (with a slight modification at the beginning which does not matter there). Just 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][4]; 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][5] for the general format of packets, [section 4.3][6] for the various kinds, and [section 5][7] for details. "Blocks" in the sense I use live in a [_Symmetrically Encrypted Data Packet_][8].


  [1]: https://tools.ietf.org/html/rfc4880
  [2]: https://tools.ietf.org/html/rfc4880#section-13.3.1
  [3]: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Feedback_.28CFB.29
  [4]: https://en.wikipedia.org/wiki/Block_cipher
  [5]: https://tools.ietf.org/html/rfc4880#section-4
  [6]: https://tools.ietf.org/html/rfc4880#section-4.3
  [7]: https://tools.ietf.org/html/rfc4880#section-5
  [8]: https://tools.ietf.org/html/rfc4880#section-5.7