AW: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled"

[Fiedler Roman]

> Von: Werner Koch [mailto:wk at gnupg.org]
>
> On Tue,  4 Sep 2018 10:08, Roman.Fiedler at ait.ac.at said:
>
> > [GNUPG:] UNEXPECTED 0
>
> The signature is corrupted in that it has a packet which is expected
> only in a key.  Or the provided key has a data signature packet etc.

I hope not :-) If any of those assumptions above is true, then the current
gpg behaviour might be a massive security problem as gpg1 can be tricked
into verifying a signature, that should not be there.

This command decrypts the data and claims to see a valid signature (both commands get input to decrypt from stdin):

/usr/bin/gpg1 --no-options --homedir decrypt-key --no-default-keyring --keyring sign.pub --lock-never --trust-model always --batch --display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets

"[GNUPG:] GOODSIG AAAAAA....[keyid] "

While gpgv (from gpg2 package) does not:

/usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring sign.pub /proc/self/fd/0

"[GNUPG:] UNEXPECTED 0"


Remember, that similar gpg2 call also returned the same error, so I changed
it to use "gpgv" according to your recommendation (see mail list archive).
But that did not help getting rid of the error.

> How did you create the keyfile and the signature?

Keyfile: gpg2 --no-options --homedir [home] --lock-never --trust-model always --export [identifier]

Signature: gpg1 --no-options --homedir [somedir] --keyring [remote.pub] --lock-never --trust-model always --sign --local-user [user-id] --encrypt --throw-keyids --hidden-recipient


> > Could it be, that "--throw-keyids" at signature creation to then avoid
> > XKeyscore-traffic-analysis [1] is not compatible with signature
> > verification?
>
> No.  The keyid (or the fingerprint in newer version) is mandatory for a
> signature packet.

OK, I have to check that. I assumed "--throw-keyids" would put me on the
safe side... Splitting up the message gives me

000001-001.pk_enc
000002-018.encrypted_mdc

Which of the files contains the problematic signature key ID? At least the
encryption key hing in pk.enc is zeroed out, as expected:

00000000: 8502 0e03 0000 0000 0000 0000 1008 00a9  ................

At which byte offset should I find the signer key fingerprint?

> Leaving this out would not help because it is easy to
> figure out the key by trial verification against all known keys.

Well, that would be all keys in the 2^2048 key space, so the problem
should be as hard to solve as factorization itself. As keys are never
transmitted unencrypted, the attacker has no chance to know a single
one.

>  And traffic analysis can be done without crypto operations.

But it is much more convenient:

* key IDs included: get unique number of recipients at each endpoint,
  detect each new recipient as soon as it is addressed for the first time ...

* key IDs missing: get frequency/size of cryptograms (size is always the
  same) and try to estimate the number of distinct recipients.