Mailing List Archive

Hello List,

Just for the records: a gnupg2 "ERROR key_generate 33554531" is fixed by sending " %no-protection" via the command-fd. It seems that a password-less key was generated with gpg1 just by not setting a password. With gnupg2 this command is needed.

@Devs: It would be really nice to issue a message like "Refusing to create unprotected key, use %no-protection if you know what you are doing". Would have helped saving quite some time.


Just to continue the gpg1 -> gpg2 migration error message guessing game: what might be the issue with this command?

/usr/bin/gpg --no-options --batch --no-default-keyring --homedir [some-home] --keyring key.pub --lock-never --trust-model always --status-fd 2 --verify 4b7b830243078d63.gpg
[GNUPG:] UNEXPECTED 0
gpg: verify signatures failed: Unexpected error
[GNUPG:] FAILURE verify 38

With gpg1 a similar command should have verified, that the signature is exactly from the single public key stored in "key.pub".

Best regards,
Roman

> Von: Gnupg-users [mailto:gnupg-users-bounces@gnupg.org] Im Auftrag von
>
> Hello list,
>
> I am attempting to upgrade software to use gpg2 instead of gpg. After fixing
> the usual "Inappropriate ioctl for device" and "Sorry, we are in batchmode -
> can't get input" messages and applying all the gpg_agent security
> workarounds, I am now stuck at this sequence:
>
> The key generation command
>
> [.'/usr/bin/gpg', '--homedir', '/tmp/tmp-3abk6l8', '--with-colons', '--status-fd',
> '2', '--pinentry-mode', 'loopback', '--batch', '--gen-key', '--command-fd', '0']
>
> with the security-sensitive passphrase-input via the command-fd
>
> b'%echo Generating key\nKey-Type: RSA\nKey-Length: 1024\nSubkey-Type:
> ELG-E\nSubkey-Length: 1024\nName-Real: AutomationKey\nExpire-Date:
> 0\n%commit\n',
>
> will generate following output:
>
> gpg: keybox '/tmp/tmp-3abk6l8/pubring.kbx' created
> gpg: Generating key
> [GNUPG:] INQUIRE_MAXLEN 100
> [GNUPG:] GET_HIDDEN passphrase.enter
> [GNUPG:] GOT_IT
> gpg: agent_genkey failed: Operation cancelled
> gpg: key generation failed: Operation cancelled
> [GNUPG:] ERROR key_generate 33554531
> [GNUPG:] KEY_NOT_CREATED
>
> It seems that agent and gpg are going through some "brain-split" episode as
> the errors seem to indicate, that everyone is thinking the other party
> canceled the transfer. The strace indicates, that gnupg itself sends the
> "cancel" request to the agent and is astonished by the result - it cannot even
> give a meaningful error message about the current condition. As there is no
> other syscall activity, all the reasons for have to be in gpg2.
>
> 2138 write(2, "[GNUPG:] INQUIRE_MAXLEN 100", 27) = 27
> 2138 write(2, "\n", 1) = 1
> 2138 write(2, "[GNUPG:] GET_HIDDEN passphrase.enter", 36) = 36
> 2138 write(2, "\n", 1) = 1
> 2138 read(0, "", 1) = 0
> 2138 write(2, "[GNUPG:] GOT_IT", 15) = 15 --- not knowing what gnupg
> successfully got here as there is no passphrase to read
> 2138 write(2, "\n", 1) = 1
> 2138 write(3, "CAN", 3) = 3 --- Gnupg sending cancel
> 2138 write(3, "\n", 1) = 1
> 2138 read(3, <unfinished ...>
> 2142 read(9, "CAN\n", 1002) = 4 --- Agent reading cancel
> 2142 getpid() = 2141
> 2142 write(2, "gpg-agent[2141]: command 'GENKEY' failed: IPC call has been
> cancelled", 69) = 69
> 2142 write(2, "\n", 1) = 1
> 2142 write(9, "ERR 67109141 IPC call has been cancelled <GPG Agent>", 52)
> = 52 --- Agent telling gnupg about cancel
> 2138 <... read resumed> "ERR 67109141 IPC call has been cancelled <GPG
> Agent>", 1002) = 52 -- gpg reading cancel
> 2138 read(3, <unfinished ...>
> 2142 write(9, "\n", 1) = 1
> 2138 <... read resumed> "\n", 950) = 1
> 2138 write(2, "gpg: agent_genkey failed: Operation cancelled", 45) = 45
> 2138 write(2, "\n", 1) = 1
> 2138 write(2, "gpg: key generation failed: Operation cancelled", 47) = 47
> 2138 write(2, "\n", 1) = 1
> 2138 write(2, "[GNUPG:] ERROR key_generate 33554531", 36) = 36
> 2138 write(2, "\n", 1) = 1
> 2138 write(2, "[GNUPG:] KEY_NOT_CREATED ", 25) = 25
> 2138 write(2, "\n", 1) = 1
> 2138 read(0, "", 8192) = 0
> 2138 munmap(0x7faad0a44000, 65536) = 0
> 2138 exit_group(2) = ?
> 2138 +++ exited with 2 +++
>
> Does someone know how to fix that?
>
> LG Roman

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 03/09/18 18:56, Fiedler Roman wrote:
> With gpg1 a similar command should have verified, that the signature
> is exactly from the single public key stored in "key.pub".

This has never been a supported use of gpg, it just happened to work
because GnuPG 1.4 happened to use a bunch of exported OpenPGP
certificates as the format of its public keyring. This was an
implementation detail which enabled you to do this. Just because you can
use the rear side of a screwdriver to hammer in a small nail doesn't
mean you're meant to do carpentry that way ;-). In GnuPG, the homedir is
pretty much not part of the interface, it is internal with some
exceptions like .conf-files and being able to retrieve revocation
certificates from it. The keyring format has changed and GnuPG also
expects a lot of other different things in its homedir. So it no longer
works.

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
before you can do verifications. I didn't see the new option in the few
announcements I read. Either it was discussed and not done or discussed
and implemented, can't recall.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

On Mon, 3 Sep 2018 19:25, peter@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]


Shalom-Salam,

Werner

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

> Von: Peter Lebbing [mailto:peter@digitalbrains.com]
>
> On 03/09/18 18:56, Fiedler Roman wrote:
> > With gpg1 a similar command should have verified, that the signature
> > is exactly from the single public key stored in "key.pub".
>
> This has never been a supported use of gpg, it just happened to work
> because GnuPG 1.4 happened to use a bunch of exported OpenPGP
> certificates as the format of its public keyring. This was an
> implementation detail which enabled you to do this. Just because you can
> use the rear side of a screwdriver to hammer in a small nail doesn't
> mean you're meant to do carpentry that way ;-).

Maybe the current hammer documentation should be updated, to remove
the "--use-as-hammer" options? Or at least declare, that they shall not
be used that way. See:

https://www.gnupg.org/gph/en/manual/r1606.html
https://www.gnupg.org/gph/en/manual/r1574.html

Without that, what should be the purpose of the "--no-default-keyring"
except to flush all default keys and operate only on the ones given
via the "--keyring" option?

> In GnuPG, the homedir is
> pretty much not part of the interface, it is internal with some
> exceptions like .conf-files and being able to retrieve revocation
> certificates from it. The keyring format has changed and GnuPG also
> expects a lot of other different things in its homedir. So it no longer
> works.

Maybe the "--no-default-keyring" should return something like "obsolete
gnupg file API used" instead of "[GNUPG:] UNEXPECTED 0"?

> 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
> before you can do verifications. I didn't see the new option in the few
> announcements I read. Either it was discussed and not done or discussed
> and implemented, can't recall.

Werner gave a good solution in another followup message. May I recommend
updating the online docu/man page for "--verify" with something like this?

"""For automated verification against a single public key, the gpgv tool may
better suit you needs"""

Or could I submit patches to documentation and source code (error handling)
myself? I did not find a "contribute" section on the gnupg website at a first glance
(menus/FAQs), but could look into it deeper, if helpful.

Regards, Roman

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Von: Werner Koch [mailto:wk@gnupg.org]
>
> On Mon, 3 Sep 2018 19:25, peter@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

On 04/09/18 09:52, Fiedler Roman wrote:
> Maybe the current hammer documentation should be updated, to remove
> the "--use-as-hammer" options? Or at least declare, that they shall not
> be used that way. See:
>
> https://www.gnupg.org/gph/en/manual/r1606.html
> https://www.gnupg.org/gph/en/manual/r1574.html

Ah, but you didn't pass it a keyring, did you? You passed it an exported
OpenPGP key, which is no longer the format of a keyring! :-)

> Werner gave a good solution in another followup message.

Yes, the new option to *encrypt* to a key in a file made me forget about
the age-old gpgv :-). I got it mixed up.

> Or could I submit patches to documentation and source code (error handling)
> myself? I did not find a "contribute" section on the gnupg website at a first glance
> (menus/FAQs), but could look into it deeper, if helpful.

I'd say: definitely. I'm not a GnuPG dev, though. I think for instance
the git repository with the man page can be reached through the web on [1].

Note that if you were to carefully read the long table of contents of
the "GnuPG manual"[2], you'd stumble upon these entries:

> 8 Helper Tools
> [...]
> 8.2 Verify OpenPGP signatures

I think your addition to the man page would be helpful, but a balance
has to be struck between documenting what something does and what it
does not. Writing good, clear documentation is hard. I don't think the
current documentation is as good as it could be. The fact that there are
so many options and commands makes it very hard to do right. In the
current state of the documentation, I think your addition is a good one.
More in general, I think there should be documentation that users read
which means they wouldn't end up at the man page for the gpg
command-line tool at all, but they would immediately have chosen gpgv in
the first place. I hope I'm succeeding in getting my intention across,
I'm having some trouble putting it in words :-).

man pages are reference works, not user guides. You already know how to
use something, but the details elude you for a moment? You grab a
reference. You can't learn English from a dictionary, and you can't
efficiently look up the spelling of a word in an English course.

In this particular case, what set you off in the wrong direction was
that you were doing something which was never *intended* to work, it
just did. Worse, people have been telling other people that this was
something you could do. I think it's hard to catch all these things in
documentation when at the same time people on the interwebs are saying
"oh you should use an exported key as keyring".

HTH,

Peter.

[1] <https://dev.gnupg.org/source/gnupg/browse/master/doc/gpg.texi>
[2] <https://gnupg.org/documentation/manuals/gnupg/#SEC_Contents>

--
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 <http://digitalbrains.com/2012/openpgp-key-peter>

> Von: Peter Lebbing [mailto:peter@digitalbrains.com]
>
> On 04/09/18 09:52, Fiedler Roman wrote:
> > Maybe the current hammer documentation should be updated, to remove
> > the "--use-as-hammer" options? Or at least declare, that they shall not
> > be used that way. See:
> >
> > https://www.gnupg.org/gph/en/manual/r1606.html
> > https://www.gnupg.org/gph/en/manual/r1574.html
>
> Ah, but you didn't pass it a keyring, did you? You passed it an exported
> OpenPGP key, which is no longer the format of a keyring! :-)

This might be an issue, but now I tried also with the "pubring.kbx" file
from the key used to create the signature (without exporting anything)
and the error message stays completely the same. The message is quite
similar to starting gpgv without any keyring at all:

# /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent data.gpg
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/proc/self/fd/nonexistent/trustedkeys.kbx': General error
[GNUPG:] ERROR add_keyblock_resource 33554433
[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error

So maybe the "GNUPG:] UNEXPECTED 0" (last two lines) are not related to the keyring at all (the
first three lines are related).

BTW: what would be the recommended/most secure way to create a keyring
file with a single public key, probably without all the gpg2 overhead of creating
home directory, searching proc to kill gpg-agent afterwards and cleaning up
the home directory in secure way afterwards?

After trying to get gnupg2 working for more than a day now, but always managing
to get only from one undocumented error message to the next, one undocumented
argument behavior to the next, I will downgrade to gnupg1. In my opinion, next
migration attempt should be started with next Ubuntu LTS 2020 earliest.

> > Werner gave a good solution in another followup message.
>
> Yes, the new option to *encrypt* to a key in a file made me forget about
> the age-old gpgv :-). I got it mixed up.
>
> > Or could I submit patches to documentation and source code (error
> handling)
> > myself? I did not find a "contribute" section on the gnupg website at a first
> glance
> > (menus/FAQs), but could look into it deeper, if helpful.
>
> I'd say: definitely. I'm not a GnuPG dev, though. I think for instance
> the git repository with the man page can be reached through the web on [1].

Thanks for the reference, I will try to figure out, how gnupg development is structured,
e.g. if patches have to be submitted to gnupg-dev first ....

> Note that if you were to carefully read the long table of contents of
> the "GnuPG manual"[2], you'd stumble upon these entries:
>
> > 8 Helper Tools
> > [...]
> > 8.2 Verify OpenPGP signatures
>
> I think your addition to the man page would be helpful, but a balance
> has to be struck between documenting what something does and what it
> does not. Writing good, clear documentation is hard. I don't think the
> current documentation is as good as it could be. The fact that there are
> so many options and commands makes it very hard to do right. In the
> current state of the documentation, I think your addition is a good one.
> More in general, I think there should be documentation that users read
> which means they wouldn't end up at the man page for the gpg
> command-line tool at all, but they would immediately have chosen gpgv in
> the first place. I hope I'm succeeding in getting my intention across,
> I'm having some trouble putting it in words :-).
>
> man pages are reference works, not user guides. You already know how to
> use something, but the details elude you for a moment? You grab a
> reference. You can't learn English from a dictionary, and you can't
> efficiently look up the spelling of a word in an English course.
>
> In this particular case, what set you off in the wrong direction was
> that you were doing something which was never *intended* to work, it
> just did. Worse, people have been telling other people that this was
> something you could do. I think it's hard to catch all these things in
> documentation when at the same time people on the interwebs are saying
> "oh you should use an exported key as keyring".

Fully agree here. There is something important in the documentation missing.

I already offered once to contribute to that part of documentation, but there
was dispute with other gnupg mailing list folks, that had quite different understanding
of engineering-, design- and end user documentation for security critical
software.

From my point of view following structure would improve the whole process:

1) have use-case documentation describing scenarios where gpg should be used.
Make them as distinct as possible to use-cases where gpg should NOT be used.
One use case group could be "fully automated en/decrypt and verify on devices
without permanent storage", another one "Embedded gpg for e-mail decryption"
or "gpg for command line e-mail/file encryption" ....

2) For designing GPG, derive software requirements from all usecases

3) for end user documentation, give recommended gpg configuration, command
line, reference output (for debugging) for each set of use-cases. The end user
has then to decide which set of use-cases is closest to the one he wants to use
to find the most appropriate gpg calls/config.



While documentation is structured that way, do you have to add anything to an
intermediate docu patch for [1], e.g.:

--- gpg.texi 2018-09-04 11:31:35.654503169 +0000
+++ gpg.texi 2018-09-04 11:34:42.337194756 +0000
@@ -1,5 +1,5 @@
@c Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
-@c 2008, 2009, 2010 Free Software Foundation, Inc.
+@c 2008, 2009, 2010, 2018 Free Software Foundation, Inc.
@c This is part of the GnuPG manual.
@c For copying conditions, see the file gnupg.texi.

@@ -1449,11 +1449,14 @@

Note that this adds a keyring to the current list. If the intent is to
use the specified keyring alone, use @option{--keyring} along with
-@option{--no-default-keyring}.
+@option{--no-default-keyring}. To verify a signature against only
+keys from a single keyring file "gpgv" might better suit your needs.

If the option @option{--no-keyring} has been used no keyrings will
be used at all.

+Bear in mind that valid keyring files should be created using
+@option(--import) on an empty @option(--primary-keyring) file.

@item --secret-keyring @var{file}
@opindex secret-keyring



> [1] <https://dev.gnupg.org/source/gnupg/browse/master/doc/gpg.texi>
> [2] <https://gnupg.org/documentation/manuals/gnupg/#SEC_Contents>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Tue, 4 Sep 2018 10:08, Roman.Fiedler@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.

On Tue, 4 Sep 2018 09:52, Roman.Fiedler@ait.ac.at said:

> Werner gave a good solution in another followup message. May I recommend
> updating the online docu/man page for "--verify" with something like this?

we have

Note: Sometimes the use of the @command{gpgv} tool is easier than
using the full-fledged @command{gpg} with this option. @command{gpgv}
is designed to compare signed data against a list of trusted keys and
returns with success only for a good signature. It has its own manual
page.

in the docs since 2.1.18 or .19 (January 2017)


Salam-Shalom,

Werner

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

On 04/09/18 13:55, Fiedler Roman wrote:
> This might be an issue, but now I tried also with the "pubring.kbx" file
> from the key used to create the signature (without exporting anything)
> and the error message stays completely the same.

I don't understand, could you give commands, expected behaviour and
actual output?

> BTW: what would be the recommended/most secure way to create a keyring
> file with a single public key

For gpgv, I'd just use an exported single public key like you tried to
do with gpg. gpgv has no problems with that.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

On 04/09/18 10:08, Fiedler Roman wrote:
> /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring key.pub data.gpg

This would open /proc/self/fd/nonexistent/key.pub as the keyring.

From the man page of gpgv:
> Add file to the list of keyrings. If file begins with a tilde
> and a slash, these are replaced by the HOME directory. If the
> filename does not contain a slash, it is assumed to be in the
> home-directory ("~/.gnupg" if --homedir is not used).

What works for me is:

$ gpgv --keyring ./key.gpg data.gpg

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 <http://digitalbrains.com/2012/openpgp-key-peter>

On 04/09/18 15:22, Peter Lebbing wrote:
> I don't understand, could you give commands, expected behaviour and
> actual output?

To clarify, I thought you were giving an example of "starting gpgv
without any keyring at all", because you gave it a non-existing homedir.
Only on re-reading your other mail did I understand this was an example
of how you were actually trying to do it.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

> Von: Peter Lebbing [mailto:peter@digitalbrains.com]
>
> On 04/09/18 15:22, Peter Lebbing wrote:
> > I don't understand, could you give commands, expected behaviour and
> > actual output?
>
> To clarify, I thought you were giving an example of "starting gpgv
> without any keyring at all", because you gave it a non-existing homedir.
> Only on re-reading your other mail did I understand this was an example
> of how you were actually trying to do it.

Sorry about being inprecise in my reply.

Yes, you are completely right: no matter which command line used, the

"[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error"

error from gpgv or plain gpg does not vanish, only additional error messages
can be added depending on the keyrings used.

Using the /proc/self/fd/nonexistent as home directory should only serve the
purpose, that it is much harder for an attacker to create that path than one
where the parent directory is a writable file system.


I just removed the executable bit from "gpg2" binary and are now isolating
all gpg calls in a clean wrapper library to invoke "gpg1". When all use-cases
work with gpg1 and there is still some time, I will try to implement also a gpg2
wrapper to start another gpg1->gpg2 migration attempt. But that will be end
of September earliest.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Von: Werner Koch [mailto:wk@gnupg.org]
>
> On Tue, 4 Sep 2018 10:08, Roman.Fiedler@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

On 04/09/18 18:31, Fiedler Roman wrote:
> /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring sign.pub /proc/self/fd/0

You missed my point. You are not including a slash in the keyring
argument, so gpgv is looking for it in the homedir. To quote the gpgv
man page again:

> --keyring file
> Add file to the list of keyrings. If file begins with a tilde
> and a slash, these are replaced by the HOME directory. If the
> filename does not contain a slash, it is assumed to be in the
> home-directory ("~/.gnupg" if --homedir is not used).

And this works:

$ gpgv --keyring ./key.gpg data.gpg

> Splitting up the message gives me
>
> 000001-001.pk_enc
> 000002-018.encrypted_mdc

This is an encrypted message. gpgv can't do anything with it.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

> Von: Peter Lebbing [mailto:peter@digitalbrains.com]
>
> On 04/09/18 18:31, Fiedler Roman wrote:
> > /usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring
> sign.pub /proc/self/fd/0
>
> You missed my point. You are not including a slash in the keyring
> argument, so gpgv is looking for it in the homedir.

Sorry, this is an error copying the command to the mail. In fact, the "gpgv"
call is and was always done with a long, absolute pathname I do not want to
disclose to the list. Therefore I just forgot the fact of the special pathname
behaviour immediately after reading it.

> And this works:
>
> $ gpgv --keyring ./key.gpg data.gpg
>
> > Splitting up the message gives me
> >
> > 000001-001.pk_enc
> > 000002-018.encrypted_mdc
>
> This is an encrypted message. gpgv can't do anything with it.

Then why does gpg1 verify claim to see a valid signature on the
very same file if there isn't even a signature included? I will
analyze it deeper but that will take time.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> Von: Peter Lebbing [mailto:peter@digitalbrains.com]
> ...
> $ gpgv --keyring ./key.gpg data.gpg
>
> > Splitting up the message gives me
> >
> > 000001-001.pk_enc
> > 000002-018.encrypted_mdc
>
> This is an encrypted message. gpgv can't do anything with it.

No, this is a signed AND encrypted message. Can gpgv only be
used to verify signatures on signed-only but not signed AND
encrypted messages, maybe due to encrypt AFTER sign scheme?

If so update of the manual pages and a more talkative error message
instead of "gpgv: verify signatures failed: Unexpected error" would
be really nice.


Test trail:

* Prepare:

Remove standard GPG homedir to detect any access to it by error
(should never happen).

rm -rf -- "${HOME}/.gnupg"

testDir="$(mktemp -d)"
cd -- "${testDir}"

* Generate receiver key:

mkdir --mode=0700 -- Receiver
cat <<EOF | /usr/bin/gpg1 --homedir Receiver --batch --gen-key /proc/self/fd/0
Key-Type: RSA
Key-Length: 2048
Subkey-Type: ELG-E
Subkey-Length: 2048
Name-Real: Receiver Key
Expire-Date: 0
%commit
EOF
/usr/bin/gpg1 --homedir Receiver --export "Receiver Key" > Receiver/ReceiverKey.pub

* Generate sender key:

mkdir --mode=0700 -- Sender
/usr/bin/gpg1 --homedir Sender --batch --command-fd 0 --status-fd 1 --gen-key <<EOF
%no-protection
Key-Type: RSA
Key-Length: 2048
Subkey-Type: ELG-E
Subkey-Length: 2048
Name-Real: Sender Key
Expire-Date: 0
%commit
EOF
/usr/bin/gpg1 --homedir Sender --export "Sender Key" > Sender/SenderKey.pub

* Generate message:

/usr/bin/gpg1 --no-options --homedir Sender --keyring Receiver/ReceiverKey.pub --lock-never --trust-model always --sign --local-user "Sender Key" --encrypt --throw-keyids --hidden-recipient "Receiver Key" <<EOF > Sender/OutgoingMessage.gpg
Secret message
EOF

* 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

gpg: Good signature from "Sender Key"
[GNUPG:] VALIDSIG 7C8D39EA43614F2266EBD8F52A1DF9C596868A14 2018-09-05 1536135808 0 4 0 1 8 00 7C8D39EA43614F2266EBD8F52A1DF9C596868A14

* Verify only with gpgv (from gnupg2):

Not clear from documentation, if gpgv could verify signed AND
encrypted messages. Use absolute path for sure as relative pathnames
will be handled differently.

/usr/bin/gpgv --status-fd 2 --homedir /proc/self/fd/nonexistent --keyring "${testDir}/Sender/SenderKey.pub" /proc/self/fd/0 < Sender/OutgoingMessage.gpg

[GNUPG:] UNEXPECTED 0
gpgv: verify signatures failed: Unexpected error

* Final checks:

Ensure default homedir was not created due to error in testing protocol:

ls -al -- "${HOME}/.gnupg"
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Wed, 5 Sep 2018 10:45, Roman.Fiedler@ait.ac.at said:

> No, this is a signed AND encrypted message. Can gpgv only be
> used to verify signatures on signed-only but not signed AND
> encrypted messages, maybe due to encrypt AFTER sign scheme?

Correct. The signature is encrypted and thus it needs to be decrypted
before the signature can be checked. gpgv is only for checking
signature becuase it is designed to work without private keys.


Salam-Shalom,

Werner

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

On Tue, 4 Sep 2018 18:31, Roman.Fiedler@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.

> Von: Werner Koch [mailto:wk@gnupg.org]
>
> On Tue, 4 Sep 2018 18:31, Roman.Fiedler@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.

That is good, one more issue not having to care about.

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

Sorry, but you are completely off here. You might also publish your public
keys world wide. But they may also be known only to a closed user group
to avoid traffic analysis, user enumeration, factorization attacks if poor
generators were used, ..

If you do not believe me, just search your key servers for NSA, BND, ...
public keys. I am sure, they use public key cryptography in many domains
and have very little of their public keys published.

The real topic of this discussion might be more if gnupg is a generic public key
cryptography security solution (where hiding keys might make sense, thus
software should be able to help fulfilling that goal) or if gnupg should only
be used for desktop e-mail encryption, where all those issues are much
less pressing as security requirements are much lower.

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

> Von: Werner Koch [mailto:wk@gnupg.org]
>
> On Wed, 5 Sep 2018 10:45, Roman.Fiedler@ait.ac.at said:
>
> > No, this is a signed AND encrypted message. Can gpgv only be
> > used to verify signatures on signed-only but not signed AND
> > encrypted messages, maybe due to encrypt AFTER sign scheme?
>
> Correct. The signature is encrypted and thus it needs to be decrypted
> before the signature can be checked. gpgv is only for checking
> signature becuase it is designed to work without private keys.

Could you please update the documentation and the error messages
from gpg1/gpg2/gpgv to be more helpful?

Now I can also reproduce with gpg1/gpg2 verify on encrypted messages,
gpg1 reports "unexpected data", which is a little more helpful than
"unexpected error" from gpg2.

Regards,
Roman

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

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.

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 <http://digitalbrains.com/2012/openpgp-key-peter>

> Von: Peter Lebbing [mailto:peter@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 <long_keyid_or_fpr> <username>

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

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 <http://digitalbrains.com/2012/openpgp-key-peter>