Skip to main content
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link

Yes, it should be possible to decipher a chunk of a large RFC 4880 / OpenPGPRFC 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.1RFC 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 4section 4 for the general format of packets, section 4.3section 4.3 for the various kinds, and section 5section 5 for details. "Blocks" in the sense I use live in a Symmetrically Encrypted Data PacketSymmetrically Encrypted Data Packet.

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.

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.

Fix the alignment rule.
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611

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) skipseek to an integer multiple ofappropriate location considering 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 (withwith a slight modification at the beginning which does not matter there). Just, 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.

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) 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 (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; 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.

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.

Polish
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611

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) 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 (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; 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.

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) 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 (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, "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.

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) 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 (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; 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.

Add final note
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611
Loading
mention the possibility of re-encryption
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611
Loading
Polish
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611
Loading
Source Link
fgrieu
  • 145.7k
  • 12
  • 319
  • 611
Loading