in reply to GPG signing Issue

I am having slightly different problems with Crypt::OpenPGP. Can't get it to read my GPGv1 private key from the keyring. It dies with:

encrypt: datasize not multiple of blocksize (16 bytes) at /usr/local/s +hare/perl5/Crypt/OpenPGP/CFB.pm line 57.

which Carp::Always tells me is called from Crypt::OpenPGP::Cipher::decrypt on a Crypt::OpenPGP::Cipher::Rijndael object. How are you reading/creating your key in the code in the OP?

It's a shame because it could be a really good alternative to either GPGme or the CLI wrappers.

Replies are listed 'Best First'.
Re^2: GPG signing Issue
by hippo (Archbishop) on Jan 29, 2019 at 15:23 UTC

    Revisiting this I am no further on and would appreciate any pointers. Here's a trivial test:

    use strict; use warnings; use Test::More tests => 1; use Crypt::OpenPGP; my $message = "Hello world!\n"; my $pgp = Crypt::OpenPGP->new (); my $sig = $pgp->sign ( Data => $message, Clearsign => 1, KeyID => $ENV{GPG_SECRET_KEY}, Passphrase => $ENV{GPG_PP} ); ok ($sig) or diag ($pgp->errstr);

    With a valid secret key ID (in the form "ABCD1234") it bombs out as follows:

    $ perl openpgp_sample.t 1..1 encrypt: datasize not multiple of blocksize (16 bytes) at /usr/local/s +hare/perl5/Crypt/OpenPGP/CFB.pm line 57. # Looks like your test exited with 2 before it could output anything.

    The keypair was created with gpg --gen-key for testing and is perfectly usable for signing via the gpg binary. What am I missing?

    Some version info:

    • perl: 5.20.3
    • Crypt::OpenPGP: 1.12
    • Crypt::Rijndael: 1.13
    • gpg: 1.4.20

      I cannot replicate, using two similar (but not identical) setups. First is my windows machine, second is a virtual linux machine; both used perl v5.20.3, but have wildly different gpg versions. Both worked just fine (though I learned that virtual machines do not like building entropy; it took forever to generate my dummy key or to sign the message).

      ... So no, I don't know what's going wrong with yours... I don't know whether it will help to know it does work on similar-but-not-identical situations. My best bet would be some bug in the interface with your specific version of gpg... Oh, are you using 32b or 64b perl? And is the gpg 32b or 64b? Maybe data is trying to cross a bitness boundary?


      update: oh, right, I think it's just Windows that has mixed bitness. I confirmed my linux virtual box was 32bit. And on Windows, it was 64bit perl as shown, with 32bit gpg.exe, so at least in that direction, it was okay to be mixed; I also tried with a 32bit v5.26.1 on windows, with the same results.

        Thanks, pryrt. It does indeed help to know that a similar setup has been shown to work in that I know it isn't a complete non-starter. Both the perl and gpg binaries are 64bit and I'm using Linux on a physical host (although if I can get this working it will go on VMs in production).

        Will keep plugging away at it and report back if I get anywhere.

        Update: It appears to be dependent on the key size. A valid signature is produced from a 1024 bit key but not a 4096 bit key (which I tend to use by default these days).

        Update 2: It's more complicated than that. It only works with some 1024 bit keys. I'm beginning to think that maybe this module isn't suitable for production environments after all. :-/