From lee.yanzhe at yanzhe.org  Sun Sep  2 05:09:14 2018
From: lee.yanzhe at yanzhe.org (Yanzhe Lee)
Date: Sun, 2 Sep 2018 11:09:14 +0800
Subject: "gpg: signing failed: Invalid length" when use brainpool512r1 keys to
 sign things
Message-ID: <ee086c72-77c6-1e3b-ea35-0607b779d90e@yanzhe.org>

Hello,

Recently I come across this error "gpg: signing failed: Invalid length" when use brainpool512r1 keys to do sign operations, such as --sign-key, --lsign-key or even generate a brainpool512r1 key.

All keys except Brainpool P-384 and Brainpool P-512 work fine. I tried to generate Brainpool P-256, it's fine.
Strange thing is that I use brainpool512r1 before, and no error occurred. The error just shows recently, maybe it is a configuration error?



? 
- Version

gpg (GnuPG) 2.2.4/2.2.9 both tried
libgcrypt 1.8.1
Ubuntu 18.04 LTS/MacOS 10.13.6 both tried

- steps to reproduce this error:

gpg --expert --full-gen-key

gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
?? (1) RSA and RSA (default)
?? (2) DSA and Elgamal
?? (3) DSA (sign only)
?? (4) RSA (sign only)
?? (7) DSA (set your own capabilities)
?? (8) RSA (set your own capabilities)
?? (9) ECC and ECC
? (10) ECC (sign only)
? (11) ECC (set your own capabilities)
? (13) Existing key
Your selection? 11
Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate
Current allowed actions: Sign Certify

?? (S) Toggle the sign capability
?? (A) Toggle the authenticate capability
?? (Q) Finished

Your selection? a

Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate
Current allowed actions: Sign Certify Authenticate

?? (S) Toggle the sign capability
?? (A) Toggle the authenticate capability
?? (Q) Finished

Your selection? q
Please select which elliptic curve you want:
?? (1) Curve 25519
?? (3) NIST P-256
?? (4) NIST P-384
?? (5) NIST P-521
?? (6) Brainpool P-256
?? (7) Brainpool P-384
?? (8) Brainpool P-512
?? (9) secp256k1
Your selection? 8
Please specify how long the key should be valid.
???????? 0 = key does not expire
????? <n>? = key expires in n days
????? <n>w = key expires in n weeks
????? <n>m = key expires in n months
????? <n>y = key expires in n years
Key is valid for? (0) 1d
Key expires at Mon 03 Sep 2018 10:39:53 AM CST
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: test2
Email address: test2
Comment:
You selected this USER-ID:
??? "test2 <test2>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: signing failed: Invalid length
gpg: make_keysig_packet failed: Invalid length
Key generation failed: Invalid length


Best regards,
Yanzhe Lee

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3EA647C79FDA9CD1.asc
Type: application/pgp-keys
Size: 10394 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180902/c556d14d/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180902/c556d14d/attachment.sig>

From mlnl at mailbox.org  Sun Sep  2 14:38:07 2018
From: mlnl at mailbox.org (mlnl)
Date: Sun, 2 Sep 2018 14:38:07 +0200
Subject: "gpg: signing failed: Invalid length" when use brainpool512r1
 keys to sign things
In-Reply-To: <ee086c72-77c6-1e3b-ea35-0607b779d90e@yanzhe.org>
References: <ee086c72-77c6-1e3b-ea35-0607b779d90e@yanzhe.org>
Message-ID: <1d49e271-a328-7203-3457-7f1f7f5da007@mailbox.org>

Hi,

> gpg: signing failed: Invalid length
> gpg: make_keysig_packet failed: Invalid length
> Key generation failed: Invalid length

tested & confirmed with GnuPG 2.2.10, libgcrypt 1.8.3 Debian Stretch 9.5

-- 
mlnl


From gniibe at fsij.org  Mon Sep  3 08:36:33 2018
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 03 Sep 2018 15:36:33 +0900
Subject: "gpg: signing failed: Invalid length" when use brainpool512r1
 keys to sign things
In-Reply-To: <1d49e271-a328-7203-3457-7f1f7f5da007@mailbox.org>
References: <ee086c72-77c6-1e3b-ea35-0607b779d90e@yanzhe.org>
 <1d49e271-a328-7203-3457-7f1f7f5da007@mailbox.org>
Message-ID: <878t4jw0i6.fsf@fsij.org>

mlnl <mlnl at mailbox.org> wrote:
>> gpg: signing failed: Invalid length
>> gpg: make_keysig_packet failed: Invalid length
>> Key generation failed: Invalid length
>
> tested & confirmed with GnuPG 2.2.10, libgcrypt 1.8.3 Debian Stretch 9.5

Not reproducible here (similar on Debian Stretch).

I tested with no configuration.

Is it reproducible under no configuration?

I tested with:

	$ export GNUPGHOME=/tmp/g; mkdir -m=0700 $GNUPGHOME
-- 


From kristian.fiskerstrand at sumptuouscapital.com  Mon Sep  3 09:58:24 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Mon, 3 Sep 2018 09:58:24 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
Message-ID: <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>

On 08/29/2018 12:41 AM, Kristian Fiskerstrand wrote:
> On 08/28/2018 08:22 PM, Daniel Kahn Gillmor wrote:
>> On Sat 2018-08-25 08:18:48 +0200, sunrises at gmx.com wrote:
>>> Hi all, since some days I'm having an issue with pinentry, I've set the default agent as pinentry-qt4
>>> from update-alternatives (I've also tried pinentry-qt and pinentry-gnome) but when I run gpg --decrypt file
>>> it's always falling on the cli for prompting the password. In .gnupg/gpg-agent.conf as the first line I have 
>>> pinentry-program /usr/bin/pinentry-qt4 as well, but I don't get why it's ignoring it.
>>> There's a way to debug what's going on?
>>
>> can you give a little bit more information about your system (OS,
>> version, version of gpg, version of pinentry, etc), and how you're
>> accessing it (e.g. via ssh, via a graphical environment, etc)?
>>
>> have you terminated your gpg-agent program ("gpgconf --kill gpg-agent")
>> after updating your settings in ~/.gnupg/gpg-agent.conf  so that the
>> settings would take effect?
> 
> Not sure if it is related, but I'm currently also investigating an issue
> with the qt pinentry for Gentoo installations. no similar issues for the
> other ones.. I'm able to reproduce failures with the auto-spawned
> gpg-agent though, that doesn't materialize when calling the pinentry
> application directly in an environment.
> 
> In this case the gtk2 pinentry works as expected though... but something
> is possibly off with the handling of DISPLAY (as far as I've gotten in
> my debugging that is the only diff in the env vars between the direct
> invocation and the bash propmpted one, it might not be ultimately relevant)
> 

Just to have it mentioned, turned out this was an issue with missing
keep-display in gpg-agent.conf, without this the Qt4/5 pinentry fail
(although I've been told it is not an issue in KDE environment).

gpg-agent without keep-display still seems to send display as argument
in --display :0 style, but this does not seem to be honored.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Strength lies in differences, not in similarities."
(Stephen Covey)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180903/d47fecd9/attachment.sig>

From mlnl at mailbox.org  Mon Sep  3 17:40:57 2018
From: mlnl at mailbox.org (mlnl)
Date: Mon, 3 Sep 2018 17:40:57 +0200
Subject: "gpg: signing failed: Invalid length" when use brainpool512r1
 keys to sign things
In-Reply-To: <878t4jw0i6.fsf@fsij.org>
References: <ee086c72-77c6-1e3b-ea35-0607b779d90e@yanzhe.org>
 <1d49e271-a328-7203-3457-7f1f7f5da007@mailbox.org> <878t4jw0i6.fsf@fsij.org>
Message-ID: <b359bd20-d755-9ab0-9189-a84a51278ad1@mailbox.org>

Hi,

>> tested & confirmed with GnuPG 2.2.10, libgcrypt 1.8.3 Debian Stretch 9.5
> 
> Not reproducible here (similar on Debian Stretch).
> 
> I tested with no configuration.
> 
> Is it reproducible under no configuration?
> 
> I tested with:
> 
> 	$ export GNUPGHOME=/tmp/g; mkdir -m=0700 $GNUPGHOME

I have looked at my gpg.conf and found a commented hint for myself ;):
# cert-digest-algo SHA512 for ECC >= 512-bit

Tested again with cert-digest-algo SHA512 without problems:
pub   brainpoolP512r1/0D9032C369992D8E 2018-09-03 [SCA] [verf?llt:
2019-09-03]
Schl.-Fingerabdruck = 2601 6E4C BA25 2686 EEC1  EBB8 0D90 32C3 6999 2D8E
  Keygrip = 985D56A2FE62C404CC0382815C391E01B5769F58
uid  testbp512 <testbp512 at test.de>

-- 
mlnl


From Siemons at CleanFuels.nl  Mon Sep  3 17:03:19 2018
From: Siemons at CleanFuels.nl (Roland Siemons (P))
Date: Mon, 3 Sep 2018 17:03:19 +0200
Subject: revocation troubles & smartcard troubles
Message-ID: <66ac615c-11d8-2cc2-4016-fc2a3e02fcd9@CleanFuels.nl>

Dear GnuPG,

I am already using GnuPG for a long time. But try to improve my
understanding of and working with it.
I became a member of Free Software Foundation Europe, and got a
smartcard. I wanted to use it.

And that is where the trouble started:
I intended to copy all my personal keys to the smart card.
In Kleopatra, I selected "Tools/Manage smartcards"
Then I selected "Import a certificate from a file", and selected files
from my laptop.
I was under the impression that I was copying files to the smartcard.
By doing so, I not only selected my private key but also my revocation
key (because, why should I enable a thief of my laptop to revoke my key?).
And then it appeared that I had revoked my entire key pair. Unintended!
Apparently, under smartcard management, I was not at all copying files
to the smartcard. Apparently, I was doing something else. Did I at all
copy files to the smartcard?

Questions:
Can I UNrevoke that key?
How can I see what is on the smartcard?
How can I copy files to the smartcard?

I studied the GnuPG Smartcard How-To
(www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
entirely linux oriented.
I am working on a win7 system.

Can anyone help me further?

Thanks!

Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAEEC5E2ED87628F5.asc
Type: application/pgp-keys
Size: 8477 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180903/a27394b8/attachment-0001.key>

From dirk.gottschalk1980 at googlemail.com  Mon Sep  3 18:41:29 2018
From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk)
Date: Mon, 03 Sep 2018 18:41:29 +0200
Subject: revocation troubles & smartcard troubles
In-Reply-To: <66ac615c-11d8-2cc2-4016-fc2a3e02fcd9@CleanFuels.nl>
References: <66ac615c-11d8-2cc2-4016-fc2a3e02fcd9@CleanFuels.nl>
Message-ID: <AE23B41E-B679-48BB-85A5-7CF8CEB4F364@googlemail.com>

As long as you did not publish reports revocation, delete the key and re-import it without the revocation cert. 

Am 3. September 2018 17:03:19 MESZ schrieb "Roland Siemons (P)" <Siemons at CleanFuels.nl>:
>Dear GnuPG,
>
>I am already using GnuPG for a long time. But try to improve my
>understanding of and working with it.
>I became a member of Free Software Foundation Europe, and got a
>smartcard. I wanted to use it.
>
>And that is where the trouble started:
>I intended to copy all my personal keys to the smart card.
>In Kleopatra, I selected "Tools/Manage smartcards"
>Then I selected "Import a certificate from a file", and selected files
>from my laptop.
>I was under the impression that I was copying files to the smartcard.
>By doing so, I not only selected my private key but also my revocation
>key (because, why should I enable a thief of my laptop to revoke my
>key?).
>And then it appeared that I had revoked my entire key pair. Unintended!
>Apparently, under smartcard management, I was not at all copying files
>to the smartcard. Apparently, I was doing something else. Did I at all
>copy files to the smartcard?
>
>Questions:
>Can I UNrevoke that key?
>How can I see what is on the smartcard?
>How can I copy files to the smartcard?
>
>I studied the GnuPG Smartcard How-To
>(www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
>entirely linux oriented.
>I am working on a win7 system.
>
>Can anyone help me further?
>
>Thanks!
>
>Roland

-- 
Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180903/102f4459/attachment.html>

From Roman.Fiedler at ait.ac.at  Mon Sep  3 18:56:41 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Mon, 3 Sep 2018 16:56:41 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
Message-ID: <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>

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


From peter at digitalbrains.com  Mon Sep  3 19:25:10 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 3 Sep 2018 19:25:10 +0200
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
Message-ID: <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@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 ;-). 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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180903/30612d8a/attachment.sig>

From wk at gnupg.org  Tue Sep  4 07:55:20 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Sep 2018 07:55:20 +0200
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com> (Peter
 Lebbing's message of "Mon, 3 Sep 2018 19:25:10 +0200")
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
Message-ID: <87bm9dg62f.fsf@wheatstone.g10code.de>

On Mon,  3 Sep 2018 19:25, peter at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/ae60afca/attachment.sig>

From Roman.Fiedler at ait.ac.at  Tue Sep  4 09:52:33 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 4 Sep 2018 07:52:33 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
Message-ID: <2669076f402241d6be36b5605049c8f4@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at 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


From Roman.Fiedler at ait.ac.at  Tue Sep  4 10:08:48 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 4 Sep 2018 08:08:48 +0000
Subject: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <87bm9dg62f.fsf@wheatstone.g10code.de>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
Message-ID: <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>

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

From andrewg at andrewg.com  Tue Sep  4 10:11:55 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 4 Sep 2018 09:11:55 +0100
Subject: First smartcard operation always fails
Message-ID: <7560326c-9cc5-1cb7-a6f0-749128911335@andrewg.com>

Hi, all.

I've had a pgp smartcard v2.1 for years now (two, actually), and I've
noticed that no matter what operation I perform, the first attempt after
inserting the card, or waking from sleep with the card inserted, fails.

Example:

```
andrewg at fred:~$ ssh my.server
sign_and_send_pubkey: signing failed: agent refused operation
andrewg at my.server's password: ^C

andrewg at fred:~$ ssh my.server
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-92-lowlatency x86_64)
```

A similar thing happens with signing emails, and my signing and
authentication subkeys are distinct.

This has been bugging me for as long as I can remember, across different
machines, different software versions and OSes (Linux and Mac), and
using both smartcards.

Does anyone have any idea what's going on?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/8490e521/attachment.sig>

From andrewg at andrewg.com  Tue Sep  4 10:17:49 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 4 Sep 2018 09:17:49 +0100
Subject: First smartcard operation always fails
In-Reply-To: <7560326c-9cc5-1cb7-a6f0-749128911335@andrewg.com>
References: <7560326c-9cc5-1cb7-a6f0-749128911335@andrewg.com>
Message-ID: <63e6787f-12cb-350d-ed65-7f28a4cbc5e1@andrewg.com>

On 04/09/18 09:11, Andrew Gallagher wrote:
> Hi, all.
> 
> I've had a pgp smartcard v2.1 for years now (two, actually), and I've
> noticed that no matter what operation I perform, the first attempt after
> inserting the card, or waking from sleep with the card inserted, fails.

And I have just confirmed (by sending that mail) that both the first
auth operation AND the first signing operation fail, separately.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/d62d8aca/attachment.sig>

From Siemons at CleanFuels.nl  Tue Sep  4 10:29:20 2018
From: Siemons at CleanFuels.nl (Roland Siemons (P))
Date: Tue, 4 Sep 2018 10:29:20 +0200
Subject: Gnupg-users Digest, Vol 180, Issue 3
In-Reply-To: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
References: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
Message-ID: <9ea1bffb-cd6c-c2f3-ac5d-d5938d960c85@CleanFuels.nl>

@ Dirk Gottschalk: Thanks for very effective response to my first question!

Remains:
How can I see what is on the smartcard?
How can I copy files to the smartcard?

I studied the GnuPG Smartcard How-To
(www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
entirely linux oriented. Whereas I am working on a win7 system.

HOWEVER, by trial and error, I found out that the same commands work on
the command line terminal of Win7. I shall test it further.

Best regards,

Roland


On 04/09/2018 09:52, gnupg-users-request at gnupg.org wrote:
> Send Gnupg-users mailing list submissions to
> 	gnupg-users at gnupg.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.gnupg.org/mailman/listinfo/gnupg-users
> or, via email, send a message with subject or body 'help' to
> 	gnupg-users-request at gnupg.org
>
> You can reach the person managing the list at
> 	gnupg-users-owner at gnupg.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnupg-users digest..."
>
>
> Today's Topics:
>
>    1. Re: revocation troubles & smartcard troubles (Dirk Gottschalk)
>    2. AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>       failed: IPC call has been cancelled" (Fiedler Roman)
>    3. Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>       failed: IPC call has been cancelled" (Peter Lebbing)
>    4. Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>       failed: IPC call has been cancelled" (Werner Koch)
>    5. AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>       failed: IPC call has been cancelled" (Fiedler Roman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 03 Sep 2018 18:41:29 +0200
> From: Dirk Gottschalk <dirk.gottschalk1980 at googlemail.com>
> To: gnupg-users at gnupg.org
> Subject: Re: revocation troubles & smartcard troubles
> Message-ID: <AE23B41E-B679-48BB-85A5-7CF8CEB4F364 at googlemail.com>
> Content-Type: text/plain; charset="utf-8"
>
> As long as you did not publish reports revocation, delete the key and re-import it without the revocation cert. 
>
> Am 3. September 2018 17:03:19 MESZ schrieb "Roland Siemons (P)" <Siemons at CleanFuels.nl>:
>> Dear GnuPG,
>>
>> I am already using GnuPG for a long time. But try to improve my
>> understanding of and working with it.
>> I became a member of Free Software Foundation Europe, and got a
>> smartcard. I wanted to use it.
>>
>> And that is where the trouble started:
>> I intended to copy all my personal keys to the smart card.
>> In Kleopatra, I selected "Tools/Manage smartcards"
>> Then I selected "Import a certificate from a file", and selected files
> >from my laptop.
>> I was under the impression that I was copying files to the smartcard.
>> By doing so, I not only selected my private key but also my revocation
>> key (because, why should I enable a thief of my laptop to revoke my
>> key?).
>> And then it appeared that I had revoked my entire key pair. Unintended!
>> Apparently, under smartcard management, I was not at all copying files
>> to the smartcard. Apparently, I was doing something else. Did I at all
>> copy files to the smartcard?
>>
>> Questions:
>> Can I UNrevoke that key?
>> How can I see what is on the smartcard?
>> How can I copy files to the smartcard?
>>
>> I studied the GnuPG Smartcard How-To
>> (www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
>> entirely linux oriented.
>> I am working on a win7 system.
>>
>> Can anyone help me further?
>>
>> Thanks!
>>
>> Roland
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAEEC5E2ED87628F5.asc
Type: application/pgp-keys
Size: 6344 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/452b6aa7/attachment.key>

From Siemons at CleanFuels.nl  Tue Sep  4 10:31:59 2018
From: Siemons at CleanFuels.nl (Roland Siemons (P))
Date: Tue, 4 Sep 2018 10:31:59 +0200
Subject: Subkeys
In-Reply-To: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
References: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
Message-ID: <f66c872a-e41c-04a0-df75-97dde084b06c@CleanFuels.nl>

Dear GnuPG

As a user of GPG4Win, is there any explanation in the compendium about
the meaning and use of subkeys (I cannot find anything about that matter
in the The Gpg4win Compendium 3.0.0)

Best regards,

-- 
Roland Siemons

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAEEC5E2ED87628F5.asc
Type: application/pgp-keys
Size: 6344 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/2f813d00/attachment-0001.key>

From peter at digitalbrains.com  Tue Sep  4 11:57:51 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 11:57:51 +0200
Subject: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
Message-ID: <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@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! :-)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/5f44c004/attachment.sig>

From peter at digitalbrains.com  Tue Sep  4 12:01:17 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 12:01:17 +0200
Subject: First smartcard operation always fails
In-Reply-To: <63e6787f-12cb-350d-ed65-7f28a4cbc5e1@andrewg.com>
References: <7560326c-9cc5-1cb7-a6f0-749128911335@andrewg.com>
 <63e6787f-12cb-350d-ed65-7f28a4cbc5e1@andrewg.com>
Message-ID: <406d828f-88fd-a8b5-0f27-0098ea4371c7@digitalbrains.com>

On 04/09/18 10:17, Andrew Gallagher wrote:
> And I have just confirmed (by sending that mail) that both the first
> auth operation AND the first signing operation fail, separately.

I have no idea, it's quite curious. As an added bread crumb to follow:
what do the PIN retry counters say after the failure? gpg --card-status.

Do you always use the same reader? Perhaps it is the reader.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/8f7072d5/attachment.sig>

From wiktor at metacode.biz  Tue Sep  4 12:14:18 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Tue, 4 Sep 2018 12:14:18 +0200
Subject: Subkeys
In-Reply-To: <f66c872a-e41c-04a0-df75-97dde084b06c@CleanFuels.nl>
References: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
 <f66c872a-e41c-04a0-df75-97dde084b06c@CleanFuels.nl>
Message-ID: <ec5e65ed-ff2c-3e49-9ecc-c9be17ac3999@metacode.biz>

Hi Roland,

I don't know if you have some specific questions but the Debian wiki
page about Subkeys is nice: https://wiki.debian.org/Subkeys

tl;dr version is primary/subkey setup lets you have your primary key
completely offline and use subkeys for daily work. If something bad
happens to a subkey (e.g. compromise) you can use primary key to revoke it.

There are 4 flags for key usage: C - Certify (for primary keys), S -
signing, E - encryption and A - authentication (e.g. SSH).

Kind regards,
Wiktor

> Dear GnuPG
> 
> As a user of GPG4Win, is there any explanation in the compendium about
> the meaning and use of subkeys (I cannot find anything about that matter
> in the The Gpg4win Compendium 3.0.0)
> 
> Best regards,
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


-- 
https://metacode.biz/@wiktor


From wiktor at metacode.biz  Tue Sep  4 12:15:17 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Tue, 4 Sep 2018 12:15:17 +0200
Subject: Gnupg-users Digest, Vol 180, Issue 3
In-Reply-To: <9ea1bffb-cd6c-c2f3-ac5d-d5938d960c85@CleanFuels.nl>
References: <mailman.5404.1536047557.30381.gnupg-users@gnupg.org>
 <9ea1bffb-cd6c-c2f3-ac5d-d5938d960c85@CleanFuels.nl>
Message-ID: <1017f87b-1aa7-c096-c553-db5507fb0e90@metacode.biz>

On 04.09.2018 10:29, Roland Siemons (P) wrote:
> Remains:
> How can I see what is on the smartcard?

gpg --card-status

> How can I copy files to the smartcard?

You can't copy generic files, smartcard contains only private keys (gpg
--edit-key X, keytocard) and a small amount of data objects (gpg
--card-edit, admin, url/lang/name).

Note that keytocard *moves* key to card, meaning the local copy of the
private key will be deleted. If you don't want that (e.g. encryption
key) either have a copy or *don't* save after keytocard command.

The card can store only 3 keys: one signature, one encryption and one
authentication key.

Kind regards,

Wiktor

On 04.09.2018 10:29, Roland Siemons (P) wrote:
> @ Dirk Gottschalk: Thanks for very effective response to my first question!
> 
> Remains:
> How can I see what is on the smartcard?
> How can I copy files to the smartcard?
> 
> I studied the GnuPG Smartcard How-To
> (www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
> entirely linux oriented. Whereas I am working on a win7 system.
> 
> HOWEVER, by trial and error, I found out that the same commands work on
> the command line terminal of Win7. I shall test it further.
> 
> Best regards,
> 
> Roland
> 
> 
> On 04/09/2018 09:52, gnupg-users-request at gnupg.org wrote:
>> Send Gnupg-users mailing list submissions to
>> 	gnupg-users at gnupg.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> 	http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> or, via email, send a message with subject or body 'help' to
>> 	gnupg-users-request at gnupg.org
>>
>> You can reach the person managing the list at
>> 	gnupg-users-owner at gnupg.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Gnupg-users digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: revocation troubles & smartcard troubles (Dirk Gottschalk)
>>    2. AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>>       failed: IPC call has been cancelled" (Fiedler Roman)
>>    3. Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>>       failed: IPC call has been cancelled" (Peter Lebbing)
>>    4. Re: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>>       failed: IPC call has been cancelled" (Werner Koch)
>>    5. AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
>>       failed: IPC call has been cancelled" (Fiedler Roman)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 03 Sep 2018 18:41:29 +0200
>> From: Dirk Gottschalk <dirk.gottschalk1980 at googlemail.com>
>> To: gnupg-users at gnupg.org
>> Subject: Re: revocation troubles & smartcard troubles
>> Message-ID: <AE23B41E-B679-48BB-85A5-7CF8CEB4F364 at googlemail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> As long as you did not publish reports revocation, delete the key and re-import it without the revocation cert. 
>>
>> Am 3. September 2018 17:03:19 MESZ schrieb "Roland Siemons (P)" <Siemons at CleanFuels.nl>:
>>> Dear GnuPG,
>>>
>>> I am already using GnuPG for a long time. But try to improve my
>>> understanding of and working with it.
>>> I became a member of Free Software Foundation Europe, and got a
>>> smartcard. I wanted to use it.
>>>
>>> And that is where the trouble started:
>>> I intended to copy all my personal keys to the smart card.
>>> In Kleopatra, I selected "Tools/Manage smartcards"
>>> Then I selected "Import a certificate from a file", and selected files
>> >from my laptop.
>>> I was under the impression that I was copying files to the smartcard.
>>> By doing so, I not only selected my private key but also my revocation
>>> key (because, why should I enable a thief of my laptop to revoke my
>>> key?).
>>> And then it appeared that I had revoked my entire key pair. Unintended!
>>> Apparently, under smartcard management, I was not at all copying files
>>> to the smartcard. Apparently, I was doing something else. Did I at all
>>> copy files to the smartcard?
>>>
>>> Questions:
>>> Can I UNrevoke that key?
>>> How can I see what is on the smartcard?
>>> How can I copy files to the smartcard?
>>>
>>> I studied the GnuPG Smartcard How-To
>>> (www.gnupg.org/howtos/card-howto/en/smartcard-howto.html), but that is
>>> entirely linux oriented.
>>> I am working on a win7 system.
>>>
>>> Can anyone help me further?
>>>
>>> Thanks!
>>>
>>> Roland
>>
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users


-- 
https://metacode.biz/@wiktor


From Roman.Fiedler at ait.ac.at  Tue Sep  4 13:55:01 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 4 Sep 2018 11:55:01 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@digitalbrains.com>
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
 <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@digitalbrains.com>
Message-ID: <86b846d748cc4a8498567c6d814fb713@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at 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,
- at c               2008, 2009, 2010 Free Software Foundation, Inc.
+ at 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
- at option{--no-default-keyring}.
+ at 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
+ at 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>


From peter at digitalbrains.com  Tue Sep  4 15:22:57 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 15:22:57 +0200
Subject: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <86b846d748cc4a8498567c6d814fb713@ait.ac.at>
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
 <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@digitalbrains.com>
 <86b846d748cc4a8498567c6d814fb713@ait.ac.at>
Message-ID: <2d8ce8a7-2c57-2716-0890-5682c672a874@digitalbrains.com>

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/0d69a05a/attachment.sig>

From peter at digitalbrains.com  Tue Sep  4 15:39:12 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 15:39:12 +0200
Subject: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
Message-ID: <ff304af5-b75c-e64a-0b4e-29ff182742a6@digitalbrains.com>

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/699436f0/attachment.sig>

From peter at digitalbrains.com  Tue Sep  4 15:41:40 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 15:41:40 +0200
Subject: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <2d8ce8a7-2c57-2716-0890-5682c672a874@digitalbrains.com>
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
 <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@digitalbrains.com>
 <86b846d748cc4a8498567c6d814fb713@ait.ac.at>
 <2d8ce8a7-2c57-2716-0890-5682c672a874@digitalbrains.com>
Message-ID: <21a3d9ad-cb53-7925-ba59-1e25c8dbcd0b@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.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/7f3be3c2/attachment.sig>

From Roman.Fiedler at ait.ac.at  Tue Sep  4 16:08:08 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 4 Sep 2018 14:08:08 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <21a3d9ad-cb53-7925-ba59-1e25c8dbcd0b@digitalbrains.com>
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
 <cbf9b33c-dd4e-1268-0ab7-89cf9900e2d2@digitalbrains.com>
 <86b846d748cc4a8498567c6d814fb713@ait.ac.at>
 <2d8ce8a7-2c57-2716-0890-5682c672a874@digitalbrains.com>
 <21a3d9ad-cb53-7925-ba59-1e25c8dbcd0b@digitalbrains.com>
Message-ID: <5cee0503e32049259f36faaf2d62dfd7@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at 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.

From wk at gnupg.org  Tue Sep  4 15:12:30 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Sep 2018 15:12:30 +0200
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <2669076f402241d6be36b5605049c8f4@ait.ac.at> (Fiedler Roman's
 message of "Tue, 4 Sep 2018 07:52:33 +0000")
References: <2669076f402241d6be36b5605049c8f4@ait.ac.at>
Message-ID: <87ftypcsox.fsf@wheatstone.g10code.de>

On Tue,  4 Sep 2018 09:52, Roman.Fiedler at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/c5967f9f/attachment.sig>

From wk at gnupg.org  Tue Sep  4 15:07:30 2018
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Sep 2018 15:07:30 +0200
Subject: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
 failed: IPC call has been cancelled"
In-Reply-To: <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at> (Fiedler Roman's
 message of "Tue, 4 Sep 2018 08:08:48 +0000")
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
Message-ID: <87k1o1csx9.fsf@wheatstone.g10code.de>

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/0c7ccc2b/attachment.sig>

From dkg at fifthhorseman.net  Tue Sep  4 18:10:23 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 04 Sep 2018 12:10:23 -0400
Subject: Issue with pinentry GUI agent
In-Reply-To: <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
Message-ID: <87tvn5z1jk.fsf@fifthhorseman.net>

On Mon 2018-09-03 09:58:24 +0200, Kristian Fiskerstrand wrote:
> Just to have it mentioned, turned out this was an issue with missing
> keep-display in gpg-agent.conf, without this the Qt4/5 pinentry fail
> (although I've been told it is not an issue in KDE environment).

to be clear, keep-display means that all requests made to the agent that
require interaction with X11 will show up on the original display that
the agent was started with.  This isn't desirable in all cases
(e.g. where an agent is shared across multiple X11 displays)

> gpg-agent without keep-display still seems to send display as argument
> in --display :0 style, but this does not seem to be honored.

i think you're saying that "pinentry-qt --display :124" doesn't honor
the "--display :124" argument, but that doesn't seem to be true to me
with pinentry 1.1.0:

    0 dkg at alice:~$ pinentry-qt --display :124
    qt.qpa.screen: QXcbConnection: Could not connect to display :124
    Could not connect to any X display.
    1 dkg at alice:~$ 

or do you mean something else?

   --dkg


From Roman.Fiedler at ait.ac.at  Tue Sep  4 18:31:25 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Tue, 4 Sep 2018 16:31:25 +0000
Subject: AW: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
 failed: IPC call has been cancelled"
In-Reply-To: <87k1o1csx9.fsf@wheatstone.g10code.de>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
Message-ID: <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>

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

From peter at digitalbrains.com  Tue Sep  4 22:56:28 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Sep 2018 22:56:28 +0200
Subject: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
Message-ID: <95abe967-dd48-6b21-dd44-76fa814a234b@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. 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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180904/57e154cc/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Sep  5 09:39:31 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 5 Sep 2018 09:39:31 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <87tvn5z1jk.fsf@fifthhorseman.net>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
Message-ID: <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>

On 9/4/18 6:10 PM, Daniel Kahn Gillmor wrote:
> or do you mean something else?

without DISPLAY env var, qt version automatically falls back to curses
variant despite the argument

kristianf at ares ~ $ unset DISPLAY
kristianf at ares ~ $ /usr/bin/pinentry-qt4 --display :0

(pinentry-qt4:6370): Gtk-WARNING **: 09:31:41.576: cannot open display:
kristianf at ares ~ $ export DISPLAY=:0
kristianf at ares ~ $ /usr/bin/pinentry-qt4 --display :0
OK Pleased to meet you

throwing in a simple wrapper around pinentry,
#!/bin/bash
env > /tmp/pinentry-log.txt
echo "$@" >> /tmp/pinentry-log.txt
exec /usr/bin/pinentry-qt "$@"

and diffing the log between keep-display, shows that the difference is
+DISPLAY=:0

btw, you say started, but this should also be updated when issuing
UPDATESTARTUPTTY shouldn't it? In any case, it solved the issue for the
user and I replicated it also on pinentry 1.1.0 on gnupg 2.2.10

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Credo quia absurdum
I believe it because it is absurd

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/1bbf05fc/attachment-0001.sig>

From Roman.Fiedler at ait.ac.at  Wed Sep  5 10:01:40 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 08:01:40 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
Message-ID: <22ebf717f819499c9a18cfa4ce505fd2@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at 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.

From Roman.Fiedler at ait.ac.at  Wed Sep  5 10:45:02 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 08:45:02 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
In-Reply-To: <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
Message-ID: <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>


> Von: Peter Lebbing [mailto:peter at 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"

From wk at gnupg.org  Wed Sep  5 10:59:13 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 05 Sep 2018 10:59:13 +0200
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at> (Fiedler Roman's
 message of "Wed, 5 Sep 2018 08:45:02 +0000")
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
 <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>
Message-ID: <8736uo9v6m.fsf@wheatstone.g10code.de>

On Wed,  5 Sep 2018 10:45, Roman.Fiedler at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/d594ab6d/attachment.sig>

From wk at gnupg.org  Wed Sep  5 11:02:43 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 05 Sep 2018 11:02:43 +0200
Subject: AW: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
 failed: IPC call has been cancelled"
In-Reply-To: <df9c2738d33549ef865500c058d6cbdd@ait.ac.at> (Fiedler Roman's
 message of "Tue, 4 Sep 2018 16:31:25 +0000")
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
Message-ID: <87y3cg8ggc.fsf@wheatstone.g10code.de>

On Tue,  4 Sep 2018 18:31, Roman.Fiedler at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/dfec904f/attachment.sig>

From Roman.Fiedler at ait.ac.at  Wed Sep  5 11:27:52 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 09:27:52 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
Message-ID: <bec7b2e0afcf48ae95a3835fbb625504@ait.ac.at>

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

From Roman.Fiedler at ait.ac.at  Wed Sep  5 11:35:34 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 09:35:34 +0000
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC
 call has been cancelled"
Message-ID: <69689f064e324421b7f5c9f7e8b7172d@ait.ac.at>

> Von: Werner Koch [mailto:wk at gnupg.org]
> 
> On Wed,  5 Sep 2018 10:45, Roman.Fiedler at 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


From peter at digitalbrains.com  Wed Sep  5 12:18:06 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 12:18:06 +0200
Subject: Hiding signature identification (was: How to fix "ERROR key_generate
 3355453" / "GENKEY' failed: IPC call has been cancelled")
In-Reply-To: <bec7b2e0afcf48ae95a3835fbb625504@ait.ac.at>
References: <bec7b2e0afcf48ae95a3835fbb625504@ait.ac.at>
Message-ID: <41cc1c2f-7cd8-a7a2-9c5d-5686e669adc3@digitalbrains.com>

On 05/09/18 11:27, Fiedler Roman wrote:
> Sorry, but you are completely off here.

If there are six people I am actually interested in, and I know all
their public keys, checking if one of them signed a message with a
hypothetical "throw-keyid" takes me at most six trial verifications,
using their public keys in turn.

Now when you say that you could find the signer by brute-forcing "all
keys in the 2^2048 key space", that seems to miss a vital step. Let's
suppose you did this massive brute force, the universe still exists, and
you found that the RSA key with keygrip
8FE036329129F568D5B58A88F6F8580A064E4887 has signed the message. Back to
your goal. Who signed the message? You don't know. You know what the RSA
modulus of the key of this person is, but you don't know their identity,
because your brute-force search did not produce an identity, it produced
an RSA modulus and exponent.

So: to know who signed a message, you need their public key. So to check
a random signature without identification, you try all the public keys
you have at your disposal (perhaps ignoring the ones you know are
uninteresting). So your search space is your collection of public keys.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/6317ec30/attachment-0001.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Sep  5 12:33:37 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 5 Sep 2018 12:33:37 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
Message-ID: <020fa8c0-4659-5ac8-147e-8b76706df65f@sumptuouscapital.com>

On 9/5/18 9:39 AM, Kristian Fiskerstrand wrote:
> without DISPLAY env var, qt version automatically falls back to curses
> variant despite the argument

Wrote too quickly there; This is actually wrong, it never actually falls
back to curses, it just fails.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Quidquid latine dictum sit, altum videtur.
Anything said in Latin sounds profound

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/febf3b54/attachment.sig>

From Roman.Fiedler at ait.ac.at  Wed Sep  5 13:00:34 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 11:00:34 +0000
Subject: AW: Hiding signature identification (was: How to fix "ERROR
 key_generate 3355453" / "GENKEY' failed: IPC call has been cancelled")
In-Reply-To: <41cc1c2f-7cd8-a7a2-9c5d-5686e669adc3@digitalbrains.com>
References: <bec7b2e0afcf48ae95a3835fbb625504@ait.ac.at>
 <41cc1c2f-7cd8-a7a2-9c5d-5686e669adc3@digitalbrains.com>
Message-ID: <0e99692c439d4defafdd7fb0b12fe6b3@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at digitalbrains.com]
> 
> On 05/09/18 11:27, Fiedler Roman wrote:
> > Sorry, but you are completely off here.
> 
> If there are six people I am actually interested in, and I know all
> their public keys,

How will you know them? I will not tell you the keys, nor publish
them. You will have to steal them or wait for GPG leaking information
about them. The later risk is what I want to prevent ...

> checking if one of them signed a message with a
> hypothetical "throw-keyid" takes me at most six trial verifications,
> using their public keys in turn.

Nope, because as stated by Werner: signature verification in sign
AND encrypt schemes is not possible without decrypting the message.
And each message WILL BE encrypted, the sender and receiver key
will be stored in a HSM in the end. So I could not even give you a
copy of the private key to perform the decryption/signature
verification, even if I wanted to.

And to make it harder for you to figure out, which HSM to steal if
you want to decrypt a given message, the messages must not give
you any clue about the sender/receiver.
 
> Now when you say that you could find the signer by brute-forcing "all
> keys in the 2^2048 key space", that seems to miss a vital step. Let's
> suppose you did this massive brute force, the universe still exists, and
> you found that the RSA key with keygrip
> 8FE036329129F568D5B58A88F6F8580A064E4887 has signed the message.
> Back to your goal. Who signed the message? You don't know. You know what the RSA
> modulus of the key of this person is, but you don't know their identity,
> because your brute-force search did not produce an identity, it produced
> an RSA modulus and exponent.

But now I can go through my archive of intercepted messages, where I usually
know, where I intercepted them, e.g. at the hacked switch of company X.
I will check the timestamps of the messages, try to figure out the originators
working hours, check with my surveillance cameras from the other side of
the street pointing at the company X parking lot until I am quite sure, which
car and hence which person is related to activity with a given key.

As soon as I have that information, I guess 40kUSD should be sufficient
to have child, wife, whatsoever kidnapped to make the employee turn
me over the HSM with his private key plus the HSM password or decrypt
messages for me in case of stationary HSMs - thus breaking an "unbreakable"
cryptosystem with quite little amount of money (the kidnapping and one
year of switch-cyberop plus passive surveillance operation on the parking
lot) compared to really factorizing moduli or exploiting crypto software/
hardware bugs.

Maybe some criminals or secret services know better ways to perform
that task, maybe such operation is much more complicated than I
currently envision. At least by best practice use of cryptosystems, I
do not want to make them even think about such a scheme to begin
with.

> So: to know who signed a message, you need their public key. 

... and the receiver private key for sign AND encrypt schemes ...

> So to check
> a random signature without identification, you try all the public keys
> you have at your disposal (perhaps ignoring the ones you know are
> uninteresting). So your search space is your collection of public keys.

The crypto design is done in such a way, so that there is NO easily accessible
collection of public keys. I am even trying to extend it in a way, that even
have a plaintext list of all relevant remote party public keys - they only can
locate a remote party key after receiving a message and decrypting it without
verification to do the verification in a second step (that's why my attempt
to verify an encrypted message) before crafting a response, encrypting it
with the now known public key and forgetting about the key until the next
message is received.

So without massive theft of multiple physical components plus an intercept
of a significant amount of messages, access to the private keys, there is NO
WAY to gain any information about the set of used public or private keys.

Regards,
Roman

From peter at digitalbrains.com  Wed Sep  5 13:56:21 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 13:56:21 +0200
Subject: Hiding signature identification
In-Reply-To: <0e99692c439d4defafdd7fb0b12fe6b3@ait.ac.at>
References: <bec7b2e0afcf48ae95a3835fbb625504@ait.ac.at>
 <41cc1c2f-7cd8-a7a2-9c5d-5686e669adc3@digitalbrains.com>
 <0e99692c439d4defafdd7fb0b12fe6b3@ait.ac.at>
Message-ID: <3a7feef3-ee2c-6826-55ed-cd7a7dce7f66@digitalbrains.com>

What does an unencrypted, signed message mean to you? Because when we're
talking about the benefits or operation model of a hypothetical
"throw-keyid" option for signatures, that's what we are discussing.
Anything about encrypted messages is not relevant, since the signature
is inside the encryption as you noted. So the actual content of the data
is already deemed not to be sensitive knowledge, it just needs to be
authenticated.

Your method of correlating key ID's to out-of-band data like spying on
people's movements is something I had not considered, but the key ID is
just a bit of extra data; you could also simply correlate the production
of *an* OpenPGP signed message to the person in question and attack
them. Who cares what key they used when you can determine they are the
person who's always behind their keyboard when that interesting signed
message appears.

Furthermore, note that the design of OpenPGP assumes the data it calls
"public" is indeed public. You could try to retrofit OpenPGP into some
role where a public key is not public, but it is dangerous to use a
crypto ecosystem for something else than it was designed for. It seems
to me asking for a "throw-keyid" for signatures is exactly that, and
maybe you need to look for something else than OpenPGP if public data is
no longer public.[1]

As soon as the public key is indeed public, you've just reduced the
search space to all public keys rather than all possible public keys. I
don't particularly care if there is a meaningful user ID on the key,
that's up to the creator of the key, but it is relevant that the actual
modulus is indeed public knowledge.

HTH,

Peter.

[1] I made a typo and wrote "and pubic data is no longer public". My
pubic data would be among the least public data about me, thank you very
much :-).

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/e944623d/attachment.sig>

From peter at digitalbrains.com  Wed Sep  5 14:38:38 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 14:38:38 +0200
Subject: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
 <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>
Message-ID: <7f65628d-88a9-17ec-538b-f25eed0d3274@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>

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/df2edf1b/attachment-0001.sig>

From peter at digitalbrains.com  Wed Sep  5 15:20:30 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 15:20:30 +0200
Subject: Both correct and surprising non-interactive gen-key (was: How to fix
 "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been
 cancelled")
In-Reply-To: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
Message-ID: <37a21c51-7885-64d8-ae29-4e5c13dc4048@digitalbrains.com>

On 31/08/18 19:11, Fiedler Roman wrote:
> ['/usr/bin/gpg', '--homedir', '/tmp/tmp-3abk6l8', '--with-colons', '--status-fd', '2', '--pinentry-mode', 'loopback', '--batch', '--gen-key', '--command-fd', '0']

It is unclear where the passphrase is supposed to come from... so I 
think it's correct that GnuPG CANcels. Oh, by the way, commands should 
come last for robustness.

I discovered something odd though:

--8<---------------cut here---------------start------------->8---
$ cat passphrase 
my_passphrase
$ cat template 
%echo Generating key
Key-Type: RSA
Key-Length: 1024
Subkey-Type: ELG-E
Subkey-Length: 1024
Name-Real: AutomationKey
Expire-Date: 0
%commit
$ exec 3<&- 3<passphrase 
$ cat template|gpg --with-colons --status-fd 2 --pinentry-mode loopback --batch --command-fd 0 --passphrase-fd 3 --gen-key
gpg: Generating key
gpg: key EC343B15345F4B66 marked as ultimately trusted
[GNUPG:] KEY_CONSIDERED 4B3A993572D5ED206D240D91EC343B15345F4B66 0
gpg: revocation certificate stored as '/home/peter/.gnupg/openpgp-revocs.d/4B3A993572D5ED206D240D91EC343B15345F4B66.rev'
[GNUPG:] KEY_CREATED B 4B3A993572D5ED206D240D91EC343B15345F4B66
--8<---------------cut here---------------end--------------->8---

That works, with passphrase on fd 3 and command on fd 0. I should delete 
it though, "ultimately trusted" no thanks. But:

--8<---------------cut here---------------start------------->8---
$ exec 3<&- 3<template
$ cat passphrase|gpg --with-colons --status-fd 2 --pinentry-mode loopback --batch --command-fd 3 --passphrase-fd 0 --gen-key
$ 
--8<---------------cut here---------------end--------------->8---

Doesn't do anything.

--8<---------------cut here---------------start------------->8---
$ exec 3<&- 3<template
$ cat passphrase|gpg --with-colons --status-fd 2 --pinentry-mode loopback --batch --command-fd 3 --gen-key
gpg: -:1: missing colon
$ 
--8<---------------cut here---------------end--------------->8---

g10/keygen.c appears to be trying to read commands from fd 0 even though 
I said fd 3. There's no colon in the "command" my_passphrase, so it 
errors.

For now, I'd say go with the one that works. But I don't understand why 
the others behave as they do.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/5d7c9d33/attachment.sig>

From Roman.Fiedler at ait.ac.at  Wed Sep  5 15:50:22 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 13:50:22 +0000
Subject: AW: Both correct and surprising non-interactive gen-key (was: How to
 fix "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been
 cancelled")
In-Reply-To: <37a21c51-7885-64d8-ae29-4e5c13dc4048@digitalbrains.com>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <37a21c51-7885-64d8-ae29-4e5c13dc4048@digitalbrains.com>
Message-ID: <1bb2e1dfec344d4c9ab38567852a22b5@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at digitalbrains.com]
> Gesendet: Mittwoch, 5. September 2018 15:21
> An: Fiedler Roman <Roman.Fiedler at ait.ac.at>; gnupg-users at gnupg.org
> Betreff: Both correct and surprising non-interactive gen-key (was: How to fix
> "ERROR key_generate 3355453" / "GENKEY' failed: IPC call has been
> cancelled")
>
> On 31/08/18 19:11, Fiedler Roman wrote:
> > ['/usr/bin/gpg', '--homedir', '/tmp/tmp-3abk6l8', '--with-colons', '--status-fd',
> '2', '--pinentry-mode', 'loopback', '--batch', '--gen-key', '--command-fd', '0']
>
> It is unclear where the passphrase is supposed to come from... so I
> think it's correct that GnuPG CANcels. Oh, by the way, commands should
> come last for robustness.

Just for clarification:

The "--pinentry-mode" is here only to make gpg-agent/gpg2 happy to get rid
of tty-related errors. The batch commands do not request any passphrase
to be set, so it should never be read - but maybe I do understand "batch-mode"
the same way (consequence: never ask anything) compared to the gpg-meaning
of batch.

@Peter: thanks for looking at it more closely. There might be quite some sleeping
dogs in semi/fully-automated gpg2 operation.

> ...

Regards,
Roman

From peter at digitalbrains.com  Wed Sep  5 16:05:55 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 16:05:55 +0200
Subject: AW: Both correct and surprising non-interactive gen-key
In-Reply-To: <1bb2e1dfec344d4c9ab38567852a22b5@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <37a21c51-7885-64d8-ae29-4e5c13dc4048@digitalbrains.com>
 <1bb2e1dfec344d4c9ab38567852a22b5@ait.ac.at>
Message-ID: <07702266-d38b-6295-b289-dd45120225f4@digitalbrains.com>

On 05/09/18 15:50, Fiedler Roman wrote:
> The "--pinentry-mode" is here only to make gpg-agent/gpg2 happy to get rid
> of tty-related errors. The batch commands do not request any passphrase
> to be set, so it should never be read

Can you point to the documentation where it says so? Because the
passphrase is correctly set to "my_passphrase", pinentry-mode should
only ever become relevant when a pinentry is about to invoked, and in
general I just don't see why this should be the case. Additionally, it
makes no sense that there is a "%no-protection" option if this is always
the case anyway. I think that GnuPG 1.4 defaulted to no passphrase if
not supplied with a "Passphrase" option, but this is not GnuPG 1.4; the
"Passphrase" option is a no-op, included only for backwards compatibility.

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/89ee348a/attachment.sig>

From peter at digitalbrains.com  Wed Sep  5 16:10:48 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 16:10:48 +0200
Subject: AW: Both correct and surprising non-interactive gen-key
In-Reply-To: <1bb2e1dfec344d4c9ab38567852a22b5@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <37a21c51-7885-64d8-ae29-4e5c13dc4048@digitalbrains.com>
 <1bb2e1dfec344d4c9ab38567852a22b5@ait.ac.at>
Message-ID: <de657bea-9c72-e386-f862-9a6b60940c3e@digitalbrains.com>

On 05/09/18 15:50, Fiedler Roman wrote:
> @Peter: thanks for looking at it more closely. There might be quite some sleeping
> dogs in semi/fully-automated gpg2 operation.

It's just one bug, if even, depending on my understanding of the
mechanism. One swallow does not a summer make; such negativity.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/3e3985fd/attachment.sig>

From Roman.Fiedler at ait.ac.at  Wed Sep  5 16:29:16 2018
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Wed, 5 Sep 2018 14:29:16 +0000
Subject: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY' failed:
 IPC call has been cancelled"
In-Reply-To: <7f65628d-88a9-17ec-538b-f25eed0d3274@digitalbrains.com>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
 <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>
 <7f65628d-88a9-17ec-538b-f25eed0d3274@digitalbrains.com>
Message-ID: <f4f68375c82a4d538a17a5c03ad53c66@ait.ac.at>

> Von: Peter Lebbing [mailto:peter at 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

From peter at digitalbrains.com  Wed Sep  5 16:31:22 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 5 Sep 2018 16:31:22 +0200
Subject: AW: AW: How to fix "ERROR key_generate 3355453" / "GENKEY'
 failed: IPC call has been cancelled"
In-Reply-To: <f4f68375c82a4d538a17a5c03ad53c66@ait.ac.at>
References: <874899396fd84b039af389d00ac65fb4@ait.ac.at>
 <e1f1ad2117174f67aef90cbb0f9beee5@ait.ac.at>
 <3d3aeb04-20d4-0b5c-602f-ce7e498ada0c@digitalbrains.com>
 <87bm9dg62f.fsf@wheatstone.g10code.de>
 <12fdd8ecaf8c4a169fd96440676dd05b@ait.ac.at>
 <87k1o1csx9.fsf@wheatstone.g10code.de>
 <df9c2738d33549ef865500c058d6cbdd@ait.ac.at>
 <95abe967-dd48-6b21-dd44-76fa814a234b@digitalbrains.com>
 <49dd5f90a8d04a218c1b20fc7e743ec0@ait.ac.at>
 <7f65628d-88a9-17ec-538b-f25eed0d3274@digitalbrains.com>
 <f4f68375c82a4d538a17a5c03ad53c66@ait.ac.at>
Message-ID: <de2fc7d4-071f-f14b-88d0-aa74f70bf6e4@digitalbrains.com>

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/29ba2b24/attachment-0001.sig>

From dkg at fifthhorseman.net  Wed Sep  5 16:20:59 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 05 Sep 2018 10:20:59 -0400
Subject: Issue with pinentry GUI agent
In-Reply-To: <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
Message-ID: <87ftyoyqic.fsf@fifthhorseman.net>

On Wed 2018-09-05 09:39:31 +0200, Kristian Fiskerstrand wrote:
> On 9/4/18 6:10 PM, Daniel Kahn Gillmor wrote:
>> or do you mean something else?
>
> without DISPLAY env var, qt version automatically falls back to curses
> variant despite the argument
>
> kristianf at ares ~ $ unset DISPLAY
> kristianf at ares ~ $ /usr/bin/pinentry-qt4 --display :0
>
> (pinentry-qt4:6370): Gtk-WARNING **: 09:31:41.576: cannot open display:
> kristianf at ares ~ $ export DISPLAY=:0
> kristianf at ares ~ $ /usr/bin/pinentry-qt4 --display :0
> OK Pleased to meet you
>
> throwing in a simple wrapper around pinentry,
> #!/bin/bash
> env > /tmp/pinentry-log.txt
> echo "$@" >> /tmp/pinentry-log.txt
> exec /usr/bin/pinentry-qt "$@"
>
> and diffing the log between keep-display, shows that the difference is
> +DISPLAY=:0
>
> btw, you say started, but this should also be updated when issuing
> UPDATESTARTUPTTY shouldn't it? In any case, it solved the issue for the
> user and I replicated it also on pinentry 1.1.0 on gnupg 2.2.10

I'm unable to replicate this.  here's a transcript of my session,
testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
testing/unstable:


0 dkg at alice:~$ DISPLAY= pinentry-qt 
OK Pleased to meet you
getpin
D monkey
OK
0 dkg at alice:~$ DISPLAY= pinentry-qt --display :0
OK Pleased to meet you
getpin
D monkey
OK
0 dkg at alice:~$ unset DISPLAY
0 dkg at alice:~$ pinentry-qt --display :0
OK Pleased to meet you
getpin 
D abc123
OK
0 dkg at alice:~$ pinentry-qt 
OK Pleased to meet you
getpin
D abc123
OK
0 dkg at alice:~$ 

The two entries with --display caused a graphical display to pop up.
the other two caused the curses fallback.

if you can sort out a clearer replication, please report it on
https://dev.gnupg.org/maniphest/task/edit/form/3/ !

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180905/a6716f32/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Fri Sep  7 14:31:16 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 7 Sep 2018 14:31:16 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <87ftyoyqic.fsf@fifthhorseman.net>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
 <87ftyoyqic.fsf@fifthhorseman.net>
Message-ID: <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>

On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote:
> I'm unable to replicate this.  here's a transcript of my session,
> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
> testing/unstable:

which desktop manager / window manager? I can replicate on cleanly
installed debian testing with Cinnamon selected during install.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"If you cannot convince them, confuse them"
(Harry S Truman)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180907/e50f57c6/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Fri Sep  7 19:30:58 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 7 Sep 2018 19:30:58 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
 <87ftyoyqic.fsf@fifthhorseman.net>
 <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
Message-ID: <77f1eb07-9f16-64a6-f209-f6a33c751ff3@sumptuouscapital.com>

On 9/7/18 2:31 PM, Kristian Fiskerstrand wrote:
> On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote:
>> I'm unable to replicate this.  here's a transcript of my session,
>> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
>> testing/unstable:
> 
> which desktop manager / window manager? I can replicate on cleanly
> installed debian testing with Cinnamon selected during install.
> 

Done some more testing on debian unstable, and it is similar to what we
see in Gentoo;

 1 Gnome: works
 2 xfce: fails
 3 KDE: works
 4 Cinnamon: fails

(the initial bug report prompting my interest was from xfce)

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"In politics stupidity is not a handicap."
(Napoleon Bonaparte)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180907/5a084afe/attachment.sig>

From dkg at fifthhorseman.net  Fri Sep  7 21:19:34 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 07 Sep 2018 15:19:34 -0400
Subject: Issue with pinentry GUI agent
In-Reply-To: <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
 <87ftyoyqic.fsf@fifthhorseman.net>
 <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
Message-ID: <87y3cd3yk9.fsf@fifthhorseman.net>

On Fri 2018-09-07 14:31:16 +0200, Kristian Fiskerstrand wrote:
> On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote:
>> I'm unable to replicate this.  here's a transcript of my session,
>> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
>> testing/unstable:
>
> which desktop manager / window manager? I can replicate on cleanly
> installed debian testing with Cinnamon selected during install.

i wasn't testing on a full-blown desktop environment -- my test
environment was openbox, plus a typical dbus-user-session arrangement,
and a systemd --user manager connected to the session.  (not that i
think any of that is likely to matter for testing pinentry-qt itself).

      --dkg


From kristian.fiskerstrand at sumptuouscapital.com  Fri Sep  7 22:23:11 2018
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Fri, 7 Sep 2018 22:23:11 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <87y3cd3yk9.fsf@fifthhorseman.net>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
 <87ftyoyqic.fsf@fifthhorseman.net>
 <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
 <87y3cd3yk9.fsf@fifthhorseman.net>
Message-ID: <808c5b38-d451-f01a-8895-2d2a943ee2bd@sumptuouscapital.com>

On 9/7/18 9:19 PM, Daniel Kahn Gillmor wrote:
> On Fri 2018-09-07 14:31:16 +0200, Kristian Fiskerstrand wrote:
>> On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote:
>>> I'm unable to replicate this.  here's a transcript of my session,
>>> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
>>> testing/unstable:
>>
>> which desktop manager / window manager? I can replicate on cleanly
>> installed debian testing with Cinnamon selected during install.
> 
> i wasn't testing on a full-blown desktop environment -- my test
> environment was openbox, plus a typical dbus-user-session arrangement,
> and a systemd --user manager connected to the session.  (not that i
> think any of that is likely to matter for testing pinentry-qt itself).

Well, none of my systems ever touches systemd, so should never say never
when it comes to potential conflicts :) But in this case it seems like a
broader issue that at least is present in xfce and cinnamon window
managers when DISPLAY is not present.


-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"We can only see a short distance ahead, but we can see plenty there
that needs to be done."
(Alan Turing)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180907/763866d9/attachment-0001.sig>

From sunrises at gmx.com  Sat Sep  8 10:48:28 2018
From: sunrises at gmx.com (sunrises at gmx.com)
Date: Sat, 8 Sep 2018 10:48:28 +0200
Subject: Issue with pinentry GUI agent
In-Reply-To: <87y3cd3yk9.fsf@fifthhorseman.net>
References: <20180825081848.43e260fa@black> <87mut65p22.fsf@fifthhorseman.net>
 <4b4d861e-33c6-b3eb-e17f-8f69818ef486@sumptuouscapital.com>
 <f27c84dd-5a49-6eb0-75ae-f9a2b47b3e54@sumptuouscapital.com>
 <87tvn5z1jk.fsf@fifthhorseman.net>
 <17e0732c-1f9e-bcaa-dd24-b9a75d33df92@sumptuouscapital.com>
 <87ftyoyqic.fsf@fifthhorseman.net>
 <366d028e-814e-2f0a-055a-b99670dd6362@sumptuouscapital.com>
 <87y3cd3yk9.fsf@fifthhorseman.net>
Message-ID: <20180908104828.07b7e4e9@black>

On Fri, 07 Sep 2018 15:19:34 -0400
Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On Fri 2018-09-07 14:31:16 +0200, Kristian Fiskerstrand wrote:
> > On 9/5/18 4:20 PM, Daniel Kahn Gillmor wrote:  
> >> I'm unable to replicate this.  here's a transcript of my session,
> >> testing pinentry-qt 1.1.0-1+b1 and gnupg 2.2.10-1 on debian
> >> testing/unstable:  
> >
> > which desktop manager / window manager? I can replicate on cleanly
> > installed debian testing with Cinnamon selected during install.  

I've been reproducing that on openbox WM


From schmtzway at yahoo.com  Wed Sep 12 21:25:02 2018
From: schmtzway at yahoo.com (wayne schlemitz)
Date: Wed, 12 Sep 2018 19:25:02 +0000 (UTC)
Subject: aes-mode, RSA
References: <940215159.4222611.1536780302544.ref@mail.yahoo.com>
Message-ID: <940215159.4222611.1536780302544@mail.yahoo.com>

I have heard that gnupg for aes256 uses cbc mode is this correct and would like to know the command line to send a key by RSA 2056 or higher. Thank you.
Wayneschmtzway at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180912/ad15a243/attachment.html>

From rjh at sixdemonbag.org  Thu Sep 13 01:25:30 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 12 Sep 2018 19:25:30 -0400
Subject: aes-mode, RSA
In-Reply-To: <940215159.4222611.1536780302544@mail.yahoo.com>
References: <940215159.4222611.1536780302544.ref@mail.yahoo.com>
 <940215159.4222611.1536780302544@mail.yahoo.com>
Message-ID: <40067c0b-8977-5578-f056-01c85e7841f7@sixdemonbag.org>

> I have heard that gnupg for aes256 uses cbc mode is this correct

No.  GnuPG uses a version of CFB mode.  CBC mode is not part of the spec.

> would like to know the command line to send a key by RSA 2056 or higher.

If your recipient's primary encryption subkey is RSA-2056 or higher,
congratulations, you're done.


From rjh at sixdemonbag.org  Thu Sep 13 21:41:58 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 13 Sep 2018 15:41:58 -0400
Subject: aes-mode, RSA
In-Reply-To: <40067c0b-8977-5578-f056-01c85e7841f7@sixdemonbag.org>
References: <940215159.4222611.1536780302544.ref@mail.yahoo.com>
 <940215159.4222611.1536780302544@mail.yahoo.com>
 <40067c0b-8977-5578-f056-01c85e7841f7@sixdemonbag.org>
Message-ID: <7132a94b-f224-815a-5eaa-e20219c599fb@sixdemonbag.org>

Wayne asked me off-list how to ensure RSA-2056 or greater was being used.

First, it's a little weird: normally we talk of RSA-2048, not -2056.
But never mind, the answer is the same each way.

When sending email to another person, you use their public key for the
encryption.  Your own key isn't used at all for encryption (unless you
include yourself on the recipients list).

To check a certificate, use --list-key and the ID of the certificate you
want to check.  For instance, my certificate is

=====
rjh at pop-os:~$ gpg --list-key 1DCBDC01B44427C7

pub   rsa3072/1DCBDC01B44427C7 2015-07-16 [SC]
      CC11BE7CBBED77B120F37B011DCBDC01B44427C7
uid                 [ultimate] Robert J. Hansen <rjh at sixdemonbag.org>
uid                 [ultimate] Robert J. Hansen <rob at hansen.engineering>
uid                 [ultimate] Robert J. Hansen <rob at enigmail.net>
sub   rsa3072/DC0F82625FA6AADE 2015-07-16 [E]
sub   ed25519/A83CAE94D3DC3873 2017-04-05 [S]
sub   cv25519/AA24CC81B8AED08B 2017-04-05 [E]
=====

Cut-and-paste that into a text document (Notepad, Atom, whatever).
Remove any line that doesn't start with "pub" or "sub".

=====
pub   rsa3072/1DCBDC01B44427C7 2015-07-16 [SC]
sub   rsa3072/DC0F82625FA6AADE 2015-07-16 [E]
sub   ed25519/A83CAE94D3DC3873 2017-04-05 [S]
sub   cv25519/AA24CC81B8AED08B 2017-04-05 [E]
=====

Now remove anything that doesn't end with the letter "E" somewhere in
brackets.  "[SCE]" is okay, but "[SC]" isn't.

=====
sub   rsa3072/DC0F82625FA6AADE 2015-07-16 [E]
sub   cv25519/AA24CC81B8AED08B 2017-04-05 [E]
=====

Presto.  I have two encryption subkeys.  Now look at the second column:
one starts with "rsa3072", denoting a 3072-bit RSA key.  The other,
cv25519, is an elliptical curve key -- not what you want.

By default, GnuPG will use the newest encryption subkey.  That means if
you were to type in this:

=====
rjh at pop-os:~$ gpg --recipient 1DCBDC01B44427C7 --encrypt foo.txt
=====

... GnuPG would use my cv25519 subkey, since it's the newest.  You can
override this.  To the right-hand side of my RSA key you'll see an
identifier for it, "DC0F82625FA6AADE".  To override GnuPG's choice of
subkeys, specify the specific subkey's identifier and add an exclamation
point to the end ("!").  This is how you tell GnuPG "no, really, use
this one".

=====
rjh at pop-os:~$ gpg --recipient DC0F82625FA6AADE! --encrypt foo.txt
=====

Hope this helps!


From felix.klee at inka.de  Mon Sep 17 18:44:46 2018
From: felix.klee at inka.de (Felix E. Klee)
Date: Mon, 17 Sep 2018 18:44:46 +0200
Subject: Cannot decrypt file encrypted with enQsig
In-Reply-To: <337a49a0-a9a5-9e8a-538f-e2db65430854@digitalbrains.com>
References: <CA+m_8J2=Pq__KtizxL9Tyvabu7pFtssAoOquKhKfNP-AHnKEnA@mail.gmail.com>
 <CA+m_8J1kwT=Zj5T2Fq9cgUtvmMY96MXgEyJC=cE3UdE=Z2uvHw@mail.gmail.com>
 <337a49a0-a9a5-9e8a-538f-e2db65430854@digitalbrains.com>
Message-ID: <CA+m_8J1x4GEQBooqB+pLBuq9nSWT0U0MyO46OA0uzQi9AnY5hA@mail.gmail.com>

On Wed, Aug 15, 2018 at 12:13 PM, Peter Lebbing
<peter at digitalbrains.com> wrote:
>> So, perhaps enQsig is using 3DES.
>
> Good find! This sounds plausible.

Created a custom key pair not on a smart card, just for this single
transaction. Result:

    >gpg --verbose --decrypt encrypted.asc | head
    gpg: armor header: Version: enQsig
    gpg: public key is FDE5C6E97DA42AE8
    gpg: public key is 92663E7CA68E4EC6
    gpg: public key is 9D8C454A43A6D2DE
    gpg: encrypted with RSA key, ID 9D8C454A43A6D2DE
    gpg: encrypted with RSA key, ID 92663E7CA68E4EC6
    gpg: encrypted with 4096-bit RSA key, ID FDE5C6E97DA42AE8, created
    2018-09-06
          "Felix E. Klee <felix.klee at inka.de>"
    gpg: 3DES encrypted data
    gpg: Note: sender requested "for-your-eyes-only"

So yes, 3DES!

Fortunately, as can be seen above, with the custom key I was able to
decrypt the message.

Issue solved.


From cjac at colliertech.org  Mon Sep 17 20:53:02 2018
From: cjac at colliertech.org (C.J. Collier)
Date: Mon, 17 Sep 2018 11:53:02 -0700
Subject: Washington State Electronic Notary Public endorsements
Message-ID: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>

Hello folks!

I thought I'd write you to let you know about my recent conversation with
the Washington State Department of Licensing (DoL).  In July, I submitted
my application for renewal of my Notary commission.  This year, the WA
Notary laws changed to allow notaries to request an endorsement with
renewal or initial application <https://www.dol.wa.gov/forms/659007.pdf>.
Since I have a bit of experience
<http://www.colliertech.org/state/19.34_RCW/> with non-repudiation online,
I checked the box indicating a request for Electronic Notary Public
endorsement, listed "Collier Technologies LLC / GnuPG" as my software of
choice, and sent in the extra $15.  My application was processed and my
third commission as notary was approved on August 17th.

I received in the mail a letter dated September 6th 2018, however, which
informed me that the software I indicated "does not meet the requirements
<http://apps.leg.wa.gov/wac/default.aspx?cite=308-30-130> of the enclosed
laws and rules."

The requirements indicated were:

Requirements for technologies and technology providers.
A tamper-evident technology shall comply with these rules:
(1) A technology provider shall enroll only notaries public who have been
issued an electronic records notary public endorsement pursuant to WAC
308-30-030 <http://apps.leg.wa.gov/wac/default.aspx?cite=308-30-030>.
(2) A technology provider shall take reasonable steps to ensure that a
notary public who has enrolled to use the technology has the knowledge to
use it to perform electronic notarial acts in compliance with these rules.
(3) A tamper-evident technology shall require access to the system by a
password or other secure means of authentication.
(4) A tamper-evident technology shall enable a notary public to affix the
notary's electronic signature and seal or stamp in a manner that attributes
such signature and seal or stamp to the notary.
(5) A technology provider shall provide prorated fees to align the usage
and cost of the tamper-evident technology with the term limit of the notary
public electronic records notary public endorsement.
(6) A technology provider shall suspend the use of any tamper-evident
technology for any notary public whose endorsement has been revoked,
suspended, or canceled by the state of Washington or the notary public.

This all seemed to me to be something that GnuPG is designed to do and does
quite well.  So I sent an email on Friday night to the sender of the letter
requesting specific issues that my provider did not comply with.  This
morning I received a call from the DoL, and was able to successfully argue
for GnuPG's qualification as an electronic records notary public technology
provider for the State of Washington.

In short, GnuPG can now be used to perform notarial acts
<http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
Washington!

Cheers,

C.J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180917/92100b6d/attachment-0001.html>

From felix at crowfix.com  Mon Sep 17 23:03:24 2018
From: felix at crowfix.com (Felix Finch)
Date: Mon, 17 Sep 2018 14:03:24 -0700
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
Message-ID: <20180917210324.GA2982@crowfix.com>

On Mon, Sep 17, 2018 at 11:53:02AM -0700, C.J. Collier wrote:
> This all seemed to me to be something that GnuPG is designed to do and does
> quite well.  So I sent an email on Friday night to the sender of the letter
> requesting specific issues that my provider did not comply with.  This
> morning I received a call from the DoL, and was able to successfully argue
> for GnuPG's qualification as an electronic records notary public technology
> provider for the State of Washington.
> 
> In short, GnuPG can now be used to perform notarial acts
> <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
> Washington!

Well done!  Any idea how applicable your experience will be in other states?

-- 
            ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
     Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o


From rjh at sixdemonbag.org  Mon Sep 17 23:24:48 2018
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 17 Sep 2018 17:24:48 -0400
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <20180917210324.GA2982@crowfix.com>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
 <20180917210324.GA2982@crowfix.com>
Message-ID: <a2cb5526-60fb-c34c-5449-fc7b8f6f5bcb@sixdemonbag.org>

> Any idea how applicable your experience will be in other states?

Each state will go on a case by case basis, _but_, states are required
to give full faith and credit to the proceedings of other states.



From jhs at berklix.com  Mon Sep 17 22:58:40 2018
From: jhs at berklix.com (Julian H. Stacey)
Date: Mon, 17 Sep 2018 22:58:40 +0200
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: Your message "Mon, 17 Sep 2018 11:53:02 -0700."
 <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
Message-ID: <201809172058.w8HKwehC001921@fire.js.berklix.net>

> <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
> Washington!

Nice.  Should probably be noted/ indexed on a web somewhere ?

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit Referendum stole 3.7 million votes inc. 700,000 from British in EU.
 UK Goverment lies it's democratic in Article 50 paragraph 3 of letter to EU.
 				http://exitbrexit.uk


From skquinn at rushpost.com  Mon Sep 17 23:07:22 2018
From: skquinn at rushpost.com (Shawn K. Quinn)
Date: Mon, 17 Sep 2018 16:07:22 -0500
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
Message-ID: <a6454bd2-1cb0-19f7-a0a4-fb2ca929859c@rushpost.com>

On 09/17/2018 01:53 PM, C.J. Collier wrote:
> In short, GnuPG can now be used to perform notarial acts
> <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
> Washington!

Nice work!

-- 
Shawn K. Quinn <skquinn at rushpost.com>
http://www.rantroulette.com
http://www.skqrecordquest.com


From markr at signal100.com  Tue Sep 18 08:17:55 2018
From: markr at signal100.com (Mark Rousell)
Date: Tue, 18 Sep 2018 07:17:55 +0100
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
Message-ID: <5BA09893.4040300@signal100.com>

On 17/09/2018 19:53, C.J. Collier wrote:
>
> In short, GnuPG can now be used to perform notarial acts
> <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State
> of Washington!
>

Well done!

I expect that lesser people than you would have just given up.


-- 
Mark Rousell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180918/47f9ae30/attachment.html>

From w at uter.be  Tue Sep 18 10:18:08 2018
From: w at uter.be (Wouter Verhelst)
Date: Tue, 18 Sep 2018 10:18:08 +0200
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
Message-ID: <20180918081808.GD3973@grep.be>

Hi C.J.,

On Mon, Sep 17, 2018 at 11:53:02AM -0700, C.J. Collier wrote:
> In short, GnuPG can now be used to perform notarial acts
> <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
> Washington!

Awesome!

However, if I go to that link, it shows a list of formats to be used for paper
certificates, rather than some more information on the use and acceptance of
GnuPG.

Was that a mistake?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab


From bxstover at yahoo.co.uk  Tue Sep 18 14:48:33 2018
From: bxstover at yahoo.co.uk (Ben)
Date: Tue, 18 Sep 2018 14:48:33 +0200
Subject: disable/prevent start of gpg-agent service?
Message-ID: <4831f0cf-3730-64d6-1ca3-7e95fd6211e2@yahoo.co.uk>

Asi found out after having installed the latest gnupg release on Windows 7 a gnupg service "gpg-agent" always is running (now) in background.

It seems to be installed automatically without letting the user a choice.

Can I disable this service?

Can I de-install this service permanently?

I need gnupg only occasionally for on-demand en-/de-cryption.

Thank you
Ben



From cjac at colliertech.org  Tue Sep 18 18:16:47 2018
From: cjac at colliertech.org (C.J. Collier)
Date: Tue, 18 Sep 2018 09:16:47 -0700
Subject: Washington State Electronic Notary Public endorsements
In-Reply-To: <20180918081808.GD3973@grep.be>
References: <CAJj0OutJvyGfWNpWkAF9otM=dBfX6_rCN2Gm=EUxFdYjwaqnHQ@mail.gmail.com>
 <20180918081808.GD3973@grep.be>
Message-ID: <CAJj0Outy=nyYTL3mdhhBhrUaN44frM1e7x5daJBH7oE2yCrHzg@mail.gmail.com>

Hi Wouter!

No, this was not a mistake.  There's very little documentation regarding
using electronic providers.  I expect that I will implement digital acts by
taking photographs or scans of the signed paper, --detach-sign'ing, and
distribute the two file as a .zip or .tar.gz depending on my audience.  Any
of the forms listed in 42.45.140 RCW can be "converted" to digital format
and distributed with the signature, maintaining their legal status as prima
facie evidence.

Cheers,

C.J.


On Tue, Sep 18, 2018 at 1:18 AM Wouter Verhelst <w at uter.be> wrote:

> Hi C.J.,
>
> On Mon, Sep 17, 2018 at 11:53:02AM -0700, C.J. Collier wrote:
> > In short, GnuPG can now be used to perform notarial acts
> > <http://app.leg.wa.gov/RCW/default.aspx?cite=42.45.140> in the State of
> > Washington!
>
> Awesome!
>
> However, if I go to that link, it shows a list of formats to be used for
> paper
> certificates, rather than some more information on the use and acceptance
> of
> GnuPG.
>
> Was that a mistake?
>
> --
> Could you people please use IRC like normal people?!?
>
>   -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf
> 2008
>      Hacklab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180918/0b3cdfce/attachment.html>

From fkater at posteo.net  Wed Sep 19 12:45:02 2018
From: fkater at posteo.net (Felix A. Kater)
Date: Wed, 19 Sep 2018 12:45:02 +0200
Subject: Performance regression for gnupg v2 keys
Message-ID: <20180919104502.GB426@zed>

Hi,

I have older keys and newer keys that behave quite different in the
decryption performance.

Old keys: Generated with gnupg-1.4.x, rsa2048, at 2017-01-10.
New keys: Generated with gnupg-2.2.8, rsa2048, some weeks ago.

I've always been using the defaults for generating the keys (no
--full-gen-key, no --expert).

Test case: Unfortunatelly a bit complicated. It is postgresql's
pg_pub_decrypt() that performs approx. 10x slower when the keys,
generated by gnupg and being passed to postgresql as a binary
string, are generated with gnupg-2.2.8. Postgresql is using gnupg
internally.

My questions here:

(1)
If the issue is caused by the keys: Do I have the chance to compare
old/new key internals?  I've diff'ed the output of gpg -ivv ... of
both keys and AFAIK only the default digest algo has changed from
SHA1 to SHA256. Not sure here though.

(2)
What would be a suitable test case with gpg only, without postgresql.

Thanks



From wk at gnupg.org  Thu Sep 20 10:04:45 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Sep 2018 10:04:45 +0200
Subject: disable/prevent start of gpg-agent service?
In-Reply-To: <4831f0cf-3730-64d6-1ca3-7e95fd6211e2@yahoo.co.uk> (Ben via
 Gnupg-users's message of "Tue, 18 Sep 2018 14:48:33 +0200")
References: <4831f0cf-3730-64d6-1ca3-7e95fd6211e2@yahoo.co.uk>
Message-ID: <87in30ppb6.fsf@wheatstone.g10code.de>

On Tue, 18 Sep 2018 14:48, gnupg-users at gnupg.org said:

> Can I disable this service?

No, it is an important component of gnupg.  It handles the private keys
and caches the passphrases.

> Can I de-install this service permanently?

No.

> I need gnupg only occasionally for on-demand en-/de-cryption.

If you really need to remove that process, run

  gpgconf --kill gpg-agent

it will be restarted as needed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180920/f98a3484/attachment.sig>

From fkater at posteo.net  Thu Sep 20 15:05:15 2018
From: fkater at posteo.net (Felix A. Kater)
Date: Thu, 20 Sep 2018 15:05:15 +0200
Subject: Performance regression for gnupg v2 keys
In-Reply-To: <20180919104502.GB426@zed>
References: <20180919104502.GB426@zed>
Message-ID: <20180920130514.GA946@zed>

fkater:

> Hi,
> 
> I have older keys and newer keys that behave quite different in the
> decryption performance.
> 
> Old keys: Generated with gnupg-1.4.x, rsa2048, at 2017-01-10.
> New keys: Generated with gnupg-2.2.8, rsa2048, some weeks ago.
> 
> I've always been using the defaults for generating the keys (no
> --full-gen-key, no --expert).
> 
> Test case: Unfortunatelly a bit complicated. It is postgresql's
> pg_pub_decrypt() that performs approx. 10x slower when the keys,
> generated by gnupg and being passed to postgresql as a binary
> string, are generated with gnupg-2.2.8. Postgresql is using gnupg
> internally.
> 
> My questions here:
> 
> (1)
> If the issue is caused by the keys: Do I have the chance to compare
> old/new key internals?  I've diff'ed the output of gpg -ivv ... of
> both keys and AFAIK only the default digest algo has changed from
> SHA1 to SHA256. Not sure here though.
> 
> (2)
> What would be a suitable test case with gpg only, without postgresql.


A little update:

When I change the passphrase of an existing 1.x generated key with
gpg 1.4.x, the key stays ok (fast).

When I change the passphrase of an existing 1.x generated key with
gpg 2.2.8, the key gets somehow updated (slow).

So, besides fast/slow:

What's the difference between default (rsa 2048) keys generated with
1.x and 2.x?

Felix



From wk at gnupg.org  Thu Sep 20 16:24:01 2018
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Sep 2018 16:24:01 +0200
Subject: Performance regression for gnupg v2 keys
In-Reply-To: <20180920130514.GA946@zed> (Felix A. Kater's message of "Thu, 20
 Sep 2018 15:05:15 +0200")
References: <20180919104502.GB426@zed> <20180920130514.GA946@zed>
Message-ID: <87d0t8p7r2.fsf@wheatstone.g10code.de>

On Thu, 20 Sep 2018 15:05, fkater at posteo.net said:

> When I change the passphrase of an existing 1.x generated key with
> gpg 2.2.8, the key gets somehow updated (slow).

So this is not about the key but about the protection of the private
key.  That protection (teh passphrase) is there as a failsafe mechanism
in case the private key is leaked without the machine being compromosed
(backup take lost, etc.).

We try to achieve that this decryption process takes about 100ms; that
value can be changed at build time using the configure option
--with-agent-s2k-calibration=MSEC but not at run time.  When you change
the passphrase of an old key the first time or when you import it to gpg
the key is re-encrypted so that it takes that long.

In contrast gpg 1.4 uses a fixed value here and does not calibrate it to
the actual machine in use.  The outcome is that a gpg 1.4 created/
passphrase changes key has a too weak protection in that a dictionary
attack can be more easily mounted.

It seems that you are doing a lot of operations with that key in a row.
gpg-agent's cache will cache the unprotected key so that the 100ms to
unprotect the key is only spend once during the caching time to live (10
minutes by default).  Make sure tha the cache is enabled by checking the
options --max-cache-ttl and default-cache-ttl.  Depending on your use
case you may want to work without a passphrase (key protection) at all.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180920/2a6cf7b7/attachment.sig>

From felix at crowfix.com  Thu Sep 20 17:55:56 2018
From: felix at crowfix.com (Felix Finch)
Date: Thu, 20 Sep 2018 08:55:56 -0700
Subject: Decryption timing calibration
In-Reply-To: <87d0t8p7r2.fsf@wheatstone.g10code.de>
References: <20180919104502.GB426@zed> <20180920130514.GA946@zed>
 <87d0t8p7r2.fsf@wheatstone.g10code.de>
Message-ID: <20180920155556.GC19350@crowfix.com>

On Thu, Sep 20, 2018 at 04:24:01PM +0200, Werner Koch wrote:
> We try to achieve that this decryption process takes about 100ms

That is fascinating -- I did not know that decryption was calibrated
to take a certain amount of time.  Very interesting.  I hope I haven't
misunderstood.

How much variation is there for a given calibration -- how do you
create generic canned packages for wide distribution?  Gentoo compiles
everything and could easily calibrate itself; RedHat, Debian, and most
others distribute binaries and can't.  I'd think that could lead to a
pretty wide range of decrypt times.

-- 
            ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
     Felix Finch: scarecrow repairman & wood chipper / felix at crowfix.com
  GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o


From andrewg at andrewg.com  Thu Sep 20 18:53:32 2018
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 20 Sep 2018 17:53:32 +0100
Subject: First smartcard operation always fails
In-Reply-To: <406d828f-88fd-a8b5-0f27-0098ea4371c7@digitalbrains.com>
References: <7560326c-9cc5-1cb7-a6f0-749128911335@andrewg.com>
 <63e6787f-12cb-350d-ed65-7f28a4cbc5e1@andrewg.com>
 <406d828f-88fd-a8b5-0f27-0098ea4371c7@digitalbrains.com>
Message-ID: <e656ea4a-4ba1-f502-7e48-a64b3b00324b@andrewg.com>

On 04/09/18 11:01, Peter Lebbing wrote:
> On 04/09/18 10:17, Andrew Gallagher wrote:
>> And I have just confirmed (by sending that mail) that both the first
>> auth operation AND the first signing operation fail, separately.
> 
> I have no idea, it's quite curious. As an added bread crumb to follow:
> what do the PIN retry counters say after the failure? gpg --card-status.
> 
> Do you always use the same reader? Perhaps it is the reader.

On further experimentation, it turns out it only happens with one of my
two cards, but does happen on multiple machines with multiple readers.
The signature counter increases every time. I can reproduce the sig
operation failure consistently, but not the auth operation.

Does this mean the card is unwittingly producing bad output on the first
attempt, and gpg (or scdaemon) is automatically retrying? Could this be
a manufacturing flaw in the card?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180920/e2e2b682/attachment.sig>

From fkater at posteo.net  Fri Sep 21 10:14:07 2018
From: fkater at posteo.net (Felix A. Kater)
Date: Fri, 21 Sep 2018 10:14:07 +0200
Subject: Performance regression for gnupg v2 keys
In-Reply-To: <87d0t8p7r2.fsf@wheatstone.g10code.de>
References: <20180919104502.GB426@zed> <20180920130514.GA946@zed>
 <87d0t8p7r2.fsf@wheatstone.g10code.de>
Message-ID: <20180921081407.GA774@zed>

wk:

> We try to achieve that this decryption process takes about 100ms;

Oh, I see...

> When you change the passphrase of an old key the first time or
> when you import it to gpg the key is re-encrypted so that it takes
> that long.

So, the trigger for this delay is then inherent to the re-encrypted
key itself, not primarily dependent on the agent or gnupg library
configuration, correct?

I am asking this detail because

- I need to move the keys to another machine, into a postgresql
  database where gnupg seems to be part of postgresql itself
  (pgcrypto) and cannot be hand-configured easily, and

- I'd like to know if I have to re-create all existing (slow) keys
  after applying --with-agent-s2k-calibration=MSEC to gnupg (on the
  machine where the keys are generated).

Please confirm.


> It seems that you are doing a lot of operations with that key in a row.
> gpg-agent's cache will cache the unprotected key so that the 100ms to
> unprotect the key is only spend once during the caching time to live (10
> minutes by default).  Make sure tha the cache is enabled by checking the
> options --max-cache-ttl and default-cache-ttl.  Depending on your use
> case you may want to work without a passphrase (key protection) at all.

Indeed: We do many decryptions, let me explain in short:

It is postgresql that receives passphrase protected gpg keys
(pgcrypto). Otherwise it couldn't execute SQL queries on encrypted
data. So, I am forced to move the whole decryption work to
postgresql instead of dealing with decryption after the query using
(a clean version of) gnupg. I don't know about postgresql's
internals but it doesn't seem to even run an agent... And just as an
example: A query using gnupg 1.x keys that completes within 3 sec
takes 40 sec with 2.x keys.


> that value can be changed at build time using the configure option
> --with-agent-s2k-calibration=MSEC but not at run time.  

This sounds like a suitable solution.  I've seen that option here
[1] but it is missing in official gnupg.  What do you recommend?

Felix

[1] https://dev.gnupg.org/source/gnupg/browse/master/configure.ac



From johndoe65534 at mail.com  Fri Sep 21 11:02:55 2018
From: johndoe65534 at mail.com (john doe)
Date: Fri, 21 Sep 2018 11:02:55 +0200
Subject: dirmngr cygwin resolv.conf
In-Reply-To: <41f7fd06-22b3-c2c7-b6a5-f9374072be8b@mail.com>
References: <2668e804-4468-774b-702f-62a3695e0e9a@mail.com>
 <87zhzgkw9c.fsf@wheatstone.g10code.de>
 <4b9eb287-7ef3-ff97-6838-943af8a92ca7@mail.com>
 <871scr17br.fsf@wheatstone.g10code.de>
 <5f12448e-fab6-6eba-325b-7273677cf822@mail.com>
 <87wouim4ma.fsf@iwagami.gniibe.org>
 <a9ce7f38-122a-f04d-c35e-18eddf0a6492@mail.com> <874lhln7ln.fsf@fsij.org>
 <6d5be269-6474-f829-c3d0-7bd9d278aeb0@mail.com>
 <87po06xhe6.fsf@wheatstone.g10code.de>
 <3ce5c37f-0bc7-3b69-7750-987fadd95226@mail.com>
 <87efgky80n.fsf@wheatstone.g10code.de> <87fu0zvjq0.fsf@iwagami.gniibe.org>
 <f9dea9c0-9d1b-8f9b-83a6-b31d8d2b96c6@mail.com> <87y3erfpbg.fsf@fsij.org>
 <87va9vw5kq.fsf@wheatstone.g10code.de>
 <41f7fd06-22b3-c2c7-b6a5-f9374072be8b@mail.com>
Message-ID: <1896914a-6e84-0c98-8d4f-254d57b502af@mail.com>

On 7/5/2018 12:18 PM, john doe wrote:
> On 7/4/2018 2:25 PM, Werner Koch wrote:
>> On Wed,? 4 Jul 2018 09:11, gniibe at fsij.org said:
>>
>>> The patch is: Don't try to look the error code, but fallback TOR_PORT2
>>> always.
>>
>> I don't like this patch because it is not specific enough.
>>
>> If Cygwin really returns EPERM, than this is a bug in the Cygwin
>> emulation because all Unix systems (and actually all BSD sockets based
>> systems) return ECONNREFUSED.? We should not try to fix bugs for Cygwin
>> given that Cygwin is not offically supported.
>>
> 
> What would it take to make Cygwin officially supported?
> 

Thanks to the help on this mailing list I've been able to isolate the 
issue that was bugging me:

I was trying to use the cygwinized version of dirmngr while having 
gpg4win installed.
As soon as I removed 'gpg4win, Cygwin dirmngr is able to connect to TBB 
for Windows.

So Cygwin returns the proper error code and gnupg can connect to TBB for 
Windows without issue.

On Cygwin I use git and need to verify tags and commits using gpg but I 
also use enigmail with gpg4win to verify e-mail signature.
When I need to use Cygwin dirmngr or gpg4win dirmngr, I do, 'gpgconf 
--kill dirmngr' as a work around.
Is this approatche reasonable or how can I insure that gpg4win dirmngr 
won't interfer with Cygwin dirmngr?

As an aside, gpg4win dirmngr is running as an processe.
I'd like dirmngr to use TBB for Windows instead  of Windows's DNS, is 
'gpgconf --reload dirmngr' the correct way to reload dirmngr for it to 
use TBB?

Thanks again to NIIBE Yutaka  and Werner Koch for their help.

-- 
John Doe


From peter at digitalbrains.com  Sun Sep 23 15:38:35 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 23 Sep 2018 15:38:35 +0200
Subject: Exact definition of token S/N field for --with-colons
Message-ID: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>

doc/DETAILS says this about the output of --with-colons listings:

> *** Field 15 - S/N of a token
> 
>     Used in sec/ssb to print the serial number of a token (internal
>     protect mode 1002) or a '#' if that key is a simple stub (internal
>     protect mode 1001).  If the option --with-secret is used and a
>     secret key is available for the public key, a '+' indicates this.

This suggests that a '+' is only output for --with-secret --list-keys,
but I see it as well in --list-secret-keys. Running gpg 2.1.18-8~deb9u2
from Debian stretch/stable. The specification leaves some interpretation
room.

- Is '+' output iff it is an on-disk key, both on --with-secret
  --list-keys and --list-secret-keys?
- I see S/N's on --with-secret --list-keys, is there even a need to
  mention --with-secret separately or is field 15 completely identical
  for both invocations?
- Is field 15 ever anything else than a serial number, a '#' or a '+' on
  --list-secret-keys? I presume the answer is "this may change in the
  future", but I mean currently.

The context is that for Debian's cryptsetup, I'm trying to determine
whether all secret (sub)keys in a homedir are stubs (serial numbers or
empty stubs). And the reason is that I'd like to error out if there is
any actual confidential data in the private keyring, instead of copying
it to the unencrypted initramfs. A password-protected on-disk key is a
major red flag despite its password protection.

Not all of my questions directly pertain to this use case, I'm just
trying to get a good feel for the field to be able to reason about it.

My attempt at bailing on confidential data is here:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903163#140>
and it is this:

--8<---------------cut here---------------start------------->8---
#!/bin/sh

UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
	gawk -F: '$1=="sec" || $1=="ssb" \
		{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')

if [ -n "$UNSAFEKEYS" ]; then
	echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
	exit 1
fi
--8<---------------cut here---------------end--------------->8---

It will only accept true OpenPGP smartcard keys (matched on ISO 7816
Application Identifier) or empty stubs (no secret key whatsoever). No
other secret key material should be necessary for this particular
application. Note that the dialect (or lack thereof) is dash; if run in
bash, echo would need -e.

Thanks,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180923/c8a7efbe/attachment.sig>

From peter at digitalbrains.com  Sun Sep 23 18:18:13 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 23 Sep 2018 18:18:13 +0200
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
Message-ID: <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>

Hi all,

The intent of this mail is not to ask whether something works. This can
be easily verified. It's asking whether it is a supported way of doing
things. I hope I can get some guidance on this!

On 23/09/2018 15:38, Peter Lebbing wrote: 
> The context is that for Debian's cryptsetup, I'm trying to determine
> whether all secret (sub)keys in a homedir are stubs (serial numbers or
> empty stubs). And the reason is that I'd like to error out if there is
> any actual confidential data in the private keyring, instead of copying
> it to the unencrypted initramfs. A password-protected on-disk key is a
> major red flag despite its password protection.

So this ran into a major mistake on my part. Not all keys in
private-keys-v1.d will be listed with this method, plus it launches an
agent which in this case is a no-go.

The situation with regard to which parts of the homedir are
implementation details and which are an API is a bit muddled IMHO. For
instance, we're supposed to be creating and editing *.conf files and
access revocation certificate files in openpgp-revocs.d, but a lot of
the rest is "Don't touch".

Would it be okay to scrub the private-keys-v1.d directory so it will
only hold KEYGRIP.key for that one smartcard stub we want to have? I'm
talking about a separate, special-purpose homedir, not the regular user
homedir, let's not scrub private-keys-v1.d there :-D.

That's the specific way of asking the question. A more general question
would be: in GnuPG 2.1+, can we expect the private key with grip X to be
at private-keys-v1.d/X.key and will an agent be happy to work on a
private-keys-v1.d with just files X.key, Y.key and Z.key when we
actually only need private keys X, Y and Z? Or is this an implementation
detail?

While I'm at it: there are conflicting opinions on whether it is okay to
build a keyring using:
$ gpg --export SOMEKEY >pubring.gpg
instead of:
$ gpg --export SOMEKEY | gpg --no-default-keyring --keyring ./pubring.kbx

Can we also get official guidance on that; is the former acceptable?
(FWIW, I've always thought it was not.)

Thanks!

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180923/d2b2df3d/attachment.sig>

From dkg at fifthhorseman.net  Sun Sep 23 22:19:22 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 23 Sep 2018 16:19:22 -0400
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
Message-ID: <87zhw8ge5x.fsf@fifthhorseman.net>

On Sun 2018-09-23 18:18:13 +0200, Peter Lebbing wrote:
> The intent of this mail is not to ask whether something works. This can
> be easily verified. It's asking whether it is a supported way of doing
> things. I hope I can get some guidance on this!

I appreciate that you're asking for clarification about what is the
scope of GnuPG's "API", such as it is.  We do need more clarity here.

i don't have the authority to answer your questions about the contents
of ~/.gnupg/private-keys-v1.d/, but i'd always thought that the
internals of ~/.gnupg/ were *not* part of the "API", and generally
should not be relied upon.  I hope that Werner or someone else more
closely related to the project can clarify here.

> While I'm at it: there are conflicting opinions on whether it is okay to
> build a keyring using:
> $ gpg --export SOMEKEY >pubring.gpg
> instead of:
> $ gpg --export SOMEKEY | gpg --no-default-keyring --keyring ./pubring.kbx
>
> Can we also get official guidance on that; is the former acceptable?
> (FWIW, I've always thought it was not.)

The former statement is a way to create a simple, exported OpenPGP
"transferable public key" (TPK) of the form described in RFC 4880.  This
is the most interoperable form, if you're looking to export a specific
key for transfer into any other implementation (including other versions
of GnuPG).  This is not only "acceptable" but it is normal,
standardized, and widely interoperable.

Traditionally, GnuPG keyrings have been just a linear concatenation of
TPKs interspersed with "Trust Packets".  The more modern keybox (the
default in 2.1 and going forward) is different from that format, though.

The latter statement doesn't even have a GnuPG command on the tail end
of the pipe, but i assume you intended for it to be --import.  is that
right?

In that case, it creates a keyring of whatever format the current
version of gpg uses by default.  But the real question is: why do you
need this, and what do you intend to do with it?  creating a keyring for
a specific version of GnuPG may be useful in some contexts, but it's
also pretty dicey to use in many other contexts.

Perhaps explaining what you're looking to do with this file you're
creating would help to decide whether the latter form is better for your
purpose.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180923/ffb64363/attachment.sig>

From email at andrewnesbit.org  Mon Sep 24 02:09:25 2018
From: email at andrewnesbit.org (Andrew Luke Nesbit)
Date: Mon, 24 Sep 2018 01:09:25 +0100
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <87zhw8ge5x.fsf@fifthhorseman.net>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
 <87zhw8ge5x.fsf@fifthhorseman.net>
Message-ID: <b5eda413-f7b9-4b78-8fdf-159bc3eb5bcb@andrewnesbit.org>

On 23/09/2018 21:19, Daniel Kahn Gillmor wrote:
> On Sun 2018-09-23 18:18:13 +0200, Peter Lebbing wrote:
>> The intent of this mail is not to ask whether something works. This can
>> be easily verified. It's asking whether it is a supported way of doing
>> things. I hope I can get some guidance on this!
> 
> I appreciate that you're asking for clarification about what is the
> scope of GnuPG's "API", such as it is.  We do need more clarity here.
> 
> i don't have the authority to answer your questions about the contents
> of ~/.gnupg/private-keys-v1.d/, but i'd always thought that the
> internals of ~/.gnupg/ were *not* part of the "API", and generally
> should not be relied upon.  I hope that Werner or someone else more
> closely related to the project can clarify here.

This raises interesting questions regarding subkeys.

For example, earlier this month there was a short thread with "Subject:
Subkeys" where OP was asking about generating subkeys.  The advice was
to consult https://wiki.debian.org/Subkeys .  That page contains the
following instructions:

> [...] delete the file `$HOME/.gnupg/private-keys-v1.d/KEYGRIP.key`,
where `KEYGRIP` is the "keygrip" of the master key which can be found by
running `gpg2 --with-keygrip --list-key YOURMASTERKEYID.`"

All other sources of information for generating subkeys that I have seen
contain similar instructions.

This is using the contents of `~/.gnupg/private-keys-v1.d/` as an API.
If this is *not* part of the API, then what *is* the official
recommendation for generating subkeys?

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9


From wiktor at metacode.biz  Mon Sep 24 10:10:00 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Mon, 24 Sep 2018 10:10:00 +0200
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <b5eda413-f7b9-4b78-8fdf-159bc3eb5bcb@andrewnesbit.org>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
 <87zhw8ge5x.fsf@fifthhorseman.net>
 <b5eda413-f7b9-4b78-8fdf-159bc3eb5bcb@andrewnesbit.org>
Message-ID: <dd6d0c77-efea-01ac-2fc6-2b25ff56ba9d@metacode.biz>

On 24.09.2018 02:09, Andrew Luke Nesbit wrote:
> This is using the contents of `~/.gnupg/private-keys-v1.d/` as an API.
> If this is *not* part of the API, then what *is* the official
> recommendation for generating subkeys?

I'm not in a position to suggest "official" recommendations but one
alternative that doesn't touch .gnupg is using secondary computer
(offline, air-gapped if possible) to store secret keys and either:

1) "keytocard" them or
2) --export-secret-keys one by one.

Kind regards,

Wiktor

-- 
https://metacode.biz/@wiktor


From peter at digitalbrains.com  Mon Sep 24 12:44:38 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 24 Sep 2018 12:44:38 +0200
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <87zhw8ge5x.fsf@fifthhorseman.net>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
 <87zhw8ge5x.fsf@fifthhorseman.net>
Message-ID: <de5e7e4e-2185-fa8d-6858-e5a0c144e0ca@digitalbrains.com>

On 23/09/2018 22:19, Daniel Kahn Gillmor wrote:
> [...], if you're looking to export a specific key for transfer into
> any other implementation (including other versions of GnuPG).  This is
> not only "acceptable" but it is normal, standardized, and widely
> interoperable.

I'm sorry, I did a very poor job of explaining it. I'm not transferring
keys, I'm managing keyrings. This is all with the same version of GnuPG.

And yes, I simply forgot to type the --import command.

The context is that we want to build a keyring for a specialized runtime
environment. We will be invoking gpg in the initramfs stage, to get
decryption keys for encrypted filesystems. It's still the same computer
running the same software (same gpg), but the normal filesystems are not
available yet.


So what there is now is this:

Preparation:
# gpg --export 0xDEADBEEF >/etc/cryptsetup-initramfs/pubring.gpg

This pubring.gpg gets copied into the initramfs at /cryptroot. During
early boot, the following gets executed (with an empty homedir in
default location):

# gpg --no-options --trust-model=always --no-default-keyring --keyring=/cryptroot/pubring.gpg --decrypt -- /etc/keys/cryptkey.gpg

I objected to this on the grounds that it is using what I have thought
for years is an implementation detail. Up to GnuPG 2.1, keyrings were
simple concatenated OpenPGP exported format certificates. Even though it
might work, even with GnuPG 2.1+, I thought building keyrings by
concatenating --export was considered not an API. So I proposed:

# gpg --export 0xDEADBEEF | gpg --no-default-keyring --keyring /etc/cryptsetup-initramfs/pubring.kbx --import

Note how we're not even changing the homedir or the executable, it's
just the same GnuPG version talking to itself, but with a different
destination keyring for --import. Okay, it also doesn't have the default
keyrings anymore during this one invocation. This does have some 
implications, the invocation might not be optimal yet.

Copy the pubring.kbx to /cryptroot in the initramfs. During subsequent
early boot (again, default but empty homedir):

# gpg --no-options --trust-model=always --no-default-keyring --keyring=/cryptroot/pubring.kbx --decrypt -- /etc/keys/cryptkey.gpg

Just the extension of the keyring changed. Extensions here are a hint
for the user anyway, GnuPG doesn't seem to care.

The always-correct option would be to --export, copy the exported key to
the initramfs, and simply --import it before use, no meddling with
prefabricated keyrings. It does waste some processing.

So have I been too strict all these years? :-) Are we free to build
keyrings with --export and will GnuPG happily consume them as an
always-supported fallback?

Thanks,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180924/c9627112/attachment.sig>

From guilhem at fripost.org  Mon Sep 24 11:58:01 2018
From: guilhem at fripost.org (Guilhem Moulin)
Date: Mon, 24 Sep 2018 11:58:01 +0200
Subject: Utilizing facts of homedir organization (was: Exact definition
 of token S/N field for --with-colons)
In-Reply-To: <87zhw8ge5x.fsf@fifthhorseman.net>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
 <87zhw8ge5x.fsf@fifthhorseman.net>
Message-ID: <20180924095800.GB9167@localhost.localdomain>

Hi there,

On Sun, 23 Sep 2018 at 16:19:22 -0400, Daniel Kahn Gillmor wrote:
> But the real question is: why do you need this, and what do you intend
> to do with it?

I believe it was a follow up to https://bugs.debian.org/903163, messages
?160 in particular.  TL;DR: for smartcard usage (decryption in our case)
at initramfs stage we need a public keyring containing the relevant
public key(s), and copy it into the initramfs image.

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180924/2de9d646/attachment.sig>

From dkg at fifthhorseman.net  Mon Sep 24 16:18:44 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 24 Sep 2018 10:18:44 -0400
Subject: Utilizing facts of homedir organization (was: Exact definition of
 token S/N field for --with-colons)
In-Reply-To: <b5eda413-f7b9-4b78-8fdf-159bc3eb5bcb@andrewnesbit.org>
References: <98b958f1-5f8c-dfc2-7ad4-59dd941fac56@digitalbrains.com>
 <6d040c11-1027-495d-61b5-e8a5b750a794@digitalbrains.com>
 <87zhw8ge5x.fsf@fifthhorseman.net>
 <b5eda413-f7b9-4b78-8fdf-159bc3eb5bcb@andrewnesbit.org>
Message-ID: <87r2hjgerf.fsf@fifthhorseman.net>

On Mon 2018-09-24 01:09:25 +0100, Andrew Luke Nesbit wrote:
> This is using the contents of `~/.gnupg/private-keys-v1.d/` as an API.
> If this is *not* part of the API, then what *is* the official
> recommendation for generating subkeys?

The part of those pages about "generating subkeys" does use the GnuPG
API.

So I think the question you're asking is "what is the official
recommendation for deleting the cryptographic secret associated with the
master key?"

I agree that it would be nice if there was a clear, supported API for
doing that.  I suspect it would be something like:

  gpg-connect-agent "delete_key $KEYGRIP" /bye

(and you probably want to get the keygrip via

   gpg --with-colons --with-keygrip $FINGERPRINT

)

This clearly isn't a usable situation for most users, so it's primarily
important to document it so that more usable tools can be written that
know how to safely interact with GnuPG under the hood.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180924/b3e551fc/attachment.sig>

From kll at dev.terastrm.net  Tue Sep 25 23:03:17 2018
From: kll at dev.terastrm.net (Kristian Larsson)
Date: Tue, 25 Sep 2018 23:03:17 +0200
Subject: Monitoring queries to gpg-agent?
Message-ID: <87lg7pcmsq.fsf@dev.terastrm.net>


Hello,

I would like to see the queries to gpg-agent that clients are 
sending. Like what key are they trying to access and whatever 
other information might be available as well.

A little background; I am using gpg-agent together with a Yubikey 
to securely store my GPG keys. In addition I've enabled so that 
whenever an authentication, sign or decryption request happens I 
must physically push the button on the Yubikey. It is very clear 
when I do ssh FOO and the Yubikey starts blinking that I need to 
push it and I can easily understand what query caused the Yubikey 
to start blinking (although I suppose there is a risk of someone 
using this opportunity to launch a query just prior and me 
thinking it is my ssh query will press the button).

I also have cron jobs that perform things, like running mbsync in 
the background to retrieve email and they in turn use GPG to 
decrypt the file containing the password. In this case I haven't 
interactively initiated the command but instead my Yubikey just 
starts blinking and I don't know why (although I can guess). I 
would like to be able to see what the current query to gpg-agent 
is.

Is there a way I can monitor and display the queries to gpg-agent 
so I can see what the current query is actually trying to do?

Kind regards,
   Kristian.

-- 
Kristian Larsson
kll at dev.terastrm.net


From peter at digitalbrains.com  Wed Sep 26 12:43:45 2018
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 26 Sep 2018 12:43:45 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <87lg7pcmsq.fsf@dev.terastrm.net>
References: <87lg7pcmsq.fsf@dev.terastrm.net>
Message-ID: <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>

On 25/09/2018 23:03, Kristian Larsson wrote:
> Is there a way I can monitor and display the queries to gpg-agent so I
> can see what the current query is actually trying to do?

This is reminding me of a message Werner wrote[1] last year that
pinentry will show some context of the reason it is prompting. So this
functionality might be in the works. I assume you are prompted by a
pinentry to push the button?

As you note, if access to your agent was compromised, this would not
constitute solid protection as the information could be spoofed or
substituted. It is informative, though.

HTH,

Peter.

[1] <https://lists.gnupg.org/pipermail/gnupg-users/2017-November/059469.html>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180926/5512fe62/attachment-0001.sig>

From wiktor at metacode.biz  Wed Sep 26 13:01:57 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 26 Sep 2018 13:01:57 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
References: <87lg7pcmsq.fsf@dev.terastrm.net>
 <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
Message-ID: <0697e81c-5a54-7765-bd4e-2b697edd9924@metacode.biz>

> This is reminding me of a message Werner wrote[1] last year that
> pinentry will show some context of the reason it is prompting. So this
> functionality might be in the works. I assume you are prompted by a
> pinentry to push the button?

I'm using a similar setup. Pinentry only appears when the actual PIN is
needed (once to unlock the card, and on each signature if that option is
enabled). It *does not* appear when there is a need to "push the
button", one just have to mind the flashing light of the button.

This feature is described here:

https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_touch

And it seems there is a mention of "User Interaction Flag" Data Object
in OpenPGP Card spec:

https://openpgpcard.org/resources/openpgp-card-3.3.pdf (search for "User
Interaction Flag") so in theory pinentry, or some other prompt, could be
displayed to the user.

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


From wiktor at metacode.biz  Wed Sep 26 13:02:01 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Wed, 26 Sep 2018 13:02:01 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
References: <87lg7pcmsq.fsf@dev.terastrm.net>
 <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
Message-ID: <648c8c06-7f3f-0fe8-e6d1-5728eb6cc3a1@metacode.biz>

> This is reminding me of a message Werner wrote[1] last year that
> pinentry will show some context of the reason it is prompting. So this
> functionality might be in the works. I assume you are prompted by a
> pinentry to push the button?

I'm using a similar setup. Pinentry only appears when the actual PIN is
needed (once to unlock the card, and on each signature if that option is
enabled). It *does not* appear when there is a need to "push the
button", one just have to mind the flashing light of the button.

This feature is described here:

https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_touch

And it seems there is a mention of "User Interaction Flag" Data Object
in OpenPGP Card spec:

https://openpgpcard.org/resources/openpgp-card-3.3.pdf (search for "User
Interaction Flag") so in theory pinentry, or some other prompt, could be
displayed to the user.

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor


From wk at gnupg.org  Wed Sep 26 17:27:50 2018
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Sep 2018 17:27:50 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <87lg7pcmsq.fsf@dev.terastrm.net> (Kristian Larsson's message of
 "Tue, 25 Sep 2018 23:03:17 +0200")
References: <87lg7pcmsq.fsf@dev.terastrm.net>
Message-ID: <87ftxwgtxl.fsf@wheatstone.g10code.de>

On Tue, 25 Sep 2018 23:03, kll at dev.terastrm.net said:

> I would like to see the queries to gpg-agent that clients are
> sending. Like what key are they trying to access and whatever other

That is easy.  Put

  log-file socket://
  debug ipc

into ~/.gnupg/gpg-agent.conf.  Feed your monitor process the with the
output of 

  watchgnupg --force $(gpgconf --list-dirs socketdir)/S.log

What you see are debug messages so it is not a really stable inetrface
but it has not changed for more than a decade.  Inside the debug message
you see the request from the gpg processes and gpg-agent's replies.  You
can easily distinguish the gpg processes.  For the semantics of the
protocol used between gpg and the agent you can use the online help:

  gpg-connect-agent

and then enter "HELP <mycommand>". <mycommand> might be PKSIGN etc.  The
manual (info or PDF file) describes some of theses commands.

If you want to see the interaction between gpg-agent and pinentry as
weel, add the line

  debug-pinenentry

to gpg-agent.conf and you see when and what gpg-agent sends to the
pinentry.  Sensitive data is blackened.  If you need more help, please
don't hesitate to ask.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180926/ed944a48/attachment.sig>

From kll at dev.terastrm.net  Wed Sep 26 12:57:33 2018
From: kll at dev.terastrm.net (Kristian Larsson)
Date: Wed, 26 Sep 2018 12:57:33 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
References: <87lg7pcmsq.fsf@dev.terastrm.net>
 <4f002ae2-580f-fc3a-27d1-4bac6ed7c955@digitalbrains.com>
Message-ID: <09a43c80-09a2-6577-51e7-6b50ddcb6f96@dev.terastrm.net>



On 2018-09-26 12:43, Peter Lebbing wrote:
> On 25/09/2018 23:03, Kristian Larsson wrote:
>> Is there a way I can monitor and display the queries to gpg-agent so I
>> can see what the current query is actually trying to do?
> 
> This is reminding me of a message Werner wrote[1] last year that
> pinentry will show some context of the reason it is prompting. So this
> functionality might be in the works.

Ah, interesting, sounds similar yes. I'd be very interested in hearing 
more about this.

> I assume you are prompted by a
> pinentry to push the button?

I cache the pin so it only asks me sporadically and mostly at the start 
of a work session but I have to push the button on the yubikey for every 
query, so with cached PIN it means there's no pinentry prompt 99% of the 
time.

> As you note, if access to your agent was compromised, this would not
> constitute solid protection as the information could be spoofed or
> substituted. It is informative, though.

Right, I understand.

Kind regards,
   Kristian.


From kll at dev.terastrm.net  Thu Sep 27 10:24:43 2018
From: kll at dev.terastrm.net (Kristian Larsson)
Date: Thu, 27 Sep 2018 10:24:43 +0200
Subject: Monitoring queries to gpg-agent?
In-Reply-To: <87ftxwgtxl.fsf@wheatstone.g10code.de>
References: <87lg7pcmsq.fsf@dev.terastrm.net>
 <87ftxwgtxl.fsf@wheatstone.g10code.de>
Message-ID: <871s9fcppw.fsf@dev.terastrm.net>


Werner Koch <wk at gnupg.org> writes:

> On Tue, 25 Sep 2018 23:03, kll at dev.terastrm.net said:
>
>> I would like to see the queries to gpg-agent that clients are
>> sending. Like what key are they trying to access and whatever 
>> other
>
> That is easy.  Put
>
>   log-file socket://
>   debug ipc
>
> into ~/.gnupg/gpg-agent.conf.  Feed your monitor process the 
> with the
> output of 
>
>   watchgnupg --force $(gpgconf --list-dirs socketdir)/S.log
>
> What you see are debug messages so it is not a really stable 
> inetrface
> but it has not changed for more than a decade.  Inside the debug 
> message
> you see the request from the gpg processes and gpg-agent's 
> replies.  You
> can easily distinguish the gpg processes.  For the semantics of 
> the
> protocol used between gpg and the agent you can use the online 
> help:
>
>   gpg-connect-agent
>
> and then enter "HELP <mycommand>". <mycommand> might be PKSIGN 
> etc.  The
> manual (info or PDF file) describes some of theses commands.
>
> If you want to see the interaction between gpg-agent and 
> pinentry as
> weel, add the line
>
>   debug-pinenentry
>
> to gpg-agent.conf and you see when and what gpg-agent sends to 
> the
> pinentry.  Sensitive data is blackened.  If you need more help, 
> please
> don't hesitate to ask.

Thanks! It was a little lower level than I had wished for but I'll 
have a look and see if I can make something useful out of it :)

Kind regards,
   Kristian.

-- 
Kristian Larsson
kll at dev.terastrm.net


From fkater at posteo.net  Thu Sep 27 17:03:27 2018
From: fkater at posteo.net (Felix A. Kater)
Date: Thu, 27 Sep 2018 17:03:27 +0200
Subject: Performance regression for gnupg v2 keys
In-Reply-To: <20180921081407.GA774@zed>
References: <20180919104502.GB426@zed> <20180920130514.GA946@zed>
 <87d0t8p7r2.fsf@wheatstone.g10code.de> <20180921081407.GA774@zed>
Message-ID: <20180927150327.GA7634@zed>

Hi,

I permit myself to sum up the open questions:

> that value can be changed at build time using the configure option
> --with-agent-s2k-calibration=MSEC but not at run time.  

That option doesn't seem to be present in gnupg configure.ac...?


> When you change the passphrase of an old key the first time or
> when you import it to gpg the key is re-encrypted so that it takes
> that long.

With the above build-time setting applied, do all previously
generated (slow) keys have to be recreated or is this delay gone
with a newly compiled agent/gnupg library?

Thanks
Felix


From Jennifer.Mead at pacificorp.com  Thu Sep 27 20:07:59 2018
From: Jennifer.Mead at pacificorp.com (Mead, Jennifer)
Date: Thu, 27 Sep 2018 18:07:59 +0000
Subject: converting gpg files into PEM and certification change confusion
Message-ID: <1538071627836.86861@pacificorp.com>

Hi folks, new to gpg and thid forum,


I have used keys for many years, but not in a mangement role.  Now I am installing Yubikey KSM and Validation server.  I thought I understood it well enough but apparently that is not true.  While working on the validation piece I was requested to convert my certificate chain into a pem file and place it where all the parts and pieces of yubikey can get to it via the web.  My first what??? moment.  Like what is the certificate chain?  I did some research and even though it is mentioned quite often by others I have not been able to assert which file that actuall is.  Here is what is in my .gnupg directory:

.   gpg.conf                                   .#lk0x23dd010.changed.16771  .note.swp          pubring.gpg   random_seed  S.gpg-agent
..  .#lk0x10c18a0.changed.32015  note                                       private-keys-v1.d  pubring.gpg~  secring.gpg  trustdb.gpg


key was created as such:

gpg --gen-key
chose: (2) DSA and Elgamal
Key is valid for? (0) 0
input name,email,user-id and passphrase
gpg: key 1234WXYZ marked as ultimately trusted
public and secret key created and signed.

then it spit out that it was checked the trustdb returned these types:
uid
pub
sub

I then took those keys and turned them into yubikey format and loaded them into a db.  I thought all was said and done (LOL).

So I think one of those files is my supposed "certificate chain"... not sure.  Maybe I have not created the chain?

When I try to convert a file (pubring, secring, trustdb) they all end with:

[root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/trustdb.gpg -outform pem
read DSA key
unable to load Private Key
140528619882384:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
unable to load Key
[root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/secring.gpg -outform pem
read DSA key
unable to load Private Key
140648490235792:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
unable to load Key


1) I am not sure that (2) DSA and Elgamal will work with the above command, it seems like two alogrythms and not one (Elgamal is there too).  Is that the problem?  Or do I need an intermediary format to accomplish this?  What the heck am I doing wrong.  I do have two certs on my server as follows:

/etc/ssl/certs/ca-bundle.trust.crt
/etc/ssl/certs/ca-bundle.crt

perhaps they are related?  I don't remember what step created them.  This is all very confusing to me and I need some gental nudges in the right direction.  Sorry for being such a newbie and not really getting any of this.  Any help is greatly appreciated.


Regards,

Jen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180927/205b2dd9/attachment-0001.html>

From wiktor at metacode.biz  Thu Sep 27 22:34:51 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Thu, 27 Sep 2018 22:34:51 +0200
Subject: converting gpg files into PEM and certification change confusion
In-Reply-To: <1538071627836.86861@pacificorp.com>
References: <1538071627836.86861@pacificorp.com>
Message-ID: <c5b538d5-af95-277f-00ea-74b7fa988876@metacode.biz>

Hi Jen,

Could you provide links to the documentation that mentions the
"certificate chain"?

I went through these docs but didn't find the exact match:
https://developers.yubico.com/yubikey-val/
https://developers.yubico.com/yubikey-ksm/

PEM format contains X.509 certificates, as used by TLS and S/MIME, not
OpenPGP ones. Likewise openssl is used to work with X.509 certs,
/etc/ssl/certs/ca-bundle.crt contains X.509 certs too.

Maybe the certs that you mention are for HTTPS server?

X.509 and OpenPGP are not compatible directly, although both can use
same cryptographic primitives (like RSA keys).

Kind regards,
Wiktor

On 27.09.2018 20:07, Mead, Jennifer wrote:
> Hi folks, new to gpg and thid forum,
> 
> 
> I have used keys for many years, but not in a mangement role.? Now I am
> installing Yubikey KSM and Validation server.? I thought I understood it
> well enough but apparently that is not true.? While working on the
> validation piece I was requested to convert my certificate chain into a
> pem file and place it where all the parts and pieces of yubikey can get
> to it via the web.? My first what??? moment.? Like what is the
> certificate chain?? I did some research and even though it is mentioned
> quite often by others I have not been able to assert which file that
> actuall is.? Here is what is in my .gnupg directory:
> 
> .?? gpg.conf??????????????????????????????????
> .#lk0x23dd010.changed.16771? .note.swp????????? pubring.gpg??
> random_seed? S.gpg-agent
> ..? .#lk0x10c18a0.changed.32015?
> note?????????????????????????????????????? private-keys-v1.d?
> pubring.gpg~? secring.gpg? trustdb.gpg
> 
> 
> key was created as such:
> 
> gpg --gen-key
> chose: (2) DSA and Elgamal
> Key is valid for? (0) 0
> input name,email,user-id and passphrase
> gpg: key 1234WXYZ marked as ultimately trusted
> public and secret key created and signed.
> 
> then it spit out that it was checked the trustdb returned these types:
> uid
> pub
> sub
> 
> I then took those keys and turned them into yubikey format and loaded
> them into a db.? I thought all was said and done (LOL).
> 
> So I think one of those files is my supposed "certificate chain"... not
> sure.? Maybe I have not created the chain?
> 
> When I try to convert a file (pubring, secring, trustdb) they all end with:
> 
> [root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/trustdb.gpg -outform pem
> read DSA key
> unable to load Private Key
> 140528619882384:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
> unable to load Key
> [root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/secring.gpg -outform pem
> read DSA key
> unable to load Private Key
> 140648490235792:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
> unable to load Key
> 
> 
> 1) I am not sure that (2) DSA and Elgamal will work with the above
> command, it seems like two alogrythms and not one (Elgamal is there
> too).? Is that the problem?? Or do I need an intermediary format to
> accomplish this?? What the heck am I doing wrong.? I do have two certs
> on my server as follows:
> 
> /etc/ssl/certs/ca-bundle.trust.crt
> /etc/ssl/certs/ca-bundle.crt
> 
> perhaps they are related?? I don't remember what step created them.?
> This is all very confusing to me and I need some gental nudges in the
> right direction.? Sorry for being such a newbie and not really getting
> any of this.? Any help is greatly appreciated.
> 
> 
> Regards,
> 
> Jen
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


-- 
https://metacode.biz/@wiktor


From wolfgang.pappa at posteo.de  Thu Sep 27 22:01:35 2018
From: wolfgang.pappa at posteo.de (Wolfgang Pappa)
Date: Thu, 27 Sep 2018 22:01:35 +0200
Subject: Update primary key on server to not expire
Message-ID: <20180927200135.kfqub3sgndqed4id@livlibrem.localdomain>

Hello,

I changed the expiration date on my primary key from "2018-09-22" to "never expire".
On my subkeys I extended the expiration date to "2019-09-24".
On my local machine, everything is fine:

$ gpg --list-keys bbea93c8
pub   rsa4096/BBEA93C8 2014-10-17 [SCA]
      Key fingerprint = A8FC 7FEC 9A68 B5E0 EFA2  5E47 4521 F618 BBEA 93C8
uid         [ultimate] Wolfgang Pappa <wolfgang.pappa at posteo.de>
uid         [ultimate] Wolfgang Pappa <wolfgang.pappa at senckenberg.de>
uid         [ultimate] Living <living at posteo.de>
sub   rsa4096/FB903A9F 2014-10-17 [E] [expires: 2019-09-24]
sub   rsa4096/DF662BA7 2017-09-24 [A] [expires: 2019-09-24]
sub   rsa4096/70B94B54 2017-09-24 [S] [expires: 2019-09-24]

Then I uploaded my key to the keyserver:

$ gpg --keyserver 'https://hkps.pool.sks-keyservers.net' --send-keys BBEA93C8

On the keyserver, only the expiration date of my subkeys got updated. My primary key is marked as expired:

$ curl 'https://hkps.pool.sks-keyservers.net/pks/lookup?op=get&fingerprint=on&search=0x4521F618BBEA93C8' | gpg
pub   rsa4096/BBEA93C8 2014-10-17 [SCA] [expired: 2018-09-22]
      Key fingerprint = A8FC 7FEC 9A68 B5E0 EFA2  5E47 4521 F618 BBEA 93C8
uid                   Living <living at posteo.de>
uid                   Wolfgang Pappa <wolfgang.pappa at posteo.de>
uid                   Wolfgang Pappa <wolfgang.pappa at senckenberg.de>
sub   rsa4096/FB903A9F 2014-10-17 [E] [expired: 2019-09-24]
sub   rsa4096/DF662BA7 2017-09-24 [A] [expired: 2019-09-24]
sub   rsa4096/70B94B54 2017-09-24 [S] [expired: 2019-09-24]

My Question: How can I convince the keyserver to set my primary key?s expiration date to "never expire"?

Cheers,

Wolfgang



From wk at gnupg.org  Fri Sep 28 07:48:08 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Sep 2018 07:48:08 +0200
Subject: converting gpg files into PEM and certification change confusion
In-Reply-To: <c5b538d5-af95-277f-00ea-74b7fa988876@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-users's message of "Thu, 27 Sep 2018 22:34:51
 +0200")
References: <1538071627836.86861@pacificorp.com>
 <c5b538d5-af95-277f-00ea-74b7fa988876@metacode.biz>
Message-ID: <87h8iacgvb.fsf@wheatstone.g10code.de>

On Thu, 27 Sep 2018 22:34, gnupg-users at gnupg.org said:

> OpenPGP ones. Likewise openssl is used to work with X.509 certs,
> /etc/ssl/certs/ca-bundle.crt contains X.509 certs too.

FWIW: GnuPG also supports X.509 and CMS (aka S/MIME) you have to use the
gpgsm tool, which is similar to gpg as far as possible.  However, the
X.509 and OpenPGP protocols are quite different in that they use
different formats and that OpenPGP is a _functional_ superset of X.509.

It is not possible to mix both protocols.  There is one exception: With
a bit of magic it is possible to use a key stored on a a smartcard by
both protocols.  This is because down at the lowest math level both use
the same algorithms.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180928/f94ce280/attachment.sig>

From wiktor at metacode.biz  Fri Sep 28 09:52:12 2018
From: wiktor at metacode.biz (Wiktor Kwapisiewicz)
Date: Fri, 28 Sep 2018 09:52:12 +0200
Subject: [INTERNET] Re: converting gpg files into PEM and certification
 change confusion
In-Reply-To: <1538080962566.92783@pacificorp.com>
References: <1538071627836.86861@pacificorp.com>
 <c5b538d5-af95-277f-00ea-74b7fa988876@metacode.biz>
 <1538080962566.92783@pacificorp.com>
Message-ID: <256be7aa-01ed-0377-157d-59989e435d1b@metacode.biz>

Hi Jen,

On 27.09.2018 22:43, Mead, Jennifer wrote:
> Hi Wiktor,
> 
> On this page https://developers.yubico.com/yubikey-val/Installation.html
> 
> Step 7
> You will need to place the private key in /etc/ssl/private/api.example.com-key.pem and the certificate chain in /etc/ssl/private/api.example.com-chain.pem.

Yes, then this is only related to SSL keys used by the server and
doesn't have anything to do with your OpenPGP/GPG keys.

They are a completely separate set of keys, and this looks like a
standard HTTPS setup. You can get some guides by searching for "ssl
apache". Generally the procedure is to generate new pair of keys,
generate CSR, then use the CSR to buy an SSL certificate. CA will
provide you with their certificate chain.

You can get a free certificate from Let's Encrypt, they are valid for 3
months.

Kind regards,
Wiktor

> 
> regards,
> Jen
> ________________________________________
> From: Wiktor Kwapisiewicz <wiktor at metacode.biz>
> Sent: Thursday, September 27, 2018 1:34 PM
> To: Mead, Jennifer
> Cc: gnupg-users at gnupg.org
> Subject: [INTERNET] Re: converting gpg files into PEM and certification change confusion
> 
> ** STOP. THINK. External Email **
> 
> ------------------------------------------------------------------------------
> 
> Hi Jen,
> 
> Could you provide links to the documentation that mentions the
> "certificate chain"?
> 
> I went through these docs but didn't find the exact match:
> https://developers.yubico.com/yubikey-val/
> https://developers.yubico.com/yubikey-ksm/
> 
> PEM format contains X.509 certificates, as used by TLS and S/MIME, not
> OpenPGP ones. Likewise openssl is used to work with X.509 certs,
> /etc/ssl/certs/ca-bundle.crt contains X.509 certs too.
> 
> Maybe the certs that you mention are for HTTPS server?
> 
> X.509 and OpenPGP are not compatible directly, although both can use
> same cryptographic primitives (like RSA keys).
> 
> Kind regards,
> Wiktor
> 
> On 27.09.2018 20:07, Mead, Jennifer wrote:
>> Hi folks, new to gpg and thid forum,
>>
>>
>> I have used keys for many years, but not in a mangement role.  Now I am
>> installing Yubikey KSM and Validation server.  I thought I understood it
>> well enough but apparently that is not true.  While working on the
>> validation piece I was requested to convert my certificate chain into a
>> pem file and place it where all the parts and pieces of yubikey can get
>> to it via the web.  My first what??? moment.  Like what is the
>> certificate chain?  I did some research and even though it is mentioned
>> quite often by others I have not been able to assert which file that
>> actuall is.  Here is what is in my .gnupg directory:
>>
>> .   gpg.conf
>> .#lk0x23dd010.changed.16771  .note.swp          pubring.gpg
>> random_seed  S.gpg-agent
>> ..  .#lk0x10c18a0.changed.32015
>> note                                       private-keys-v1.d
>> pubring.gpg~? secring.gpg  trustdb.gpg
>>
>>
>> key was created as such:
>>
>> gpg --gen-key
>> chose: (2) DSA and Elgamal
>> Key is valid for? (0) 0
>> input name,email,user-id and passphrase
>> gpg: key 1234WXYZ marked as ultimately trusted
>> public and secret key created and signed.
>>
>> then it spit out that it was checked the trustdb returned these types:
>> uid
>> pub
>> sub
>>
>> I then took those keys and turned them into yubikey format and loaded
>> them into a db.  I thought all was said and done (LOL).
>>
>> So I think one of those files is my supposed "certificate chain"... not
>> sure.  Maybe I have not created the chain?
>>
>> When I try to convert a file (pubring, secring, trustdb) they all end with:
>>
>> [root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/trustdb.gpg -outform pem
>> read DSA key
>> unable to load Private Key
>> 140528619882384:error:0906D06C:PEM routines:PEM_read_bio:no start
>> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>> unable to load Key
>> [root at cswks99 .gnupg]# openssl dsa -in ~/.gnupg/secring.gpg -outform pem
>> read DSA key
>> unable to load Private Key
>> 140648490235792:error:0906D06C:PEM routines:PEM_read_bio:no start
>> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>> unable to load Key
>>
>>
>> 1) I am not sure that (2) DSA and Elgamal will work with the above
>> command, it seems like two alogrythms and not one (Elgamal is there
>> too).  Is that the problem?  Or do I need an intermediary format to
>> accomplish this?  What the heck am I doing wrong.  I do have two certs
>> on my server as follows:
>>
>> /etc/ssl/certs/ca-bundle.trust.crt
>> /etc/ssl/certs/ca-bundle.crt
>>
>> perhaps they are related?  I don't remember what step created them.
>> This is all very confusing to me and I need some gental nudges in the
>> right direction.  Sorry for being such a newbie and not really getting
>> any of this.  Any help is greatly appreciated.
>>
>>
>> Regards,
>>
>> Jen
>>
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>>
> 
> 
> --
> https://metacode.biz/@wiktor
> 


-- 
https://metacode.biz/@wiktor


From wk at gnupg.org  Fri Sep 28 17:18:28 2018
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Sep 2018 17:18:28 +0200
Subject: [INTERNET] Re: converting gpg files into PEM and certification
 change confusion
In-Reply-To: <256be7aa-01ed-0377-157d-59989e435d1b@metacode.biz> (Wiktor
 Kwapisiewicz via Gnupg-users's message of "Fri, 28 Sep 2018 09:52:12
 +0200")
References: <1538071627836.86861@pacificorp.com>
 <c5b538d5-af95-277f-00ea-74b7fa988876@metacode.biz>
 <1538080962566.92783@pacificorp.com>
 <256be7aa-01ed-0377-157d-59989e435d1b@metacode.biz>
Message-ID: <8736ttbqgq.fsf@wheatstone.g10code.de>

On Fri, 28 Sep 2018 09:52, gnupg-users at gnupg.org said:

> You can get a free certificate from Let's Encrypt, they are valid for 3
> months.

.. and you can automated the update of the certificates.  There are lot
of tools for this; we at gnupg.org use the Dehydrated script.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180928/02212d5f/attachment.sig>