-----BEGIN PGP SIGNED MESSAGE-----
No, the cause is completely different. The unencrypted actual MPI
determines the bit length and should not include any leading zeroes,
but encryption might introduce them (and it's probably not wise to
adjust the bit length accordingly).
This sounds like a bug I found in the OpenPGP engine inside Mixmaster
2.9beta23... it (wrongly) treats the encrypted data as an MPI and
puts out the wrong bit count. (Note that the "encrypted MPI" could
have a bit count that's a whole byte or more shorter. The bit
counting in Mix2.9b23 serendipitously avoids an accident here.)
This resulted in other PGP versions reporting checksum errors
(because they did not adjust the bit count after decrypting).
All that said, this is an implementation bug, not a spec issue.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
-----END PGP SIGNATURE-----