GnuPG (good) and PGP (bad) encryption
Falissard
Here is one case where PGP is not as clever as GnuPG...
The following conventionally encrypted data
decrypts well with GnuPG, ** not ** with PGP ("bad packet").
The passphrase is "test".
Nothing special here regarding algorithms (Cast5 + MD5).
The thing that I suspect is that PGP does not always
accept packets with indeterminate length, while
it's OK for GnuPG.
(I deliberately encrypted a compressed
packet with indeterminate length.)
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.0.6 (MingW32)
Comment: For info see http://www.gnupg.org
wwQEAwAByf8AAAAyEXrKTVH2DEz0lKVsP6ZpFJySpLkH+ha6WY3EXlj7Phjgdm0c
cRg0WUWFpllUCMJqzPk=
=hHJq
-----END PGP MESSAGE-----
Imad R. Faiad
Hash: RIPEMD160
Greetings,
That's very intersting, indeed.
Thanks,
Best Regards,
Imad R. Faiad
-----BEGIN PGP SIGNATURE-----
iQEVAwUBPoijDbzDFxiDPxutAQOcqQgAh9oWL/eeygYUx5+o4ZqUIyZZrrUyYQIa
tR7tnroqybBDI0Sh9bG+24vNV2LXhAXS0AxYlvwROWE64D1K1wxYon/b3Y8CrPqB
98rzDFGg7QNETIfFbk9P9KSenkuSN0SpE+7k2HF8zEZXaq1JcIusOI8gHJNHWZkd
mbXnq1IkH7KuzJnj+AVeoBYmYTFvmp8+mrgNTeGXw4WumL0EpbZHiXiS5NnMUpNt
UeL3o0Tvl6cpcZ00HdPnTYwF+OvtADbbgV5Yo5RvLa16J8wm5WMAO5ZyQgsU6HI1
dDS3W93SPCNkQhmufMQp13pwjSlx9bBdC5W9sHEXlYIAwmyftNE5Mw==
=6wla
-----END PGP SIGNATURE-----
Robert J. Hansen
Which version of PGP? Keep in mind that even up until 6.5.x, PGP was
only mostly-compatible with RFC2440. 7.x increased conformance more,
but it still craps out on things like comment packets in keys (when I
was transferring keys between a GnuPG install and a 7.1.1 install, I
had to "--no-comment" the exported keys).
If we're getting interoperability problems between GnuPG and PGP 8,
that's a lot more significant than if this is a problem between GnuPG
and PGP 6.5.8.
vedaal
Hash: RIPEMD160
"Falissard" <th.fal...@etic.fr> wrote in message
news:3e88b221$0$1635$79c1...@nan-newsreader-03.noos.net...
...
> The following conventionally encrypted data
> decrypts well with GnuPG, ** not ** with PGP ("bad packet").
> The passphrase is "test".
> Nothing special here regarding algorithms (Cast5 + MD5).
> The thing that I suspect is that PGP does not always
> accept packets with indeterminate length, while
> it's OK for GnuPG.
> (I deliberately encrypted a compressed
> packet with indeterminate length.)
...
does this also happen with encryption to a key?
tia,
vedaal
-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA
iQEVAwUBPom6z2oFoLeFMG0lAQP+PQf+PR/XOtrYtGFjFhJYAoZatA5Y+fuBHx69
ZefTBFigZFbk0NaIszcr4NLeaePWhzUMqbVvmmUBTGzowwgTQVk3w4LA7TuxZGMd
hXhFwzCrahkQHpnU2ED77kEjPf0uKapmXQiEhYDZWxkAK3VRJctsxahffjCJRt9j
RnIOs2E23IRDXX96cEe21J4qpTx9NywjjhenvxNHv/3YGbJJHSkhqbr5MYDP+bSG
1GJc1eAXBd1gOzrbhIZudLbCfuRQkWH7YsEpO4F+ATc9TmaDHmVKKxBYiQDYMQtc
TQjIDv7pEb0ANhjcnOn/NszcbRR/84ZcLDut5WcyiIFWmk9h5mNz0Q==
=8G7m
-----END PGP SIGNATURE-----
Falissard
> does this also happen with encryption to a key?
>
Chris Applegate
Hash: SHA1
Tom McCune wrote:
> I had the stated result with PGP 8.0. Maybe tonight, I can try
> with the newly released 8.02.
8.02 gives me an "error decompressing data."
CDA
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2
iQA/AwUBPoniN1QICXvbwNhREQL5awCguLIvzrP6kQgFamZ8O2QD23f7rSsAn39+
eRyP9OPedFAcxZmI81SkcEpq
=BEu4
-----END PGP SIGNATURE-----
Michael Young
Hash: SHA1
>The following conventionally encrypted data
> > decrypts well with GnuPG, ** not ** with PGP ("bad packet").
Note that the compression algorithm in the example is 2 (zlib) rather
than 1 (zip). I suspect that this is the issue, not the indeterminate length.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBPooPy+c3iHYL8FknEQI/2QCcCtkwFDNMkX5OMFmz2/OsK9BbC3YAoLxd
qPhRf/HdtG9SNvvucaNOMCtf
=QWOA
-----END PGP SIGNATURE-----
Falissard
> Note that the compression algorithm in the example is 2 (zlib) rather
> than 1 (zip). I suspect that this is the issue, not the indeterminate
length.
You may be right. I realize now that GnuPG encrypted files
(with compression algorithm = 2) cannot be decrypted
by the v7.0.3 PGP that I use, nor by PGP command line v 6.5.8 !
Talk about compatibility...
Robert J. Hansen
This isn't actually PGP's fault, nor GnuPG's. RFC-conformant
implementations MUST support uncompressed data, SHOULD support
ZIP-compressed data and MAY support ZLIB-compressed data.
As it turns out, PGP doesn't support ZLIB, and GnuPG does. Neither
one of them is right or wrong. Compatability between the two is
unaffected: just use the --pgp6 switch with GnuPG, or --openpgp.
IMO, while this isn't anyone's fault, it does cast a little doubt onto
how well GnuPG follows the Postel Principle ("be liberal in what you
accept, be conservative in what you generate"). But that's for
another day. :)
Falissard
> > Talk about compatibility...
>
> As it turns out, PGP doesn't support ZLIB, and GnuPG does. Neither
> one of them is right or wrong. Compatability between the two is
> unaffected: just use the --pgp6 switch with GnuPG, or --openpgp.
>
An error in the encrypted flow cannot get unnoticed.
David Shaw
Not at all. GnuPG never uses ZLIB unless generating a message for another
GnuPG user, or if the user forces its use on the command line (and ignores
the warning message). If a user is bound and determined to shoot
themselves in the foot, there isn't much GnuPG can do about it.
David
Malte Gell
You made your example with conventionally encrypted data which was
compressed using ZLIB, but does this issue also affect standard public
key encryption ?
I can't imagine, that such a thing would go unnoticed ? So, does it only
affect symmetric encryption ?
Tux
Falissard wrote:
Hmm:
My output using gpg 1.2.1 on Linux (Mandrake 9.1)
[ron@Router ron]$ gpg test.pgp
gpg: CAST5 encrypted data
gpg: WARNING: message was not integrity protected
[ron@Router ron]$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iQEVAwUBPoz25kpQ41XL9/JxAQGaPgf7BYuIajkzjeo7FrYrNnS0unL2YKeaucJJ
SCRophDcC0QrdQbePvZ7xtea1H5YIKkq9N7EgcJLl8LZdMnkWTC6Pd86KDIiizbu
BHvjXzbC6h6DRQQkQ6/WpND9uzc6FjrafYEfD5UmjYvXpMTla2OdyPA9SeTTTe0W
GZKb9LmmWcvVBVlwt83xJ2JwEgZv5lAcNGOzOlL6r+EBXOkSKZPin8NdrE4NPj5a
h70RRI8OBjW52s+VcG9Msd6T47RaSJ06IRWwH1mUFsJM8Y9jP3yogQVWeOGRUU+2
iESqrJ5I8dvKedMb1VUmOffS+gKEb+DTQyydVXIRhhCGIycqQSo1yw==
=uDfu
-----END PGP SIGNATURE-----
Robert J. Hansen
> compressed using ZLIB, but does this issue also affect standard public
> key encryption ?
Public-key crypto, as used in OpenPGP, incorporates symmetric crypto
into the overall design. So yes, it would be affected; but no, this
isn't a problem. GnuPG doesn't compress with ZLIB by default; and
this problem only exists when a message is compressed with ZLIB and
the receiving client doesn't support ZLIB.
Marc A. Donges
> You made your example with conventionally encrypted data which was
> compressed using ZLIB, but does this issue also affect standard public
> key encryption ?
In public key encryption, gpg uses the preferences specified in the
public key. If those are absent, a default set of preferences *not*
containing zlib is assumed. Therefore, specifying whether he can decode
zlib is the choice of the recipient.
Marc
--
_ _ Marc A. Donges +49 721 6904-2130
'v' Klosterweg 28 / E110
/ \ 76131 Karlsruhe PGP-Key(RSA): 1024R/429D9719
W W http://www.hadiko.de/~marc/marc.asc
Imad R. Faiad
Greetings,
Having looked at the recently released PGP 8.0.2, it looks like
PGP is more zlib aware now, albeit it does not yet handle the
compression/decompression.
I would speculate and say zlib might probably be supported
in PGP 8.0.2+??
Best Regards
Imad R. Faiad
-----BEGIN PGP SIGNATURE-----
iQEVAwUBPo4D8rzDFxiDPxutAQFeZwf/UCDTJjFckMul+emQ8E6oxW3AC3KtyDym
HwFe7YvHJTckRM1rOEvpLyQRfMDADwDkwy0Up4IOt72ToxVk1DHbc91RSiCeM9XI
Y82553x4mCehMVtk/kBsZPDphm6Lh3cIXa8wIrAHuZCTcc79QxzExQVj1smUeSIX
hLJpcGE8UcoepUpYEuFf3U+dANFJatAE5Q5VlT6bJMK7GMnYfXE9lDMbYKCpk7CP
+6YklHCwsgzOjeaaEqxCi1HpFbQ5H+zu76vane7dAKTmaBNFO5oQXdIlvrKvYXlv
41d42oiB9i5/KSfYjGuSusjB60Rln/aM+Pu3a0wljysPKbke2a4ofQ==
=UGTX
-----END PGP SIGNATURE-----
Imad R. Faiad
Greetings,
You are right, I second your opinion.
Best Regards
Imad R. Faiad
-----BEGIN PGP SIGNATURE-----
iQEVAwUBPo4I0LzDFxiDPxutAQEGpwf+OIWgumNN2YiGdP34v+gf5uL4X6ZPGipS
mlbTSS5U900ma1+JM/AoCmquGFV+ENcS06U1xVxHFXp26ry4wGXRRO86NTy4UlPI
c2ePKNdJvs3pgcEt97+wjqr+XBppI322vu2+EElXRKQ99kzlb2Xta5zwwhm85P22
reioV3mbcXb1Rt3+bqYCrWGLrkh53WTH1v2Libc+zPyxMno6eA4XkJIZTYgZqLA9
DLI45/OYOnVcyxzBAAn8a4G7ZacdpKMJ+qUs7grrNd8YCnwrkznJYyBH0qw4Mesr
kfS1Q0uPrDN78AM3F7U4I8URCMnDwb1D2K4qQvIE4FhHIGNuiGfJdw==
=8EAT
-----END PGP SIGNATURE-----