> Von: Werner Koch [mailto:w...@gnupg.org] > > On Tue, 4 Sep 2018 10:08, roman.fied...@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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
