Possible bug in gpg?

[Brad Tilley]

>> Hi,
>> I have a symmetrically encrypted pgp file here:
>> http://16s.us/word_machine/downloads/pgp-easy.tgz.pgp
>> gpg will accept the three characters !=X as the password and exit with
a return status of 0 (although it does not actually decrypt the file):
>> $ gpg -d pgp-easy.tgz.pgp gpg: CAST5 encrypted data gpg: encrypted with
1 passphrase gpg: WARNING: message was not integrity
>> protected
>
> Yep, I got essentially the same thing:
>
> bash-3.2$ gpg -vvv pgp-easy.tgz.pgp
> gpg: using character set `utf-8'
> :symkey enc packet: version 4, cipher 3, s2k 3, hash 2
> 	salt 8dd17929c3935452, count 65536 (96)
> gpg: CAST5 encrypted data
> :encrypted data packet:
> 	length: unknown
> gpg: encrypted with 1 passphrase
> gpg: decryption okay
> gpg: WARNING: message was not integrity protected
> bash-3.2$ pgpdump pgp-easy.tgz.pgp
> Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
> 	New version(4)
> 	Sym alg - CAST5(sym 3)
> 	Iterated and salted string-to-key(s2k 3):
> 		Hash alg - SHA1(hash 2)
> 		Salt - 8d d1 79 29 c3 93 54 52
> 		Count - 65536(coded count 96)
> New: Symmetrically Encrypted Data Packet(tag 9)(512 bytes) partial start
> 	Encrypted data [sym alg is specified in sym-key encrypted session key]
> New: 	(13 bytes) partial end
> bash-3.2$
>
>> !=X is not the plaintext password that was used to encrypt the
>> file. I was hoping someone on the list might be able to help me
understand why this might happen. Could it be a bug in gpg, or
>> OpenPGP itself? Here is my gpg version:
>
> I symmetrically encrypted another file with CAST5 (same version of GPG
as you) and tried the same trick.  The !=X string did not produce the
the same message.  Instead I received the expected "decryption failed:
bad key" message.
>
>> I don't yet know the actual plaintext password or the exact
>> commands/program used to encrypt the file, but I should know in a few
days. This is a file that's apart of the defcon password
>> cracking contest and I came across this and wanted to mention it here.
>
> Ah.  I suspect that it will either be something weird to do with
whatever software was used to encrypt the file or someone has found a
way to be sneaky with it.  Either way, when all is revealed please post
a follow-up.
>
>> I'm not subscribed to this list, so please cc me if you want to reach me.
>
> Sure.  There has only been one other response which it does not appear
was CC'd to you, but it didn't shed any light either.
>
> Maybe someone else here will have some insight.
>
>
> Regards,
> Ben

---

Thanks for the reply Ben, I've encountered several other plaintext strings
that cause the same behavior. Here's another one:

K02&10&![

It seems to work (gpg -d accepts the string and exits with status 0) but
again the data are not decrypted. Someone cracked this, so we should know
what the actual plaintext is soon.

Thanks again,

Brad