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

[Peter Lebbing]

On 05/09/18 16:29, Fiedler Roman wrote:
> Apart from that, is not the
> 
> [GNUPG:] VALIDSIG 25CE8B1D52A5B231543F8D660EE7BE094144A67F 2018-09-05 
> 1536157493 0 4 0 1 8 00 25CE8B1D52A5B231543F8D660EE7BE094144A67F
> 
> more suited for checking?

Generally: no. It just indicates the signature is cryptographically
valid, it does not indicate whether the *key* is valid. With
--trust-model always and a non-revoked key; perhaps.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Fiedler Roman]

> Von: Peter Lebbing [mailto:pe...@digitalbrains.com]
>
> On 05/09/18 10:45, Fiedler Roman wrote:
> > * Decrypt and verify with gpg1 on receiver side:
> >
> > /usr/bin/gpg1 --no-options --homedir Receiver --no-default-keyring --
> keyring Sender/SenderKey.pub --lock-never --trust-model always --batch --
> display-charset utf-8 --status-fd 2 --decrypt --try-all-secrets <
> Sender/OutgoingMessage.gpg
>
> If you want to know which of the public keys you have signed a
> particular message, instead of restricting your "keyring" to a single,
> desired key, you can scan the status-fd for
>
> [GNUPG:] GOODSIG

That would be the preferred way if each recipient has and is allowed
to have a list of public keys. As in my usecase the keys are stored in
a database and only the relevant key is handed out by a service, used
for the operation and then thrown away again. In a perfect world it
should never touch non-volatile storage during that process.

Not relying on a local keyring to be filled should also allow central
sanitation/quality assurance of encoded public key material, thus
avoiding security issues on status-fd protocol with key fields similar
to filename related problems in gnupg (see CVE-2018-12020)

Apart from that, is not the

[GNUPG:] VALIDSIG 25CE8B1D52A5B231543F8D660EE7BE094144A67F 2018-09-05 
1536157493 0 4 0 1 8 00 25CE8B1D52A5B231543F8D660EE7BE094144A67F

more suited for checking? The 64-bit key-IDs should be close to
bruteforcing, thus not really reliable for key identification?

> In this case, just keep your keyring as it normally is, containing all
> public keys. You might then also reach a situation where you can
> meaningfully use a trust model, instead of your --trust-model always.
>
> status-fd is documented in doc/DETAILS.

The "--status-fd" is really great for that to pin keys in a classical setup,
where I have such filter lists already in operation.

Regards,
Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Werner Koch]

On Tue,  4 Sep 2018 18:31, roman.fied...@ait.ac.at said:

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

That is an encrypted message and thus can you seen the the signature. 

>> 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

Nope.  Public keys, which are required to check a signature, are, as the
name says, public and availabale from several sources, for example the
key servers.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpLF3ytSPmeY.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Fiedler Roman]

> 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 AA[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

01-001.pk_enc
02-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:

: 8502 0e03     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

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

[Werner Koch]

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.

How did you create the keyfile and the signature?

> 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.  Leaving this out would not help because it is easy to
figure out the key by trial verification against all known keys.  And
traffic analysis can be done without crypto operations.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpMT7zdIS9uc.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

[Fiedler Roman]

> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Mon,  3 Sep 2018 19:25, pe...@digitalbrains.com said:
>
> > It could be that recently an option was added to check a signature by a
> > certificate in a file, but in general you need to import a certificate
>
> No, that is nlot the case.  We only added the option -f to encrypt to a
> key taken from a file.
>
> For verification against a single key or a set of keys use the gpgv
> tool:
>
>gpgv --keyring FILEWITHKEYS FILETOCHECK [DATAFILE]

Thanks for your helpful reply, that seems to be exactly the command
I should use. But it seems it is suffering from the same "[GNUPG:] UNEXPECTED 0"
issue.

/usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring 
key.pub data.gpg
[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error

Could it be, that "--throw-keyids" at signature creation to then avoid
XKeyscore-traffic-analysis [1] is not compatible with signature verification? I
would have expected to work exactly the same way as with "--decrypt":
without a key-ID all keys are tested.

Regards, Roman

[1] https://motherboard.vice.com/en_us/article/ezpxan/pssst-your-pgp-is-leaking
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users