gpg --symmetric emits a SEIP packet, but no MDC
Closed, InvalidPublic

Description

% echo huhu > huhu
% gpg --symmetric -o huhu.gpg huhu
% sq decrypt --dump huhu.gpg
Symmetric-key Encrypted Session Key Packet
  Version: 4
  Cipher: AES with 256-bit key
  S2K: Iterated
    Hash: SHA1
    Salt: 337327578C0BB913
    Iterations: 65011712

Encrypted and Integrity Protected Data Packet
  Version: 1

Enter password to decrypt message: 
    Compressed Data Packet
      Algorithm: ZIP

        Literal Data Packet
          Format: Binary data
          Filename: huhu
          Timestamp: 2018-08-31T09:35

huhu
Malformed OpenPGP message

Note the missing MDC packet at the end. RFC4880 says:

The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet [...]

Details

Version
2.2.9
justus created this task.Aug 31 2018, 11:45 AM
gniibe claimed this task.EditedSep 4 2018, 7:35 AM
gniibe added a subscriber: gniibe.

I can see MDC packet of 22-byte (which starts by 0xd3 0x14, and then 20-byte SHA-1 hash), when SEIP data packet is decrypted.
I don't see your situation.
How about with no compression (-z 0)? I mean, compression is not applied to MDC packet.

gniibe added a comment.Sep 5 2018, 3:55 AM

Here is my understanding.

I made huhu.gpg by "passphrase-no-1".

============================ huhu.gpg
8c 0d 04 09 03 02 ef 6c 96 89 50 b0 cc 77 e7 d2 
3b 01 ad 06 3e 19 8c 45 66 f6 65 fe da 61 c3 63
ab 6a 98 c1 3f 6d 5c 09 d7 7a b5 13 7c 1b fb c6
c3 b9 be 13 12 d1 06 34 43 05 fa ab e3 15 c2 16
cb bd 7c 4d 7d 8c 5f 15 3e f9 c1 0a
============================

...which is (explained by pgpdump output):

============================
  8c 0d
     04 09 03 02 ef 6c 96 89 50 b0 cc 77 e7

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
	New version(4)
	Sym alg - AES with 256-bit key(sym 9)
	Iterated and salted string-to-key(s2k 3):
		Hash alg - SHA1(hash 2)
		Salt - ef 6c 96 89 50 b0 cc 77 
		Count - 24117248(coded count 231)

  d2 3b
      01
      ad 06 3e 19 8c 45 66 f6 65 fe da 61 c3 63 ab 6a
      98 c1 3f 6d 5c 09 d7 7a b5 13 7c 1b fb c6 c3 b9
      be 13 12 d1 06 34 43 05 fa ab e3 15 c2 16 cb bd
      7c 4d 7d 8c 5f 15 3e f9 c1 0a

New: Symmetrically Encrypted and MDC Packet(tag 18)(59 bytes)
	Ver 1
	Encrypted data [sym alg is specified in sym-key encrypted session key]
		(plain text + MDC SHA1(20 bytes))
============================

When SEIP data packet of length is decrypted, we have
following octets:

============================ Prefix (instead of IV) 16+2
cf c1 9e d3 96 05 a8 50 bc 38 e2 fc 45 fb f9 38
f9 38
============================ Compressed data packet
a3 01 5b c3 9f c4 92 51 9a 51 1a dd af 28 02 a2
b9 00
============================ MDC packet
d3 14 f2 e4 0b f5 80 e2 e2 62 25 e9 47 7f 71 6c
09 57 e7 52 2f 78
============================

Here we have MDC packet. ---^

And then, the compressed data packet will be uncompressed into:

============================ Literal data packet
ac 0f 62 04 68 75 68 75 5b 8f 21 14 68 75 68 75
0a
============================
gniibe added a comment.EditedSep 5 2018, 3:58 AM

Perhaps, the missing length information in compressed data packet is confusing. The length can be determined by the assumption of existence of 22-byte MDC packet.

werner closed this task as Invalid.Sep 5 2018, 12:40 PM
werner added a subscriber: werner.

Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.

justus added a comment.Sep 5 2018, 1:51 PM

Thanks for the clarification.