From linux_nutzer42 at mailbox.org  Sat Jul  1 16:46:21 2017
From: linux_nutzer42 at mailbox.org (linux_nutzer42 at mailbox.org)
Date: Sat, 1 Jul 2017 16:46:21 +0200 (CEST)
Subject: gnupg 2.1.16: change of option --with-fingerprint
Message-ID: <1740352141.11593.1498920381694@office.mailbox.org>

Hello all,

did the function of the option --with-fingerprint change in gnupg 2.1.16 and later?

When I tried to import a CentOS gpg key according to the manual from [1], I made the following observation:

"gpg --quiet --with-fingerprint <file path>" does not return the fingerprint when using gnupg 2.1.17 (on ArchLinux and openSuse Tumbleweed).
Also a self-compiled gnupg 2.1.16 does not return the fingerprint in this scenario, whereas a self compiled gnupg 2.1.15 does so.
gnupg 2.1.13 on Fedora also returns the fingerprint.
For the tests I used the key from [2] which I downloaded according to [1] with wget.

Many thanks in advance.

Regards
linux_nutzer42


links
=====
[1] https://wiki.centos.org/Download/Verify 
[2] http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

details
=======
Arch Linux gnupg 2.1.17
-----------------------
$ gpg --quiet --with-fingerprint ./RPM-GPG-KEY-CentOS-7
pub?? rsa4096 2014-06-23 [SC]
uid?????????? CentOS-7 Key (CentOS 7 Official Signing Key) <security at centos.org>

Fedora gnupg 2.1.13
-------------------
$ gpg2 --quiet --with-fingerprint ./RPM-GPG-KEY-CentOS-7
pub?? rsa4096 2014-06-23 [SC]
????? 6341 AB27 53D7 8A78 A7C2? 7BB1 24C6 A8A7 F4A8 0EB5
uid?????????? CentOS-7 Key (CentOS 7 Official Signing Key) <security at centos.org>


From guru at unixarea.de  Sun Jul  2 20:49:03 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 2 Jul 2017 20:49:03 +0200
Subject: about CCID USB readers (Re: setting GnuPG card to 'not forces'
 does not let sign)
In-Reply-To: <20170622062857.GA2681@c720-r314251>
References: <20170608102956.GA10333@c720-r314251>
 <877f0lofp3.fsf@wheatstone.g10code.de>
 <20170609063910.GB2857@c720-r314251>
 <871sqqjqp2.fsf@wheatstone.g10code.de>
 <20170612103825.GA4341@c720-r314251>
 <87wp8hh3qo.fsf@wheatstone.g10code.de>
 <20170622062857.GA2681@c720-r314251>
Message-ID: <20170702184903.GA2425@c720-r314251>

El d?a jueves, junio 22, 2017 a las 08:28:57a. m. +0200, Matthias Apitz escribi?:

> Some days ago I acquired this uTrust token. And surprise, surprise, it
> showed the same symptoms as the other one, the HID Global OMNIKEY 6121
> Smart Card Reader: My operating system does not always recognises the
> USB device, not even when plug'ed in before power-on. This smells
> somehow as a hardware issue in the Acer C720 or in the kernel of the
> FreeBSD (and I do run CURRENT on it, i.e. compiled directly from SVN).
> Here is the bug issue I filed against our beloved FreeBSD:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220127
> Only if someone has similar experiences.
> 
> ...

At the end of the day it turned out that this was an issue in the
FreeBSD' drivers and/or some raise conditions or electrical problem. I
removed some of the drivers which were searching the USB bus for devices
and now have only the XHCI driver in the kernel (disabled UHCI, OHCI and EHCI)
and with this, the detection of both cards (uTrust and Omnikey) is fine.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170702/2f0c2615/attachment.sig>

From guru at unixarea.de  Sun Jul  2 20:51:32 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 2 Jul 2017 20:51:32 +0200
Subject: using GnuPG card for Firefox master password
Message-ID: <20170702185132.GB2425@c720-r314251>


Hi,

I have a bunch of saved logins in Firefox, protected by some so called
master password. Is there a way for using the GnuPG card as the master
password, maybe some plug-in for FF?

Thanks

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170702/fe164bc8/attachment.sig>

From dgouttegattat at incenp.org  Sun Jul  2 21:29:13 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 2 Jul 2017 21:29:13 +0200
Subject: using GnuPG card for Firefox master password
In-Reply-To: <20170702185132.GB2425@c720-r314251>
References: <20170702185132.GB2425@c720-r314251>
Message-ID: <d8b3ab5f-d255-79ea-a444-a41247ad01a3@incenp.org>

Hi,

On 07/02/2017 08:51 PM, Matthias Apitz wrote:
> I have a bunch of saved logins in Firefox, protected by some so called
> master password. Is there a way for using the GnuPG card as the master
> password, maybe some plug-in for FF?

As far as I know, not as the master password protecting Firefox's own 
password store. But what you can do is make Firefox use *another* 
password store, one that relies on GnuPG.

pass [1] is a password manager which encrypts passwords with the user's 
GnuPG key. Several plug-ins are available to instruct Firefox to use 
pass instead of its own password storage system, such as PassFF [2] or 
BrowserPass [3]. (Disclaimer: I tried none of them.)

So, when Firefox will need a password it will ask pass, which will call 
gpg, which will in turn "call" your smartcard.

An obvious drawback of this method is that you need to migrate all your 
passwords from Firefox's own storage to pass. There is at least one 
script available for that [4], but again I did not try it.

Hope that helps,

Damien

[1] https://www.passwordstore.org/
[2] https://addons.mozilla.org/en-US/firefox/addon/passff/
[3] https://github.com/dannyvankooten/browserpass
[4] https://github.com/Unode/firefox_decrypt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170702/c0378dbc/attachment.sig>

From johanw at vulcan.xs4all.nl  Tue Jul  4 12:05:08 2017
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Tue, 04 Jul 2017 12:05:08 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <87r2y35k2z.fsf@wheatstone.g10code.de>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
Message-ID: <595B6854.8030300@vulcan.xs4all.nl>

On 29-06-2017 9:28, Werner Koch wrote:

> The GnuPG Project is pleased to announce the availability of Libgcrypt
> version 1.7.8.  This release fixes a local side-channel attack.

Is 1.4 vulnerable to this attack as well? I know it ows not use
libgcrypt but I'm not sure about the vulnerability.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From wk at gnupg.org  Tue Jul  4 18:12:40 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Jul 2017 18:12:40 +0200
Subject: SHA1 depreciation ??
In-Reply-To: <c33a36ed-d967-2521-690d-3161ca4cd73b@gmail.com> (Lou Wynn's
 message of "Thu, 29 Jun 2017 17:33:32 -0700")
References: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>
 <ead53bf3-9e19-55b4-1c9b-17e96bed0076@sixdemonbag.org>
 <c33a36ed-d967-2521-690d-3161ca4cd73b@gmail.com>
Message-ID: <87y3s4qiyv.fsf@wheatstone.g10code.de>

On Fri, 30 Jun 2017 02:33, lewisurn at gmail.com said:

> Do you know any time frame and significant changes of v5 specs?

Next year we will prepare GnuPG to handle v5 keys read-only.  I assume
that we can create v5 keys by default in maybe 5 years.


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: </pipermail/attachments/20170704/4d871282/attachment.sig>

From wk at gnupg.org  Tue Jul  4 18:28:27 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Jul 2017 18:28:27 +0200
Subject: gnupg 2.1.16: change of option --with-fingerprint
In-Reply-To: <1740352141.11593.1498920381694@office.mailbox.org> (linux
 nutzer's message of "Sat, 1 Jul 2017 16:46:21 +0200 (CEST)")
References: <1740352141.11593.1498920381694@office.mailbox.org>
Message-ID: <87tw2sqi8k.fsf@wheatstone.g10code.de>

On Sat,  1 Jul 2017 16:46, linux_nutzer42 at mailbox.org said:

> When I tried to import a CentOS gpg key according to the manual from [1], I made the following observation:
>
> "gpg --quiet --with-fingerprint <file path>" does not return the fingerprint when using gnupg 2.1.17 (on ArchLinux and openSuse Tumbleweed).

That manual suggest the use of an unspecified behavior.  Namely that gpg
tries to do the right thing depending on the data.  For keys you will
see only some kind of debug output which funnily resembles a key
listing.  But it is not a real key listing.  Recent version of gpg thus
print

  gpg: WARNING: no command supplied.  Trying to guess what you mean ...

What you need to do instead is to import that key and then run 

  gpg -k --with-fingerprint security at centos.org

or

  gpg --fingerprint security at centos.org

which shows the fingerprint.  Here -k and --fingerprint are the
commands.  If you don't want to import the key and your version of gpg
is at least 2.1.14 you can do this:

  gpg -n --import --import-options import-show FILE_WITH_KEY

This tells the import command to list the key during input (import-show)
and not to actually import (-n or --dry-run)

In case you want to script this, please make sure to also add
--with-colons so that you get the guaranteed to be stable machine
readable output.


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: </pipermail/attachments/20170704/e2f30f19/attachment.sig>

From wk at gnupg.org  Tue Jul  4 18:30:28 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Jul 2017 18:30:28 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <595B6854.8030300@vulcan.xs4all.nl> (Johan Wevers's message of
 "Tue, 04 Jul 2017 12:05:08 +0200")
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl>
Message-ID: <87podgqi57.fsf@wheatstone.g10code.de>

On Tue,  4 Jul 2017 12:05, johanw at vulcan.xs4all.nl said:

> Is 1.4 vulnerable to this attack as well? I know it ows not use
> libgcrypt but I'm not sure about the vulnerability.

Maybe.  And probably also to a lot of other local side channel attacks.


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: </pipermail/attachments/20170704/fb88ce86/attachment-0001.sig>

From guru at unixarea.de  Tue Jul  4 12:07:33 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 4 Jul 2017 12:07:33 +0200
Subject: scdaemon does not "see" card insertion
Message-ID: <20170704100733.GA5055@c720-r314251>


Hello,

I have now the GnuPG card working fine for signing mails, SSH access and
even for using GnuPG crypted credentials in Firefox. The last issue I'm
struggling with is the use of card removal and card insert via the
'scd-event' to lock and unlock the KDE desktop.

The script 'scd-event' is only invoked on card removal (I do just en
echo of the args):

scd-event --reader-port 0 --old-code 0x0007 --new-code 0x0000 --status NOCARD

A card insert is only seen *after* some agent requires something, for
example the SSH client needs access to the secret key on the card; than
it says:

scd-event --reader-port 0 --old-code 0xFFFFFFFF --new-code 0x0007 --status USABLE

On the UNIX system level the card insert triggers via devd(8) the start
of /usr/local/sbin/pcscd and the card removal triggers a 'killall pcscd'.
This is working fine, i.e. an inserted card is useable immediately, requesting 
the PIN entry.

I created a file scdaemon.conf to get debug information, here is the
resulting log:

...
2017-07-04 11:33:51 scdaemon[4945.802016000] DBG: enter: apdu_get_status: slot=0 hang=0
2017-07-04 11:33:51 scdaemon[4945.802016000] DBG: leave: apdu_get_status => sw=0x0 status=7
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: enter: apdu_get_status: slot=0 hang=0

now the card is removed and /usr/local/sbin/pcscd is killed

2017-07-04 11:33:52 scdaemon[4945.802016000] pcsc_get_status_change failed: no service (0x8010001d)
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: leave: apdu_get_status => sw=0x1000c status=0
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: Removal of a card: 0
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: enter: apdu_close_reader: slot=0
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: enter: apdu_disconnect: slot=0
2017-07-04 11:33:52 scdaemon[4945.802016000] pcsc_disconnect failed: no service (0x8010001d)
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: leave: apdu_disconnect => sw=0x1000a
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: apdu_close_reader => 0x1000a (apdu_disconnect)
2017-07-04 11:33:52 scdaemon[4945.802016000] DBG: leave: apdu_close_reader => 0x0 (close_reader)

now scdaemon sits there, the card was already inserted again, nothing
happens

now SSH needs the key, this awakes scdaemon again and it sees the card:

2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: chan_7 <- SERIALNO
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: enter: apdu_open_reader: portstr=(null)
2017-07-04 11:34:28 scdaemon[4945.802017900] detected reader 'Identiv uTrust 3512 SAM slot Token (55511514602745) 00 00'
2017-07-04 11:34:28 scdaemon[4945.802017900] detected reader ''
2017-07-04 11:34:28 scdaemon[4945.802017900] reader slot 0: not connected
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: leave: apdu_open_reader => slot=0 [pc/sc]
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: enter: apdu_connect: slot=0
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: feature: code=12, len=4, v=42330012
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: TLV properties: tag=01, len=2, v=00000000
2017-07-04 11:34:28 scdaemon[4945.802017900] DBG: TLV properties: tag=03, len=1, v=00000000

What should be changed too let scdaemon see the card insertion?

Thanks

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170704/67040914/attachment.sig>

From johanw at vulcan.xs4all.nl  Tue Jul  4 21:03:50 2017
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Tue, 04 Jul 2017 21:03:50 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <87podgqi57.fsf@wheatstone.g10code.de>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl> <87podgqi57.fsf@wheatstone.g10code.de>
Message-ID: <595BE696.3060404@vulcan.xs4all.nl>

On 04-07-2017 18:30, Werner Koch wrote:

>> Is 1.4 vulnerable to this attack as well? I know it ows not use
>> libgcrypt but I'm not sure about the vulnerability.
> 
> Maybe.  And probably also to a lot of other local side channel attacks.

Is that going to be fixed, or is 1.4 now really considered EOL?

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From peter at digitalbrains.com  Tue Jul  4 21:37:05 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 4 Jul 2017 21:37:05 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <595BE696.3060404@vulcan.xs4all.nl>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl> <87podgqi57.fsf@wheatstone.g10code.de>
 <595BE696.3060404@vulcan.xs4all.nl>
Message-ID: <6e96b94c-b54d-a5c3-0868-32518cb4b86f@digitalbrains.com>

On 04/07/17 21:03, Johan Wevers wrote:
> Is that going to be fixed, or is 1.4 now really considered EOL?

I think you need to see it in the context of this part of the announcement:

> Allowing execute access to a box with private keys should be considered
> as a game over condition, anyway.  Thus in practice there are easier
> ways to access the private keys than to mount this side-channel attack.

If you're worried about cross-VM crypto attacks, perhaps host your essential
crypto on a box that doesn't host potentially hostile VM's. Security has its
cost, or: there's no such thing as a free lunch.

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: </pipermail/attachments/20170704/5e02dec7/attachment.sig>

From sbdisn-gnu at yahoo.com  Tue Jul  4 15:22:37 2017
From: sbdisn-gnu at yahoo.com (S)
Date: Tue, 4 Jul 2017 13:22:37 +0000 (UTC)
Subject: Access denied when using gpg4win via command prompt
References: <1525182026.5111298.1499174557085.ref@mail.yahoo.com>
Message-ID: <1525182026.5111298.1499174557085@mail.yahoo.com>

Hello,
Firstly, let me state right away that I'm a complete newbie.
I've had this software installed for a while now with everything working as intended until a few days back. Although I'm able to access most features via the GUI (Kleopatra and GPA), the command prompt functionality seems to be broken all of a sudden. The issue started with me trying to create a revocation certificate for my personal key.
As you can see in the attached screenshot, a dialog pops up saying 'This app can't run on your PC' with an 'access denied' message in the cmd. Not sure why this is the case when I haven't made any changes to the system or the Gpg4win installation. Now none of the other tasks viz. import key, verification commands work either.
As a workaround, I did try setting the 'smart screen filtering' to off in the settings along with enabling the developer mode but it still doesn't work.
I'm posting this here since you don't get any workable solution on the Windows forums.
My OS : Windows 10 (1607 version)Gpg4win version : 2.33
Any help's appreciated.
Thanks





-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170704/75efdbd4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.JPG
Type: image/jpeg
Size: 62934 bytes
Desc: not available
URL: </pipermail/attachments/20170704/75efdbd4/attachment-0001.jpe>

From gniibe at fsij.org  Wed Jul  5 02:23:06 2017
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 05 Jul 2017 09:23:06 +0900
Subject: scdaemon does not "see" card insertion
In-Reply-To: <20170704100733.GA5055@c720-r314251>
References: <20170704100733.GA5055@c720-r314251>
Message-ID: <87inj7g2ad.fsf@iwagami.gniibe.org>

Hello,

Matthias Apitz <guru at unixarea.de> wrote:
> The script 'scd-event' is only invoked on card removal (I do just en
> echo of the args):
[...]
> A card insert is only seen *after* some agent requires something, for
> example the SSH client needs access to the secret key on the card;

Right.  Scdaemon only watches the event of card removal and card reader
removal.

In the past, once, scdaemon implementation in 2.0 partially tried to
support watching insertion, too.  The name "scdaemon" would have implied
that, perhaps.  We couldn't go this road well, because a card reader is
shared resource and there are valid use cases for other cards.

Then, the development of scdaemon evolved as openpgp-card-helper for
GnuPG.

This focus could stabilize the use case for GnuPG, and it resulted
less conflict for other use cases for card and card reader.

> On the UNIX system level the card insert triggers via devd(8) the start
> of /usr/local/sbin/pcscd and the card removal triggers a 'killall pcscd'.
> This is working fine, i.e. an inserted card is useable immediately, requesting 
> the PIN entry.

IIUC, system level service like devd can only handle the event of card
reader insertion, not card insertion.  I may be wrong here.

I think that it is good for your use case to use PC/SC daemon
and its related tool.

I found a tool named card_eventmgr in:

    https://github.com/OpenSC/pam_pkcs11/tree/master/src/tools/

This may help.  (No, I don't have any experience with this tool.)
-- 


From guru at unixarea.de  Wed Jul  5 08:08:23 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 5 Jul 2017 08:08:23 +0200
Subject: scdaemon does not "see" card insertion
In-Reply-To: <87inj7g2ad.fsf@iwagami.gniibe.org>
References: <20170704100733.GA5055@c720-r314251>
 <87inj7g2ad.fsf@iwagami.gniibe.org>
Message-ID: <20170705060823.GA7586@c720-r314251>

El d?a mi?rcoles, julio 05, 2017 a las 09:23:06a. m. +0900, NIIBE Yutaka escribi?:

> Hello,
> 
> Matthias Apitz <guru at unixarea.de> wrote:
> > The script 'scd-event' is only invoked on card removal (I do just en
> > echo of the args):
> [...]
> > A card insert is only seen *after* some agent requires something, for
> > example the SSH client needs access to the secret key on the card;
> 
> Right.  Scdaemon only watches the event of card removal and card reader
> removal.
> 
> ...

Hello,

Thanks for all explanations. For now I implemented the scd-event script
as:

...

DISPLAY=:0 export DISPLAY
if [ x$status = xNOCARD ]; then
    nohup /usr/local/lib/kde4/libexec/kscreenlocker_greet --immediateLock &
    while true; do
      # Signature key ....: 5E69 FBAC ...
      gpg2 --card-status | grep '5E69 FBAC' >> /tmp/scd-event.log  && {
      killall kscreenlocker_greet
      break
      }
      sleep 1  
    done
fi

which works nice: on card removal it locks the screen and on card insert
it unlocks it fine.

> > On the UNIX system level the card insert triggers via devd(8) the start
> > of /usr/local/sbin/pcscd and the card removal triggers a 'killall pcscd'.
> > This is working fine, i.e. an inserted card is useable immediately, requesting 
> > the PIN entry.
> 
> IIUC, system level service like devd can only handle the event of card
> reader insertion, not card insertion.  I may be wrong here.

No, you are correct, I was inprecise.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170705/f239484f/attachment.sig>

From fuflono at aol.com  Tue Jul  4 22:40:17 2017
From: fuflono at aol.com (fuflono at aol.com)
Date: Tue, 4 Jul 2017 16:40:17 -0400
Subject: Fwd: which program use: gpg or gpgv?
In-Reply-To: <15d0a0b938b-20f-7149@webprd-m39.mail.aol.com>
References: <15d0a0b938b-20f-7149@webprd-m39.mail.aol.com>
Message-ID: <15d0f550815-3c1d-fe95e@webprd-a46.mail.aol.com>


 

 

fuflono at aol.com

 

 

-----Original Message-----
From: fuflono <fuflono at aol.com>
To: gnupg-users <gnupg-users at gnupg.org>
Sent: Mon, Jul 3, 2017 4:01 pm
Subject: which program use: gpg or gpgv?


Hi,
my Debian8.8 has the programs about gpg: 

-rwxr-xr-x  1 root   root    1128700 Sep  3  2016 gpg
-rwxr-xr-x  1 root   root     913236 Sep  3  2016 gpg2
-rwxr-xr-x  1 root   root     334260 Sep  3  2016 gpg-agent
-rwxr-xr-x  1 root   root     148108 Sep  3  2016 gpgconf
-rwxr-xr-x  1 root   root     165508 Sep  3  2016 gpg-connect-agent
-rwxr-xr-x  1 root   root      38144 Sep  3  2016 gpgkey2ssh
-rwxr-xr-x  1 root   root      25908 Sep  3  2016 gpgparsemail
-rwxr-xr-x  1 root   root      59104 Sep  3  2016 gpgsplit
-rwxr-xr-x  1 root   root     407820 Sep  3  2016 gpgv
-rwxr-xr-x  1 root   root       3303 Sep  3  2016 gpg-zip

Are they enough or no, for  verifying integrity of packages?

Also  is  ~/.gnupg
drwx------  2 user user 4096 Aug 13  2016 private-keys-v1.d #it's empty#
-rw-------  1 user user    0 Jun 24 15:34 pubring.gpg
-rw-------  1 user user    0 Jun 28 12:45 secring.gpg
-rw-------  1 user user   40 Jun 30 07:19 trustdb.gpg
user at debian:~/.gnupg$ 

And I don;t know which program use: gpg or gpgv?
------------------------------------------
~/Downloads/screen-4.5.1$ gpg -vv --verify screen-4.5.1.tar.gz.sig screen-4.5.1.tar.gz
gpg: armor: BEGIN PGP SIGNATURE
:signature packet: algo 1, keyid 21F968DEF747ABD7
    version 4, created 1488037815, md5len 0, sigclass 0x00
    digest algo 8, begin of digest 2e ec
    hashed subpkt 33 len 21 (?)
    hashed subpkt 2 len 4 (sig created 2017-02-25)
    subpkt 16 len 8 (issuer key ID 21F968DEF747ABD7)
    data: [4095 bits]
gpg: Signature made Sat 25 Feb 2017 10:50:15 AM EST using RSA key ID F747ABD7
gpg: Can't check signature: public key not found
user at debian:~/Downloads/screen-4.5.1$ 
~/Downloads/screen-4.5.1$ 
--------------------------------------
:~/Downloads/screen-4.5.1$ gpgv -vv screen-4.5.1.tar.gz.sig
gpgv: keyblock resource `/home/user/.gnupg/trustedkeys.gpg': file open error
gpgv: armor: BEGIN PGP SIGNATURE
:signature packet: algo 1, keyid 21F968DEF747ABD7
    version 4, created 1488037815, md5len 0, sigclass 0x00
    digest algo 8, begin of digest 2e ec
    hashed subpkt 33 len 21 (?)
    hashed subpkt 2 len 4 (sig created 2017-02-25)
    subpkt 16 len 8 (issuer key ID 21F968DEF747ABD7)
    data: [4095 bits]
gpgv: no signed data
gpgv: can't hash datafile: file open error
user at debian:~/Downloads/screen-4.5.1$ 
-----------------------------------
I guess don't enough  public keys at me. Please prompt me what to do, and excuse my stupid questions:
While I shall attempt operate with gpg or gpgv, of course there will done some wrong things. May I remove improper files, which will appear? Need I switch on cookies when try get keys? Reminding, me need justl verify screen-4.5.1.tar.gz by  screen-4.5.1.tar.gz.sig ,  I hope learn this program after.
Thanks all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170704/2dc3a5e5/attachment.html>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Jul  5 12:14:12 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 5 Jul 2017 12:14:12 +0200
Subject: Access denied when using gpg4win via command prompt
In-Reply-To: <1525182026.5111298.1499174557085@mail.yahoo.com>
References: <1525182026.5111298.1499174557085.ref@mail.yahoo.com>
 <1525182026.5111298.1499174557085@mail.yahoo.com>
Message-ID: <2e608b2f-6000-ae23-0de3-79fa74e95756@sumptuouscapital.com>

On 07/04/2017 03:22 PM, S via Gnupg-users wrote:


> My OS : Windows 10 (1607 version)Gpg4win version : 2.33
> Any help's appreciated.
> Thanks
> 

You seem to try to output the revocation certificate to
c:\windows\system32 , does the error persist if not outputting to a
system directory?

-- 
----------------------------
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
----------------------------
"History repeats itself; historians repeat each other"
(Philip Guedalla)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170705/51eb6f98/attachment.sig>

From bernhard at intevation.de  Wed Jul  5 16:13:02 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 5 Jul 2017 16:13:02 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <87podgqi57.fsf@wheatstone.g10code.de>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl> <87podgqi57.fsf@wheatstone.g10code.de>
Message-ID: <201707051613.07050.bernhard@intevation.de>

Am Dienstag 04 Juli 2017 18:30:28 schrieb Werner Koch:
> On Tue, ?4 Jul 2017 12:05, johanw at vulcan.xs4all.nl said:
> > Is 1.4 vulnerable to this attack as well? I know it ows not use
> > libgcrypt but I'm not sure about the vulnerability.
>
> Maybe. ?And probably also to a lot of other local side channel attacks.

In general I think it would be useful to have information available that 
shows which versions of GnuPG and libgcrypt are exposed to this or other 
weaknesses and what the consequences are.

People now know which that there are versions
with this vulnerability and without it.

My concept so far:
not vulnerable:
  libgcrypt 1.7.8
  libgcrypt 1.8 -beta since commit
    Thu, 29 Jun 2017 04:11:37 +0200 (11:11 +0900)
    8725c99ffa41778f382ca97233183bcd687bb0ce

vulnerable 
  libgcrypt v<=?
  GnuPG v1.?

Best regards,
Bernhard
-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170705/a43f835e/attachment-0001.sig>

From marcus.brinkmann at ruhr-uni-bochum.de  Wed Jul  5 21:39:26 2017
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Wed, 5 Jul 2017 21:39:26 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <201707051613.07050.bernhard@intevation.de>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl> <87podgqi57.fsf@wheatstone.g10code.de>
 <201707051613.07050.bernhard@intevation.de>
Message-ID: <d3ce8d67-003e-de61-b24b-a2ea3af20968@ruhr-uni-bochum.de>

On 07/05/2017 04:13 PM, Bernhard Reiter wrote:
> Am Dienstag 04 Juli 2017 18:30:28 schrieb Werner Koch:
>> On Tue,  4 Jul 2017 12:05, johanw at vulcan.xs4all.nl said:
>>> Is 1.4 vulnerable to this attack as well? I know it ows not use
>>> libgcrypt but I'm not sure about the vulnerability.
>>
>> Maybe.  And probably also to a lot of other local side channel attacks.
>
> In general I think it would be useful to have information available that
> shows which versions of GnuPG and libgcrypt are exposed to this or other
> weaknesses and what the consequences are.
>
> People now know which that there are versions
> with this vulnerability and without it.
>
> My concept so far:
> not vulnerable:
>   libgcrypt 1.7.8
>   libgcrypt 1.8 -beta since commit
>     Thu, 29 Jun 2017 04:11:37 +0200 (11:11 +0900)
>     8725c99ffa41778f382ca97233183bcd687bb0ce
>
> vulnerable

Caveat: I have only looked at the code of the oldest and newest
versions.  Remember that old versions may not even have 64-bit support,
so they run on different CPU architectures.  But the code is essentially
the same as the vulnerable code in libgcrypt 1.7.7 for these:

>   libgcrypt v<=?

Probably all versions up to 1.7.7, starting from at least 1.2.0 (which
is the oldest I could find).

>   GnuPG v1.?

Probably all versions from 1.0.4 up to 1.4.21.  (I could not find 1.0.3,
which according to the NEWS file is the first version with RSA support).

I made a backport of the patch for GPG 1.4.21 here:

https://dev.gnupg.org/D438

I have also found a paper that indicates that the exponent blinding
defense is not as solid as one might think naively, and in which the
author indicates that OpenSSL defended against these kind of attacks
conclusively in 0.9.8f (Oct 2007). I have only glanced over the claims,
but it's certainly intriguing:

Schindler, W.: Exclusive Exponent Blinding May Not Suffice
to Prevent Timing Attacks on RSA (2015), Bundesamt f?r Sicherheit in der
Informationstechnik

Preprint available at https://eprint.iacr.org/2014/869.pdf





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170705/7b13b067/attachment.sig>

From dkg at fifthhorseman.net  Thu Jul  6 02:56:56 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 05 Jul 2017 20:56:56 -0400
Subject: Fwd: which program use: gpg or gpgv?
In-Reply-To: <15d0f550815-3c1d-fe95e@webprd-a46.mail.aol.com>
References: <15d0a0b938b-20f-7149@webprd-m39.mail.aol.com>
 <15d0f550815-3c1d-fe95e@webprd-a46.mail.aol.com>
Message-ID: <871spus7qf.fsf@fifthhorseman.net>

On Tue 2017-07-04 16:40:17 -0400, fuflono--- via Gnupg-users wrote:
> Hi,
> my Debian8.8 has the programs about gpg: 
>
> -rwxr-xr-x  1 root   root    1128700 Sep  3  2016 gpg
> -rwxr-xr-x  1 root   root     913236 Sep  3  2016 gpg2
> -rwxr-xr-x  1 root   root     334260 Sep  3  2016 gpg-agent
> -rwxr-xr-x  1 root   root     148108 Sep  3  2016 gpgconf
> -rwxr-xr-x  1 root   root     165508 Sep  3  2016 gpg-connect-agent
> -rwxr-xr-x  1 root   root      38144 Sep  3  2016 gpgkey2ssh
> -rwxr-xr-x  1 root   root      25908 Sep  3  2016 gpgparsemail
> -rwxr-xr-x  1 root   root      59104 Sep  3  2016 gpgsplit
> -rwxr-xr-x  1 root   root     407820 Sep  3  2016 gpgv
> -rwxr-xr-x  1 root   root       3303 Sep  3  2016 gpg-zip
>
> Are they enough or no, for  verifying integrity of packages?

more recent versions of debian will use gpgv for verifying integrity of
downloaded system packages, and do not need gpg itself for this purpose.

If you want to verify packages signed by other developers, you'll need
to get their keys, though, and that requires knowing their keys.

According to the versions at https://ftp.gnu.org/gnu/screen/, it looks
screen 4.5.1 has been signed with key
0x71AA09D9E8870FDB0AA7B61E21F968DEF747ABD7, while the most recent
version of screen (4.6.0) has been signed with
0x2EE59A5D0C50167B5535BBF1B708A383C53EF3A4.

Which of these keys is a legitimate key to validate versions of screen?
I don't know!  They're both listed in
https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=screen
though, so perhaps they're both acceptable.


If you fetch the maintainers' file from savannah, and convert it into an
OpenPGP binary form, you should be able to validate the screen package
against it:

    wget -O screen-keys.asc 'https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=screen&download=1'
    gpg --dearmor < screen-keys.asc > screen-keys.gpg

    wget https://ftp.gnu.org/gnu/screen/screen-4.5.1.tar.gz https://ftp.gnu.org/gnu/screen/screen-4.5.1.tar.gz.sig
    gpgv --keyring $(pwd)/screen-keys.gpg screen-4.5.1.tar.gz.sig screen-4.5.1.tar.gz


This should show you something like:

    gpgv: Signature made Sat 25 Feb 2017 10:50:15 AM EST
    gpgv:                using RSA key 71AA09D9E8870FDB0AA7B61E21F968DEF747ABD7
    gpgv: Good signature from "Alexander Naumov <alexander_naumov at opensuse.org>"

Note, however, that you've only moved the responsibility from verifying
the package to verifying which keys actually are the legitimate keys for
the maintainers of GNU screen.  So it's a win, but it's not perfect.

hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170705/fb95ffd2/attachment.sig>

From skquinn at rushpost.com  Thu Jul  6 03:32:23 2017
From: skquinn at rushpost.com (Shawn K. Quinn)
Date: Wed, 5 Jul 2017 20:32:23 -0500
Subject: Fwd: which program use: gpg or gpgv?
In-Reply-To: <15d0f550815-3c1d-fe95e@webprd-a46.mail.aol.com>
References: <15d0a0b938b-20f-7149@webprd-m39.mail.aol.com>
 <15d0f550815-3c1d-fe95e@webprd-a46.mail.aol.com>
Message-ID: <e8f5aa52-6069-e7ff-b43e-0910ab34c7db@rushpost.com>

On 07/04/2017 03:40 PM, fuflono--- via Gnupg-users wrote:
> -----Original Message-----
> From: fuflono <fuflono at aol.com>
> To: gnupg-users <gnupg-users at gnupg.org>
> Sent: Mon, Jul 3, 2017 4:01 pm
> Subject: which program use: gpg or gpgv?
> 
> Hi,
> my Debian8.8 has the programs about gpg:
> 
> -rwxr-xr-x  1 root   root    1128700 Sep  3  2016 gpg
> -rwxr-xr-x  1 root   root     913236 Sep  3  2016 gpg2
> -rwxr-xr-x  1 root   root     334260 Sep  3  2016 gpg-agent
> -rwxr-xr-x  1 root   root     148108 Sep  3  2016 gpgconf
> -rwxr-xr-x  1 root   root     165508 Sep  3  2016 gpg-connect-agent
> -rwxr-xr-x  1 root   root      38144 Sep  3  2016 gpgkey2ssh
> -rwxr-xr-x  1 root   root      25908 Sep  3  2016 gpgparsemail
> -rwxr-xr-x  1 root   root      59104 Sep  3  2016 gpgsplit
> -rwxr-xr-x  1 root   root     407820 Sep  3  2016 gpgv
> -rwxr-xr-x  1 root   root       3303 Sep  3  2016 gpg-zip
> 
> Are they enough or no, for  verifying integrity of packages?
> 
> Also  is  ~/.gnupg
> drwx------  2 user user 4096 Aug 13  2016 private-keys-v1.d #it's empty#
> -rw-------  1 user user    0 Jun 24 15:34 pubring.gpg
> -rw-------  1 user user    0 Jun 28 12:45 secring.gpg
> -rw-------  1 user user   40 Jun 30 07:19 trustdb.gpg
> user at debian:~/.gnupg$
> 
> And I don;t know which program use: gpg or gpgv?
> ------------------------------------------
> ~/Downloads/screen-4.5.1$ gpg -vv --verify screen-4.5.1.tar.gz.sig
> screen-4.5.1.tar.gz
> gpg: armor: BEGIN PGP SIGNATURE
> :signature packet: algo 1, keyid 21F968DEF747ABD7
>     version 4, created 1488037815, md5len 0, sigclass 0x00
>     digest algo 8, begin of digest 2e ec
>     hashed subpkt 33 len 21 (?)
>     hashed subpkt 2 len 4 (sig created 2017-02-25)
>     subpkt 16 len 8 (issuer key ID 21F968DEF747ABD7)
>     data: [4095 bits]
> gpg: Signature made Sat 25 Feb 2017 10:50:15 AM EST using RSA key ID
> F747ABD7
> gpg: Can't check signature: public key not found
> user at debian:~/Downloads/screen-4.5.1$
> ~/Downloads/screen-4.5.1$

This means you do not have the correct key in pubring.gpg where the main
gpg executable is expecting it. As pubring.gpg is a zero byte file, this
is entirely to be expected. To fix this, add the appropriate keys.

> --------------------------------------
> :~/Downloads/screen-4.5.1$ gpgv -vv screen-4.5.1.tar.gz.sig
> gpgv: keyblock resource `/home/user/.gnupg/trustedkeys.gpg': file open error
> gpgv: armor: BEGIN PGP SIGNATURE
> :signature packet: algo 1, keyid 21F968DEF747ABD7
>     version 4, created 1488037815, md5len 0, sigclass 0x00
>     digest algo 8, begin of digest 2e ec
>     hashed subpkt 33 len 21 (?)
>     hashed subpkt 2 len 4 (sig created 2017-02-25)
>     subpkt 16 len 8 (issuer key ID 21F968DEF747ABD7)
>     data: [4095 bits]
> gpgv: no signed data
> gpgv: can't hash datafile: file open error
> user at debian:~/Downloads/screen-4.5.1$
> -----------------------------------

The first line means there is no trustedkeys.gpg keyring. This is the
keyring that gpgv uses. Unlike the main gpg program, it assumes
everything on that keyring is a valid and fully trustable key.

Which one you decide to use to verify packages is ultimately a matter of
personal choice. If you wish to keep a separate keyring for the purpose
of verifying signatures on certain files such as software releases, then
perhaps gpgv is the better choice. If you think that's overkill and you
are content with one keyring for both correspondence and signature
verification, then the main gpg program will do. Debian itself uses gpgv
to verify updates but there is a specific reason for this, that being
that the apt and dpkg tools used by most users never need to sign or
encrypt anything, only verify signatures.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170705/4261d9f3/attachment.sig>

From bernhard at intevation.de  Thu Jul  6 11:34:45 2017
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 6 Jul 2017 11:34:45 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <d3ce8d67-003e-de61-b24b-a2ea3af20968@ruhr-uni-bochum.de>
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <201707051613.07050.bernhard@intevation.de>
 <d3ce8d67-003e-de61-b24b-a2ea3af20968@ruhr-uni-bochum.de>
Message-ID: <201707061134.46221.bernhard@intevation.de>

Am Mittwoch 05 Juli 2017 21:39:26 schrieb Marcus Brinkmann via Gnupg-users:
> Caveat: I have only looked at the code of the oldest and newest
> versions.  Remember that old versions may not even have 64-bit support,
> so they run on different CPU architectures.  But the code is essentially
> the same as the vulnerable code in libgcrypt 1.7.7 for these:

> Probably all versions up to 1.7.7, starting from at least 1.2.0 (which
> is the oldest I could find).

Thanks for your useful examinations.

> >   GnuPG v1.?
> Probably all versions from 1.0.4 up to 1.4.21.  (I could not find 1.0.3,
> which according to the NEWS file is the first version with RSA support).
>
> I made a backport of the patch for GPG 1.4.21 here:
> https://dev.gnupg.org/D438

Yes good, though Werner' s comment there shows that there will be more things 
to consider.

Like:

> I have also found a paper that indicates that the exponent blinding
> defense is not as solid as one might think naively,

> Preprint available at https://eprint.iacr.org/2014/869.pdf

To my conculsion for users so far is:
The side-channel attack from CVE-2017-7526 and related side-channel attacks
and implementation fixes are under active examination by the GnuPG-Dev team.

My current understanding:
To prevent exploitation for GnuPG 1.4: prevent other users on the machine.
To be extra sure: Do not share a machine by VMs (unless they are well 
separated.)
For GnuPG 2.1: Update to a version using libgcrypt 1.7.8 or later
(or alternatively apply the same measures as for GnuPG 1.4).

We should take in depth discussions to gnupg-devel@ I guess.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170706/39df3827/attachment.sig>

From aheinlein at gmx.com  Thu Jul  6 12:30:55 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 6 Jul 2017 12:30:55 +0200
Subject: Questions using GPGME
Message-ID: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>

Hello,

I am currently taking first steps using GPGME with the Python interface.
I am facing two questions:

1.) I'm looking for a way to get the recipients of encrypted data which
I can not/do not want to decrypt. I.e. a message for which I do not have
the private key. Enigmail tells me "This message was encrypted for ..."
in such cases, and the gpg command line does the same. Is this possible
with GPGME? Calling 'decrypt' just raises a GPGMEError in this case and
does not return a result.

2.) Is there a way to safely distinguish "User clicked cancel when asked
for the passphrase" from other errors? I think an application should
abort silently in this case, but I'm getting another GPGMEError without
any clue to the reason.

I wonder if these are just problems with the python interface or if the
functionality is missing from libgpgme. I am currently using gpgme 1.8.0
because that's what is packaged with Debian 9, but if you tell me I need
to upgrade, I will ;-)

Thanks,
Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170706/0043716e/attachment-0001.sig>

From justus at g10code.com  Thu Jul  6 14:01:34 2017
From: justus at g10code.com (Justus Winter)
Date: Thu, 06 Jul 2017 14:01:34 +0200
Subject: Questions using GPGME
In-Reply-To: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
References: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
Message-ID: <87h8ypai5d.fsf@europa.jade-hamburg.de>

Hi :)

Andreas Heinlein <aheinlein at gmx.com> writes:

> I am currently taking first steps using GPGME with the Python interface.
> I am facing two questions:
>
> 1.) I'm looking for a way to get the recipients of encrypted data which
> I can not/do not want to decrypt. I.e. a message for which I do not have
> the private key. Enigmail tells me "This message was encrypted for ..."
> in such cases, and the gpg command line does the same. Is this possible
> with GPGME? Calling 'decrypt' just raises a GPGMEError in this case and
> does not return a result.

This is indeed a shortcoming of the Python bindings.  I will address this.

> 2.) Is there a way to safely distinguish "User clicked cancel when asked
> for the passphrase" from other errors? I think an application should
> abort silently in this case, but I'm getting another GPGMEError without
> any clue to the reason.

Maybe.  GPGMEError is a very general error, this is a bit of pyme
legacy.  You can inspect the error code using .getcode().  For a quick
check, try to str() the error.


Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170706/d9043965/attachment.sig>

From aheinlein at gmx.com  Thu Jul  6 14:48:47 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 6 Jul 2017 14:48:47 +0200
Subject: Questions using GPGME
In-Reply-To: <87h8ypai5d.fsf@europa.jade-hamburg.de>
References: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
 <87h8ypai5d.fsf@europa.jade-hamburg.de>
Message-ID: <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com>

Am 06.07.2017 um 14:01 schrieb Justus Winter:
>> 2.) Is there a way to safely distinguish "User clicked cancel when asked
>> for the passphrase" from other errors? I think an application should
>> abort silently in this case, but I'm getting another GPGMEError without
>> any clue to the reason.
> Maybe.  GPGMEError is a very general error, this is a bit of pyme
> legacy.  You can inspect the error code using .getcode().  For a quick
> check, try to str() the error.
Thank you for the quick answer. I gave it a try with 3 tests, one
decrypt with cancel'ing the pinentry, one with missing private key and
one with a truncated input file. All three gave

print str(e): Invocation of gpgme_op_decrypt_verify: GPGME: Decryption
failed
print e.getcode(): 152

So this doesn't help. But good to know someone is working on this; I'd
be happy to help where I can. I am not a C developer, though, but I
could test if neccessary.

Bye,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170706/c5abfa87/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170706/c5abfa87/attachment.sig>

From sbdisn-gnu at yahoo.com  Thu Jul  6 14:50:28 2017
From: sbdisn-gnu at yahoo.com (S)
Date: Thu, 6 Jul 2017 12:50:28 +0000 (UTC)
Subject: Option to select "Which topic categories would you like to
 subscribe to?" under Gnupg-users Subscription Options
References: <699176742.6980354.1499345428327.ref@mail.yahoo.com>
Message-ID: <699176742.6980354.1499345428327@mail.yahoo.com>

Hello,
Apologies for having to ask this. Didn't find any options in the relevant page.
I would like to receive messages only for topics I'm subscribed to. But, I don't see an option to select topics of my choice either in "Gnupg-users mailing list membership configuration" page or in the concerned mailing lists page "https://lists.gnupg.org/pipermail/".
I would like to know where I can select topics for message filtering. As of now, I receive every mail transacted under the chosen mailing list.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170706/f52193d8/attachment.html>

From sbdisn-gnu at yahoo.com  Thu Jul  6 14:39:39 2017
From: sbdisn-gnu at yahoo.com (S)
Date: Thu, 6 Jul 2017 12:39:39 +0000 (UTC)
Subject: Fw: Access denied when using gpg4win via command prompt
In-Reply-To: <198584031.6210786.1499279330239@mail.yahoo.com>
References: <1525182026.5111298.1499174557085.ref@mail.yahoo.com>
 <1525182026.5111298.1499174557085@mail.yahoo.com>
 <2e608b2f-6000-ae23-0de3-79fa74e95756@sumptuouscapital.com>
 <198584031.6210786.1499279330239@mail.yahoo.com>
Message-ID: <236309691.6998138.1499344779358@mail.yahoo.com>



     
----- Forwarded Message -----
 From: S <sbdisn-gnu at yahoo.com>
 To: Kristian Fiskerstrand <kristian.fiskerstrand at sumptuouscapital.com> 
 Sent: Wednesday, 5 July 2017 6:28 PM
 Subject: Re: Access denied when using gpg4win via command prompt
   
@Kristian Fiskerstrand: Yes, I still get the the error no matter what. And, it's not just with revocation certificate. Nothing works now be it import/verify fingerprint/Sha etc.



      From: Kristian Fiskerstrand <kristian.fiskerstrand at sumptuouscapital.com>
 To: S <sbdisn-gnu at yahoo.com>; "gnupg-users at gnupg.org" <gnupg-users at gnupg.org> 
 Sent: Wednesday, 5 July 2017 10:14 AM
 Subject: Re: Access denied when using gpg4win via command prompt
  
On 07/04/2017 03:22 PM, S via Gnupg-users wrote:


> My OS : Windows 10 (1607 version)Gpg4win version : 2.33
> Any help's appreciated.
> Thanks
> 

You seem to try to output the revocation certificate to
c:\windows\system32 , does the error persist if not outputting to a
system directory?

-- 
----------------------------
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
----------------------------
"History repeats itself; historians repeat each other"
(Philip Guedalla)


   

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170706/c9db02e5/attachment.html>

From justus at g10code.com  Thu Jul  6 16:01:47 2017
From: justus at g10code.com (Justus Winter)
Date: Thu, 06 Jul 2017 16:01:47 +0200
Subject: Questions using GPGME
In-Reply-To: <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com>
References: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
 <87h8ypai5d.fsf@europa.jade-hamburg.de>
 <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com>
Message-ID: <87efttacl0.fsf@europa.jade-hamburg.de>

Andreas Heinlein <aheinlein at gmx.com> writes:

> Am 06.07.2017 um 14:01 schrieb Justus Winter:
>>> 2.) Is there a way to safely distinguish "User clicked cancel when asked
>>> for the passphrase" from other errors? I think an application should
>>> abort silently in this case, but I'm getting another GPGMEError without
>>> any clue to the reason.
>> Maybe.  GPGMEError is a very general error, this is a bit of pyme
>> legacy.  You can inspect the error code using .getcode().  For a quick
>> check, try to str() the error.
> Thank you for the quick answer. I gave it a try with 3 tests, one
> decrypt with cancel'ing the pinentry, one with missing private key and
> one with a truncated input file. All three gave
>
> print str(e): Invocation of gpgme_op_decrypt_verify: GPGME: Decryption
> failed
> print e.getcode(): 152
>
> So this doesn't help.

Well, then it is not python-gpg's fault, but the underlying library or
components do not differentiate that.

> But good to know someone is working on this

I'm not.  If you feel that this is important, please file a bug.


Cheers,
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170706/99b4314c/attachment-0001.sig>

From mirimir at riseup.net  Thu Jul  6 15:01:58 2017
From: mirimir at riseup.net (Mirimir)
Date: Thu, 6 Jul 2017 02:01:58 -1100
Subject: Option to select "Which topic categories would you like to
 subscribe to?" under Gnupg-users Subscription Options
In-Reply-To: <699176742.6980354.1499345428327@mail.yahoo.com>
References: <699176742.6980354.1499345428327.ref@mail.yahoo.com>
 <699176742.6980354.1499345428327@mail.yahoo.com>
Message-ID: <6679a11d-d258-096a-9857-16a33895038b@riseup.net>

On 07/06/2017 01:50 AM, S via Gnupg-users wrote:
> Hello,
> Apologies for having to ask this. Didn't find any options in the relevant page.
> I would like to receive messages only for topics I'm subscribed to. But, I don't see an option to select topics of my choice either in "Gnupg-users mailing list membership configuration" page or in the concerned mailing lists page "https://lists.gnupg.org/pipermail/".
> I would like to know where I can select topics for message filtering. As of now, I receive every mail transacted under the chosen mailing list.
> 
> Thanks

You need to handle that locally, I believe.


From aheinlein at gmx.com  Thu Jul  6 17:14:16 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 6 Jul 2017 17:14:16 +0200
Subject: Option to select "Which topic categories would you like to
 subscribe to?" under Gnupg-users Subscription Options
In-Reply-To: <699176742.6980354.1499345428327@mail.yahoo.com>
References: <699176742.6980354.1499345428327.ref@mail.yahoo.com>
 <699176742.6980354.1499345428327@mail.yahoo.com>
Message-ID: <ab447183-7776-0783-8171-085b47fb8360@gmx.com>

Am 06.07.2017 um 14:50 schrieb S via Gnupg-users:
> Hello,
>
> Apologies for having to ask this. Didn't find any options in the
> relevant page.
>
> I would like to receive messages only for topics I'm subscribed to.
> But, I don't see an option to select topics of my choice either in
> "/Gnupg-users mailing list membership configuration/" page or in the
> concerned mailing lists page "/https://lists.gnupg.org/pipermail//".
> *
> *
> Iwould like to know where I can select topics for message filtering.
> As of now, I receive every mail transacted under the chosen mailing list.*
> *
> *
> *
> Thanks
*I don't think the mailing list software could handle this. Thunderbird
can ignore and hide topics, so you would have to 'opt-out' of every new
topic.

Bye,
Andreas
*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170706/c16e08a3/attachment.sig>

From sbdisn-gnu at yahoo.com  Thu Jul  6 18:17:41 2017
From: sbdisn-gnu at yahoo.com (S)
Date: Thu, 6 Jul 2017 16:17:41 +0000 (UTC)
Subject: Option to select "Which topic categories would you like to
 subscribe to?" under Gnupg-users Subscription Options
In-Reply-To: <ab447183-7776-0783-8171-085b47fb8360@gmx.com>
References: <699176742.6980354.1499345428327.ref@mail.yahoo.com>
 <699176742.6980354.1499345428327@mail.yahoo.com>
 <ab447183-7776-0783-8171-085b47fb8360@gmx.com>
Message-ID: <1999979884.7101243.1499357861140@mail.yahoo.com>

Thanks for the reply.
That's exactly I would like to know as to how to do i.e, either 'opt-in' or 'opt-out'. I still don't see either option in the config page. May be I'm missing something. Also, I have no experience with Thunderbird and I'm transacting through Yahoo-mail.

      From: Andreas Heinlein <aheinlein at gmx.com>
 To: gnupg-users at gnupg.org 
 Sent: Thursday, 6 July 2017 3:57 PM
 Subject: Re: Option to select "Which topic categories would you like to subscribe to?" under Gnupg-users Subscription Options
   
Am 06.07.2017 um 14:50 schrieb S via Gnupg-users:
> Hello,
>
> Apologies for having to ask this. Didn't find any options in the
> relevant page.
>
> I would like to receive messages only for topics I'm subscribed to.
> But, I don't see an option to select topics of my choice either in
> "/Gnupg-users mailing list membership configuration/" page or in the
> concerned mailing lists page "/https://lists.gnupg.org/pipermail//".
> *
> *
> Iwould like to know where I can select topics for message filtering.
> As of now, I receive every mail transacted under the chosen mailing list.*
> *
> *
> *
> Thanks
*I don't think the mailing list software could handle this. Thunderbird
can ignore and hide topics, so you would have to 'opt-out' of every new
topic.

Bye,
Andreas
*
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170706/38bc8be3/attachment.html>

From neal at walfield.org  Thu Jul  6 21:19:23 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 06 Jul 2017 21:19:23 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87efubkmng.fsf@mithlond.arda>
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org> <87efubkmng.fsf@mithlond.arda>
Message-ID: <8760f5weys.wl-neal@walfield.org>

At Fri, 23 Jun 2017 13:45:39 +0300,
Teemu Likonen wrote:
> I don't know whether my thinking is common but perhaps it would be
> helpful if gpg's man page made clear that on conflict situation both
> keys go to "ask" mode. A quote from my gpg 2.1.18 manual:

I tried to improve the documentation in 243b2a570.  Thanks for the
suggestion.

:) Neal


From sbdisn-gnu at yahoo.com  Fri Jul  7 18:16:27 2017
From: sbdisn-gnu at yahoo.com (S)
Date: Fri, 7 Jul 2017 16:16:27 +0000 (UTC)
Subject: Access denied when using gpg4win via command prompt
In-Reply-To: <2e608b2f-6000-ae23-0de3-79fa74e95756@sumptuouscapital.com>
References: <1525182026.5111298.1499174557085.ref@mail.yahoo.com>
 <1525182026.5111298.1499174557085@mail.yahoo.com>
 <2e608b2f-6000-ae23-0de3-79fa74e95756@sumptuouscapital.com>
Message-ID: <1309541135.859801.1499444187090@mail.yahoo.com>

Hello,
Just wanted to update the status of my issue. It turns out there was an issue with my gpg4win installation. Tried a reinstall and everything's back in order. I could create a revocation certificate via cmd, however, this time to a local directory and not the windows dir. 

The 'access denied' problem began upon me trying to create the certificate to the default dir.? I had assumed the output dir path would be the local user path (C:\Users\AppData\Roaming\gnupg), which wasn't the case.
Thanks


      From: Kristian Fiskerstrand <kristian.fiskerstrand at sumptuouscapital.com>
 To: S <sbdisn-gnu at yahoo.com>; "gnupg-users at gnupg.org" <gnupg-users at gnupg.org> 
 Sent: Wednesday, 5 July 2017 10:14 AM
 Subject: Re: Access denied when using gpg4win via command prompt
   
On 07/04/2017 03:22 PM, S via Gnupg-users wrote:


> My OS : Windows 10 (1607 version)Gpg4win version : 2.33
> Any help's appreciated.
> Thanks
> 

You seem to try to output the revocation certificate to
c:\windows\system32 , does the error persist if not outputting to a
system directory?

-- 
----------------------------
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
----------------------------
"History repeats itself; historians repeat each other"
(Philip Guedalla)


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170707/ac22c8c2/attachment.html>

From guru at unixarea.de  Mon Jul 10 09:09:58 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 10 Jul 2017 09:09:58 +0200
Subject: storing PINs of credit / EC cards with GnuPG
Message-ID: <20170710070958.GA13027@c720-r314251>


Hello,

This question is perhaps only for German users of GnuPG. In the past
German banks and credit institutes prohibited the storing of PIN numbers
etc. on personal computer systems, even claiming that in the case of storing
they would not have been responsible anymore for the abuse of stolen
credit cards.

What is the current situation about this issue in the German law if such
PIN numbers are stored ciphered with GnuPG?

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170710/e8867aa9/attachment-0001.sig>

From gnupg-user at niob.at  Fri Jul  7 18:01:03 2017
From: gnupg-user at niob.at (gnupg-user at niob.at)
Date: Fri, 7 Jul 2017 18:01:03 +0200
Subject: gpgme - raw RSA operation using GPG public/private keys?
Message-ID: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>

Hello everybody!

I am looking for a "simple" way to use a GPG public/private RSA key to
do "raw" RSA operations. I have the impression, that gpgme only deals
with "real" OpenPGP data structures, but this does not fit my use case.
This is for an application that is currently based on openssl crypto.

I do have a "plan-b" if there is no simpler way, but given the gpgme,
libgcrypt ecosystem (which I have not really used before) I hope that I
will not have to use this:

  * use gpgme to access gnupg keyrings
  * "export" a key using as an OpenPGP key into an in-memory buffer
  * parse this key from the buffer - extracting RSA numbers
  * put the RSA values into an openssl RSA key structure
  * do the crypto using openssl

This does work - I tested this up to the fourth bullet... but there
surely must be a better way.... however, looking at the gpgme docs I can
find no obvious candidates for RSA operations - gpgme_op_encrypt does
not what I need, as it constructs a PGP message, where I assume it uses
a session key and encrypts that using RSA...


peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170707/adcedc54/attachment.html>

From jhs at berklix.com  Mon Jul 10 13:50:42 2017
From: jhs at berklix.com (Julian H. Stacey)
Date: Mon, 10 Jul 2017 13:50:42 +0200
Subject: storing PINs of credit / EC cards with GnuPG
In-Reply-To: Your message "Mon, 10 Jul 2017 09:09:58 +0200."
 <20170710070958.GA13027@c720-r314251>
Message-ID: <201707101150.v6ABog9B075773@fire.js.berklix.net>

> Hello,
> This question is perhaps only for German users of GnuPG. In the past
> German banks and credit institutes prohibited the storing of PIN numbers
> etc. on personal computer systems, even claiming that in the case of storing
> they would not have been responsible anymore for the abuse of stolen
> credit cards.
> 
> What is the current situation about this issue in the German law if such
> PIN numbers are stored ciphered with GnuPG?
> 
> Thanks
> 
> 	matthias

Hi Matthias cc gnupg-users@
Others that might know: German SAGE (Sys Admin Guild)
	http://guug.de/sage/index.html
1.5 hours back I posted to SAGE/Munich suggesting a beer garden tonight.
	https://lists.guug.de/cgi-bin/mailman/listinfo/sage-muc

Cheers,
Julian
-- 
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#700k_stolen_votes


From guanx.bac at gmail.com  Mon Jul 10 17:42:12 2017
From: guanx.bac at gmail.com (Guan Xin)
Date: Mon, 10 Jul 2017 23:42:12 +0800
Subject: Changing PINs of German bank card
Message-ID: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>

This is probably a general question --

I have never seen a German bank that allows changing the PIN of a card.
So I wonder if it is because using a fixed (non-changeable) 4-digit PIN
mailed in clear text really safer than using a 4 to 6 digit variable length
PIN that never explicitly appears anywhere.

If German banks are right, then should I follow their method and store the
PINs of my OpenPGP cards on a piece of paper?

Guan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170710/f3044bfb/attachment.html>

From kloecker at kde.org  Mon Jul 10 19:38:54 2017
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Mon, 10 Jul 2017 19:38:54 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
Message-ID: <2169887.G3JAZmPBVB@thufir>

On Monday 10 July 2017 23:42:12 Guan Xin wrote:
> This is probably a general question --
> 
> I have never seen a German bank that allows changing the PIN of a
> card. So I wonder if it is because using a fixed (non-changeable)
> 4-digit PIN mailed in clear text really safer than using a 4 to 6
> digit variable length PIN that never explicitly appears anywhere.

... and that would very often be either 1234[56] or the card owner's 
date of birth as we all know. A random 4-digit PIN randomly chosen by 
the bank is certainly safer than this.


> If German banks are right, then should I follow their method and store
> the PINs of my OpenPGP cards on a piece of paper?

German banks require you to destroy the PIN letter after memorizing the 
PIN. You are not supposed to keep the letter. If you want to follow 
their method then write your PIN on a piece of paper, memorize the PIN 
and then burn or eat the piece of paper. ;-)


Regards,
Ingo



From guru at unixarea.de  Mon Jul 10 19:52:03 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 10 Jul 2017 19:52:03 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
Message-ID: <20170710175203.GA3647@c720-r314251>

El d?a lunes, julio 10, 2017 a las 11:42:12p. m. +0800, Guan Xin escribi?:

> This is probably a general question --
> 
> I have never seen a German bank that allows changing the PIN of a card.
> So I wonder if it is because using a fixed (non-changeable) 4-digit PIN
> mailed in clear text really safer than using a 4 to 6 digit variable length
> PIN that never explicitly appears anywhere.

Nowadays some German banks allow changing the PIN in the Teller
Machines. I saw it today in an ATM of the Sparkasse. Amex allows (or 
allowed) requesting a new personal PIN by fax.

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170710/ebc1d36d/attachment.sig>

From htd+ml at fritha.org  Mon Jul 10 20:00:48 2017
From: htd+ml at fritha.org (Heinz Diehl)
Date: Mon, 10 Jul 2017 20:00:48 +0200
Subject: storing PINs of credit / EC cards with GnuPG
In-Reply-To: <20170710070958.GA13027@c720-r314251>
References: <20170710070958.GA13027@c720-r314251>
Message-ID: <20170710180048.GA7619@fritha.org>

On 10.07.2017, Matthias Apitz wrote: 

> This question is perhaps only for German users of GnuPG. In the past
> German banks and credit institutes prohibited the storing of PIN numbers
> etc. on personal computer systems

Does anybody care?

> even claiming that in the case of storing
> they would not have been responsible anymore for the abuse of stolen
> credit cards.

..what still has to be proofed in case this happens.

> What is the current situation about this issue in the German law if such
> PIN numbers are stored ciphered with GnuPG?

If storing the PIN on personal computers is prohibited, then... it's
prohibited.

Cheers, Heinz (not living in Germany and storing all PINs within a
password manager)



From gnupg-users.dirk at o.banes.ch  Mon Jul 10 21:24:28 2017
From: gnupg-users.dirk at o.banes.ch (gnupg-users.dirk at o.banes.ch)
Date: Mon, 10 Jul 2017 21:24:28 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <20170710175203.GA3647@c720-r314251>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <20170710175203.GA3647@c720-r314251>
Message-ID: <18b91b36-a933-7e55-ada7-2e465fe1c493@o.banes.ch>

since german bankingcards / even girocard should comply to EMV Standard
a change of PIN via Issuer Script should be possible - if the issuer -
your bank - supports it.

FYI: You have to change the PIN in the Card for offline validation  and
the PIN stored in the issuers backed.

In e.g. switerland it is normal to change your PIN - which is most time
6 Digits long.

best regards

Dirk

On 10.07.2017 19:52, Matthias Apitz wrote:
> El d?a lunes, julio 10, 2017 a las 11:42:12p. m. +0800, Guan Xin escribi?:
>
>> This is probably a general question --
>>
>> I have never seen a German bank that allows changing the PIN of a card.
>> So I wonder if it is because using a fixed (non-changeable) 4-digit PIN
>> mailed in clear text really safer than using a 4 to 6 digit variable length
>> PIN that never explicitly appears anywhere.
> Nowadays some German banks allow changing the PIN in the Teller
> Machines. I saw it today in an ATM of the Sparkasse. Amex allows (or 
> allowed) requesting a new personal PIN by fax.
>
> 	matthias
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users




From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jul 11 01:38:56 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 11 Jul 2017 00:38:56 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <18b91b36-a933-7e55-ada7-2e465fe1c493@o.banes.ch>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <20170710175203.GA3647@c720-r314251>
 <18b91b36-a933-7e55-ada7-2e465fe1c493@o.banes.ch>
Message-ID: <1911145169.20170711003856@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Monday 10 July 2017 at 8:24:28 PM, in
<mid:18b91b36-a933-7e55-ada7-2e465fe1c493 at o.banes.ch>,
gnupg-users.dirk at o.banes.ch wrote:-


> In e.g. switerland it is normal to change your PIN -
> which is most time
> 6 Digits long.

In the UK bank card PINs are almost exclusively 4 digits long. The
bank allocates a PIN initially, but the customer can usually change it
as often as they like at an ATM that supports PIN changes.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Hard work never killed anyone, but why take a risk?
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWQQEV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5PYiAP9EsNwdiB/SIfTLFBdfUvZZoRXP45DGJS7pIbRFK/+hTAEAs3wPoT9uSXhV
cw1zh3xFCanohsHofRcWzoa5wB1pYAuJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWQQF18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8LF2B/9B5cN54cApj+jdAge2m7M0VRXB
VQVbGSxnlCniGJnLAsN69KffCV9RkHsQtj0lYM6j1AbStJd2PJUh7ZFK2mMPhtOl
SNYaXgFJL/8nEqM84NKI1GdxOWhd5wiQ82zbpiqDV0R4GjGnswudjjVfIXjJanGx
3tf6SknBCCW2KSeg9rOqBJP9PKA2EpDbEx0Ol8Wacg0tH/zVlXUPnwqPb8ezYsNS
DyrSW+ndCNUNVEgFGpZpJXENe9MyP6D9RD0hSHfIY+J6BWQZ/UeM/21eDE9o50e9
dGA+a0SyDPbRx+A6CaGBvcfVZWbCcQgfyHEmL92ZQBGD/Fcnefn2WM1SAy7Z
=JVCv
-----END PGP SIGNATURE-----



From guanx.bac at gmail.com  Tue Jul 11 04:18:22 2017
From: guanx.bac at gmail.com (Guan Xin)
Date: Tue, 11 Jul 2017 10:18:22 +0800
Subject: Changing PINs of German bank card
In-Reply-To: <2169887.G3JAZmPBVB@thufir>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <2169887.G3JAZmPBVB@thufir>
Message-ID: <CANeMGR5gHU=O4EOmJmUM7iRum_BxPUsQ1zD3wq3J8-N=z+fm2Q@mail.gmail.com>

On Tue, Jul 11, 2017 at 1:38 AM, Ingo Kl?cker <kloecker at kde.org> wrote:

>
> ... and that would very often be either 1234[56] or the card owner's
> date of birth as we all know. A random 4-digit PIN randomly chosen by
> the bank is certainly safer than this.
>
> Yes, that's true.


> German banks require you to destroy the PIN letter after memorizing the
> PIN. You are not supposed to keep the letter. If you want to follow
> their method then write your PIN on a piece of paper, memorize the PIN
> and then burn or eat the piece of paper. ;-)
>
> Sometimes they circulate the permanent PIN for two weeks in German Post
before delivery. Looks like I'm the last to read it.

Two  other advantages (correct me if I'm mistaken) of self-invented PINs
are, I think,
1) One can prepare and remember the PIN in advance, so there is practically
no need to write it down;
2) A PIN letter is only something I have, while my own PIN record is in
addition something I know. i.e., it may not be obvious to someone else to
be a PIN record / reminder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170711/f0da7a60/attachment.html>

From guanx.bac at gmail.com  Tue Jul 11 04:18:35 2017
From: guanx.bac at gmail.com (Guan Xin)
Date: Tue, 11 Jul 2017 10:18:35 +0800
Subject: Changing PINs of German bank card
In-Reply-To: <20170710175203.GA3647@c720-r314251>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <20170710175203.GA3647@c720-r314251>
Message-ID: <CANeMGR5PVjMaX+donpQVb50FjMXdmGXwRq1xJgnwm6D31A8fpg@mail.gmail.com>

On Tue, Jul 11, 2017 at 1:52 AM, Matthias Apitz <guru at unixarea.de> wrote:

>
> Nowadays some German banks allow changing the PIN in the Teller
> Machines. I saw it today in an ATM of the Sparkasse. Amex allows (or
> allowed) requesting a new personal PIN by fax.
>
> Interesting ... Just closed my Sparkasse account since everyday every
clerk of them has a different answer to exactly the same question and I'm
unable follow them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170711/3a85cc75/attachment.html>

From lists at binarus.de  Tue Jul 11 09:44:48 2017
From: lists at binarus.de (Binarus)
Date: Tue, 11 Jul 2017 09:44:48 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
Message-ID: <3499376d-11fb-9854-688a-48e054166647@binarus.de>

On 10.07.2017 17:42, Guan Xin wrote:
> This is probably a general question --
> 
> I have never seen a German bank that allows changing the PIN of a card.

I am not sure if this is an intentional limitation of the cards (to
prevent users from choosing idiotic pins like 1234 or their birthday).

> So I wonder if it is because using a fixed (non-changeable) 4-digit PIN
> mailed in clear text really safer than using a 4 to 6 digit variable
> length PIN that never explicitly appears anywhere.

I recently had a talk with one of my banks because they didn't even
allow changing the web password (for access to online banking) to
something being longer than 5 alphanumeric digits (!!!).

Although (in my case) the subject of the talk was the web password, the
following applies to the card pin as well.

- Usually, you are receiving the card's pin by postal mail. It is
consensus here in Germany that postal mail is highly trustworthy and
that the so called "Briefgeheimnis" is obeyed very carefully. The legal
hurdles for opening a letter during transport are still very high.

- Additionally, you are usually receiving the pins in a special envelope
which (AFAIK) makes it very difficult to read the letter's content
without opening it, even by advanced means (X-ray and the like). In many
cases, the pin is even more secured (metal coating).

I (personally) consider receiving pins that way safe.

But the key point in the bank's argumentation was (applies to pins as
well as to my online banking access):

- If somebody tries to brute force the pin (or online banking password),
the access will be permanently denied if there are more than 3 failures
(the exact number may vary). That means that the length of the pin /
password is not as important as one might think, because it is
practically impossible to brute force a 4 digit pin with only 3 tries.

I know that the chance for guessing 4 digits within 3 tries is higher
than guessing 6 digits, but obviously, most banks are considering 4
digits safe enough.

Furthermore, if you are really hacked and lose money because of this,
the bank will compensate your loss provided that you did not behave like
an idiot (i.e. if you did not note the pin on a piece of paper, attached
that piece of paper to your card and then lost both of them). At least,
they did so in all cases I know about, despite of the fact that the
respective customer (of course) could not *prove* at a technical level
how the hacking worked. As long as the customer could demonstrate
credibly that he had not done any very silly mistake, the bank compensated.

Due to all reasons mentioned above, I (personally) think that you should
not be concerned by the length of the pin, the fact that you can't
change it, and the way you receive it.

> If German banks are right, then should I follow their method and store
> the PINs of my OpenPGP cards on a piece of paper?

Now, this is a completely different question which does not have to do
anything with the pin's length. The answer to this question completely
depends on your environment and your intentions. I will explain this by
two examples with contrary conclusions:

Example 1:

You always forget that pin of your EC card. Therefore, you write it down
to a piece of paper and put it into your wallet besides your EC card.

Well, as said above, this obviously would be the most silly thing you
could do. No bank will compensate you if you lose your wallet (with the
card and its pin) and if somebody then steals your money.

So you think about it and come to a better idea. You could store the pin
on your smart phone. This indeed is better - hopefully you won't lose
your smart phone and your banking card at the same time. But there is
still a small chance that you do.

You think again and finally have a good idea. You install a password
safe app on your smart phone which locally stores all pins and passwords
with strong encryption. You operate that app with great discipline: You
choose a long, weird master password which you must enter to open the
password safe where the pin is stored. You open the safe only when
needed, and you close it immediately when done, and you don't let the
app (or OS) cache the master password.

(Note: Of course, you MUST NOT write the master password on a piece of
paper and attach that paper to your smart phone ...)

So, in this example, carrying a piece of paper with you where the pin is
noted is a very bad idea, but carrying that pin with you on your smart
phone is a good idea provided that the pin is stored there in a heavily
encrypted password safe and provided that you operate that safe with
some discipline. You still have to memorize that safe's master password,
but this is a one time thing, and you then could store all other
passwords and pins in that safe.

Example 2:

On your desktop PC, you are using the internet excessively, and you are
afraid that some Trojan horse / keylogger will be able to get on your PC
(given the latest ransomware attacks, this obviously is a real threat
even when you are running an up-to-date virus protection).

In this case, using a password safe software won't protect you. The
Trojan horse / keylogger could be able to intercept all your keystrokes,
including your master password for the password safe. If you don't use a
password safe and just store the passwords in an unencrypted text file
(perhaps because you are the only person who physically has access to
the PC in question), a Trojan horse will be able to read all your
passwords even without intercepting keystrokes.

So, in this case, it obviously would be better to write down your
passwords on a sheet of paper provided you can store that paper in a
place where only you have access to (for example, some secret place in
your private apartment).

>From these examples, it should be clear that there can't be a general
recommendation which fits all cases.

And there is one more very important thing most people don't think of:
What happens if you have an accident or if you die? Your heirs will have
all sorts of troubles if something happens to you and they can't access
your electronic accounts because they don't have the passwords.

So I tend to write down at least my master password on a sheet of paper,
put that in a sealed envelope and give it to a relative who I highly
trust. In case I die, they open the envelope, have the master password
for my password safe and can use that to open the access to all my
accounts. Alternatively, you could have some relative you trust memorize
your master password. But since he won't use it regularly (hopefully),
he probably will forget it after short time ...

Regards,

Binarus


From ndk.clanbo at gmail.com  Tue Jul 11 10:14:26 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 11 Jul 2017 10:14:26 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <3499376d-11fb-9854-688a-48e054166647@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
Message-ID: <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>

Il 11/07/2017 09:44, Binarus ha scritto:

> - If somebody tries to brute force the pin (or online banking password),
> the access will be permanently denied if there are more than 3 failures
> (the exact number may vary). That means that the length of the pin /
> password is not as important as one might think, because it is
> practically impossible to brute force a 4 digit pin with only 3 tries.
If you routinely use your card twice a day, they can make two or four
guesses each day: every correct PIN you insert resets the counter.
The probability to guess the correct code during the 5-years life of the
card is definitely non-negligible.

> And there is one more very important thing most people don't think of:
> What happens if you have an accident or if you die? Your heirs will have
> all sorts of troubles if something happens to you and they can't access
> your electronic accounts because they don't have the passwords.
Usually there are other, non-technical ways. For example they just go to
the bank with a death certificate.

> So I tend to write down at least my master password on a sheet of paper,
> put that in a sealed envelope and give it to a relative who I highly
> trust. In case I die, they open the envelope, have the master password
> for my password safe and can use that to open the access to all my
> accounts. Alternatively, you could have some relative you trust memorize
> your master password. But since he won't use it regularly (hopefully),
> he probably will forget it after short time ...
Better use shamir's secret sharing, or just use LCD-segments characters
printed on two acetate sheets that need to be combined to be read.
Obviously the two sheets are to be given to two different people, in
sealed envelopes...

BTW the method you use is the same that was used for our mainframe's
master password. :)

BYtE,
 Diego


From jhs at berklix.com  Tue Jul 11 12:23:06 2017
From: jhs at berklix.com (Julian H. Stacey)
Date: Tue, 11 Jul 2017 12:23:06 +0200
Subject: Changing PINs of German bank card
In-Reply-To: Your message "Mon, 10 Jul 2017 19:52:03 +0200."
 <20170710175203.GA3647@c720-r314251>
Message-ID: <201707111023.v6BAN6j5024725@fire.js.berklix.net>

> > This is probably a general question --
> >=20
> > I have never seen a German bank that allows changing the PIN of a card.
> > So I wonder if it is because using a fixed (non-changeable) 4-digit PIN
> > mailed in clear text really safer than using a 4 to 6 digit variable leng=
> th
> > PIN that never explicitly appears anywhere.
> 
> Nowadays some German banks allow changing the PIN in the Teller
> Machines. I saw it today in an ATM of the Sparkasse. Amex allows (or=20
> allowed) requesting a new personal PIN by fax.

Postbank.de did not provide it on ATM or by any other means a month back.
All UK cards I know of allow PIN change at the ATM.

Cheers,
Julian
-- 
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#700k_stolen_votes


From lists at binarus.de  Tue Jul 11 12:32:56 2017
From: lists at binarus.de (Binarus)
Date: Tue, 11 Jul 2017 12:32:56 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
Message-ID: <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>

On 11.07.2017 10:14, NdK wrote:
> Il 11/07/2017 09:44, Binarus ha scritto:
> 
>> - If somebody tries to brute force the pin (or online banking password),
>> the access will be permanently denied if there are more than 3 failures
>> (the exact number may vary). That means that the length of the pin /
>> password is not as important as one might think, because it is
>> practically impossible to brute force a 4 digit pin with only 3 tries.

> If you routinely use your card twice a day, they can make two or four
> guesses each day: every correct PIN you insert resets the counter.

I am not completely sure if I got you right. Wouldn't that mean that I
have to lose my card, the bad person then makes two guesses, then I get
back my card and enter my correct pin, then I lose my card again, and
the same bad person finds it again and makes another two guesses, then I
get my card back again and so on?

This is practically impossible (unless I have missed something obvious).
How could the correct pin be entered and the counter be reset if I
didn't get the card back?

Or did you refer to an adversary who copied the card? In that case, he
still would have to know when I actually have entered the correct pin
(which would mean that he permanently had to observe me) to start his
next two tries.

Furthermore, people usually call their bank to make their card invalid
as soon as they notice they have lost it. This means that they usually
won't enter the correct pin again after having lost the card.

The only way to abuse the fail counter reset feature would be to steal
the card, to copy it and to return it to its owner, and to do this in a
way that the owner would not notice it. But again, the adversary would
then still have to observe the card owner to see when the counter is
reset and to start his next tries.

> The probability to guess the correct code during the 5-years life of the
> card is definitely non-negligible.>
>> And there is one more very important thing most people don't think of:
>> What happens if you have an accident or if you die? Your heirs will have
>> all sorts of troubles if something happens to you and they can't access
>> your electronic accounts because they don't have the passwords.

> Usually there are other, non-technical ways. For example they just go to
> the bank with a death certificate.

I already have seen cases where it was not that easy in Germany.
Usually, presenting a death certificate to the bank is not enough. I
have seen that the bank had to make sure that the people presenting the
death certificate actually were the legal heirs. That meant that those
people had to acquire all sorts of documents from all sorts of
authorities which has been very expensive (several hundreds of EUR), but
more important, was very unpleasant and time consuming, especially in
the situation they were.

AFAIK, there is only one thing you could do to avoid that hassle: The
testator and the heirs should make a contract of inheritance. Such a
contract must be made by a notary, so this will also have its cost, but
when you present such a contract to the bank (in addition to the death
certificate), you will have no problems.

But now, being a German citizen, try the same thing with eBay, Facebook,
LinkedIn, PayPal and so on ... no thanks.

>> So I tend to write down at least my master password on a sheet of paper,
>> put that in a sealed envelope and give it to a relative who I highly
>> trust. In case I die, they open the envelope, have the master password
>> for my password safe and can use that to open the access to all my
>> accounts. Alternatively, you could have some relative you trust memorize
>> your master password. But since he won't use it regularly (hopefully),
>> he probably will forget it after short time ...

> Better use shamir's secret sharing, or just use LCD-segments characters
> printed on two acetate sheets that need to be combined to be read.
> Obviously the two sheets are to be given to two different people, in
> sealed envelopes...

Nice ideas :-) My own security needs are not that high, though (hoping
that life won't punish me for that optimism).

> BTW the method you use is the same that was used for our mainframe's
> master password. :)

To add to it, if you mistrust your relatives, you could put the password
on paper into some sort of lock box and carry the key to that lock box
with you. But then what would happen if you lost that key?

Regards,

Binarus


From m.mansfeld at mansfeld-elektronik.de  Tue Jul 11 11:48:09 2017
From: m.mansfeld at mansfeld-elektronik.de (Matthias Mansfeld)
Date: Tue, 11 Jul 2017 11:48:09 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <3499376d-11fb-9854-688a-48e054166647@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>,
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
Message-ID: <59649ED9.17679.ECA890A@m.mansfeld.mansfeld-elektronik.de>

On 11 Jul 2017 at 9:44, Binarus wrote:

> On 10.07.2017 17:42, Guan Xin wrote:
> > This is probably a general question --
> > 
> > I have never seen a German bank that allows changing the PIN of a card.
> 
> I am not sure if this is an intentional limitation of the cards (to
> prevent users from choosing idiotic pins like 1234 or their birthday).

[..]
At least Sparkasse and HypoVereinsbank and IIRC also Postbank allow 
changing at the ATM terminal.

And a birthday isn't as idiotic as 1234 or 1111, as long you assume a 
standard pickpocket doesn't know you personal data (OK, your ID-card 
within the same wallet... maybe no good idea. Then not your own 
birthday but from a person or your cat you can remember, or better 
your wedding day, which normally would be forgotten always ;-) 

> Now, this is a completely different question which does not have to do
> anything with the pin's length. The answer to this question completely
> depends on your environment and your intentions. I will explain this by
> two examples with contrary conclusions:
> 
> Example 1:
> 
[...]
> 
> Example 2:
[..]

Example 3

MY use case would be: I have, let's say two bank accounts at 
Sparkasse, one at Postbank, one at HypoVereinsbank (possible reason: 
two bussines accounts and one private account and one from a 
inherited account) and I can remember ONE good "random-like" 
4-digit-PIN, but would mangle definitely four different PINs (been 
there, done that...). Then I chose one and the same "good" PIN for 
all four cards which I don't need to write down anywhere and 
everything is OK.

Regards
Matthias
--
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF



From ndk.clanbo at gmail.com  Tue Jul 11 14:32:43 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 11 Jul 2017 14:32:43 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
 <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
Message-ID: <bc71fcfb-7de1-e617-1637-444a85c92b8e@gmail.com>

Il 11/07/2017 12:32, Binarus ha scritto:

>> If you routinely use your card twice a day, they can make two or four
>> guesses each day: every correct PIN you insert resets the counter.
> I am not completely sure if I got you right. Wouldn't that mean that I
> have to lose my card, the bad person then makes two guesses, then I get
> back my card and enter my correct pin, then I lose my card again, and
> the same bad person finds it again and makes another two guesses, then I
> get my card back again and so on?
Say that's your wife/son that takes the card when you're at home...
Low prob, but possible :)

>> Usually there are other, non-technical ways. For example they just go to
>> the bank with a death certificate.
> I already have seen cases where it was not that easy in Germany.
> Usually, presenting a death certificate to the bank is not enough. I
> have seen that the bank had to make sure that the people presenting the
> death certificate actually were the legal heirs. That meant that those
> people had to acquire all sorts of documents from all sorts of
> authorities which has been very expensive (several hundreds of EUR), but
> more important, was very unpleasant and time consuming, especially in
> the situation they were.
Been there...
Another reason to give the password before going with the documents
might be "a bit" illegal: just transfer the money to avoid paying taxes.

> But now, being a German citizen, try the same thing with eBay, Facebook,
> LinkedIn, PayPal and so on ... no thanks.
Why should heirs have access to social accounts? Paypal, otoh, is a bank
that have to follow the same rules of other banks...

> Nice ideas :-) My own security needs are not that high, though (hoping
> that life won't punish me for that optimism).
My concern with a singl "cleartext" pass would be a burglar that steals
it together with other valuables...

> To add to it, if you mistrust your relatives, you could put the password
> on paper into some sort of lock box and carry the key to that lock box
> with you. But then what would happen if you lost that key?
Given that mechanical keys are often easier to open whithout the key
than with it...

BYtE,
 Diego



From lists at binarus.de  Tue Jul 11 15:32:20 2017
From: lists at binarus.de (Binarus)
Date: Tue, 11 Jul 2017 15:32:20 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <bc71fcfb-7de1-e617-1637-444a85c92b8e@gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
 <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
 <bc71fcfb-7de1-e617-1637-444a85c92b8e@gmail.com>
Message-ID: <55d80c1b-b854-abd3-0d0c-5057e7f0896d@binarus.de>

On 11.07.2017 14:32, NdK wrote:
> Il 11/07/2017 12:32, Binarus ha scritto:
> 
>> But now, being a German citizen, try the same thing with eBay, Facebook,
>> LinkedIn, PayPal and so on ... no thanks.
> Why should heirs have access to social accounts? Paypal, otoh, is a bank
> that have to follow the same rules of other banks...

Interestingly enough, this subject is becoming more and more important.
I think I can remember that there are first tries in some countries (or
the EU?) to make respective laws. At least, I am sure that there already
were lawsuits where heirs have tried to get hold of accounts of somebody
who passed away (in the case I can remember, a facebook account has been
subject of the lawsuit, but I can't remember right now how it ended).

IMHO, there are many reasons why this should be possible, so I would
appreciate if there were such laws. I don't want this thread to become
too off-topic, so I won't elaborate on this in a fashion this complex
subject deserves, but just give one pragmatic example:

Let's suppose somebody offers something on eBay and then passes away.
Let's suppose that somebody else wins that auction and immediately pays
via PayPal. Now what?

There may be means to solve such situations, but they usually cost lots
of time, money or nerves, and this has been just a simple example. If we
think a while about it, we surely will find a constellation where it
would be quite catastrophic if an account holder's heirs couldn't get
hold of his accounts.

>> Nice ideas :-) My own security needs are not that high, though (hoping
>> that life won't punish me for that optimism).
> My concern with a singl "cleartext" pass would be a burglar that steals
> it together with other valuables...

You are right, burglary is a real threat. But if you have memorized your
master password and don't keep it on paper in your own apartment /
house, but just give it on paper to a relative, the burglar will have to
steal the paper from your relative and at the same time steal your PC
(or banking card) from you to make anything out of it.

Therefore, I have no problem with giving the password on paper to a
relative who lives some km away from me. I would never keep the password
on paper in the same room (or even building) as the PC or banking card,
though, and as soon as either the PC (or banking card) or the password
paper would be stolen, I would immediately change the password (and hand
the new one out on paper to my relative).

>> To add to it, if you mistrust your relatives, you could put the password
>> on paper into some sort of lock box and carry the key to that lock box
>> with you. But then what would happen if you lost that key?
> Given that mechanical keys are often easier to open whithout the key
> than with it...

Actually, I was thinking about a lock box in a bank or such things ...

Regards,

Binarus


From jerry at seibercom.net  Tue Jul 11 14:38:01 2017
From: jerry at seibercom.net (Jerry)
Date: Tue, 11 Jul 2017 08:38:01 -0400
Subject: Changing PINs of German bank card
In-Reply-To: <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
 <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
Message-ID: <20170711083801.00003d1d@seibercom.net>

On Tue, 11 Jul 2017 12:32:56 +0200, Binarus stated:

>On 11.07.2017 10:14, NdK wrote:
>> Il 11/07/2017 09:44, Binarus ha scritto:
>>   
>>> - If somebody tries to brute force the pin (or online banking
>>> password), the access will be permanently denied if there are more
>>> than 3 failures (the exact number may vary). That means that the
>>> length of the pin / password is not as important as one might
>>> think, because it is practically impossible to brute force a 4
>>> digit pin with only 3 tries.  
>
>> If you routinely use your card twice a day, they can make two or four
>> guesses each day: every correct PIN you insert resets the counter.  
>
>I am not completely sure if I got you right. Wouldn't that mean that I
>have to lose my card, the bad person then makes two guesses, then I get
>back my card and enter my correct pin, then I lose my card again, and
>the same bad person finds it again and makes another two guesses, then
>I get my card back again and so on?

If you continually lose your card that often, you have more problems
than just a lost/stolen card to deal with. I sincerely hope you are
never trusted with confidential information.

>This is practically impossible (unless I have missed something
>obvious). How could the correct pin be entered and the counter be
>reset if I didn't get the card back?

In theory, it couldn't.

>Or did you refer to an adversary who copied the card? In that case, he
>still would have to know when I actually have entered the correct pin
>(which would mean that he permanently had to observe me) to start his
>next two tries.
>
>Furthermore, people usually call their bank to make their card invalid
>as soon as they notice they have lost it. This means that they usually
>won't enter the correct pin again after having lost the card.

That is the general idea.

>The only way to abuse the fail counter reset feature would be to steal
>the card, to copy it and to return it to its owner, and to do this in a
>way that the owner would not notice it. But again, the adversary would
>then still have to observe the card owner to see when the counter is
>reset and to start his next tries.

I was told, although not confirmed, that cards with embedded chips
cannot be copied and still be usable. If anyone would like to comment
on that, it would be welcomed.

>> The probability to guess the correct code during the 5-years life of
>> the card is definitely non-negligible.>  
>>> And there is one more very important thing most people don't think
>>> of: What happens if you have an accident or if you die? Your heirs
>>> will have all sorts of troubles if something happens to you and
>>> they can't access your electronic accounts because they don't have
>>> the passwords.  
>
>> Usually there are other, non-technical ways. For example they just
>> go to the bank with a death certificate.  

I have actually seen that happen. The estate lawyer had to fill out
some paper work, but it was really no big deal. Basically, it is the
same procedure used to get access to a deceased safe deposit box.

>I already have seen cases where it was not that easy in Germany.
>Usually, presenting a death certificate to the bank is not enough. I
>have seen that the bank had to make sure that the people presenting the
>death certificate actually were the legal heirs. That meant that those
>people had to acquire all sorts of documents from all sorts of
>authorities which has been very expensive (several hundreds of EUR),
>but more important, was very unpleasant and time consuming, especially
>in the situation they were.

Good for them. They should make absolutely sure before releasing the
funds.

>AFAIK, there is only one thing you could do to avoid that hassle: The
>testator and the heirs should make a contract of inheritance. Such a
>contract must be made by a notary, so this will also have its cost, but
>when you present such a contract to the bank (in addition to the death
>certificate), you will have no problems.

The cost of a notary is a few dollars; therefore, negligible. Honestly,
I would hope that it would NOT be that easy.

>But now, being a German citizen, try the same thing with eBay,
>Facebook, LinkedIn, PayPal and so on ... no thanks.
>
>>> So I tend to write down at least my master password on a sheet of
>>> paper, put that in a sealed envelope and give it to a relative who
>>> I highly trust. In case I die, they open the envelope, have the
>>> master password for my password safe and can use that to open the
>>> access to all my accounts. Alternatively, you could have some
>>> relative you trust memorize your master password. But since he
>>> won't use it regularly (hopefully), he probably will forget it
>>> after short time ...  
>
>> Better use shamir's secret sharing, or just use LCD-segments
>> characters printed on two acetate sheets that need to be combined to
>> be read. Obviously the two sheets are to be given to two different
>> people, in sealed envelopes...  
>
>Nice ideas :-) My own security needs are not that high, though (hoping
>that life won't punish me for that optimism).
>
>> BTW the method you use is the same that was used for our mainframe's
>> master password. :)  
>
>To add to it, if you mistrust your relatives, you could put the
>password on paper into some sort of lock box and carry the key to that
>lock box with you. But then what would happen if you lost that key?

I have all of my important papers, including passwords to accounts that
have to be kept secure, in a bank safe deposit box. If I were to die,
it wouldn't matter who had the key if they were on the allowed users
list. My heirs would have to get a court order to have the box opened.
Not really a big deal. Usually things like this are written into the
will and happen all the time.

BTW, it isn't all the difficult to open a regular lock box. I have
drilled out a few in my time after losing the key. Having it a bank is
far more secure.

-- 
Jerry



From lists at binarus.de  Tue Jul 11 16:29:51 2017
From: lists at binarus.de (Binarus)
Date: Tue, 11 Jul 2017 16:29:51 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <59649ED9.17679.ECA890A@m.mansfeld.mansfeld-elektronik.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <59649ED9.17679.ECA890A@m.mansfeld.mansfeld-elektronik.de>
Message-ID: <6f23af4f-3944-80f2-cec8-8d14021047b5@binarus.de>

On 11.07.2017 11:48, Matthias Mansfeld wrote:
> On 11 Jul 2017 at 9:44, Binarus wrote:
> 
>> On 10.07.2017 17:42, Guan Xin wrote:
>>> This is probably a general question --
>>>
>>> I have never seen a German bank that allows changing the PIN of a card.
>>
>> I am not sure if this is an intentional limitation of the cards (to
>> prevent users from choosing idiotic pins like 1234 or their birthday).
> 
> [..]
> At least Sparkasse and HypoVereinsbank and IIRC also Postbank allow 
> changing at the ATM terminal.
> 
> And a birthday isn't as idiotic as 1234 or 1111, as long you assume a 
> standard pickpocket doesn't know you personal data (OK, your ID-card 
> within the same wallet... maybe no good idea. Then not your own 
> birthday but from a person or your cat you can remember, or better 
> your wedding day, which normally would be forgotten always ;-) 

You are right, but experience tells us (no, not us, but the banks) that
people won't think about it. I have no doubt that people like you and me
would choose a secure pin, but from a bank's point of view, most people
would choose pins like 1234 or their birthday.

It might be only a matter of time until there is the first case of a
bank refusing to compensate a customer because his pin was his birthday.

>> Now, this is a completely different question which does not have to do
>> anything with the pin's length. The answer to this question completely
>> depends on your environment and your intentions. I will explain this by
>> two examples with contrary conclusions:
>>
>> Example 1:
>>
> [...]
>>
>> Example 2:
> [..]
> 
> Example 3
> 
> MY use case would be: I have, let's say two bank accounts at 
> Sparkasse, one at Postbank, one at HypoVereinsbank (possible reason: 
> two bussines accounts and one private account and one from a 
> inherited account) and I can remember ONE good "random-like" 
> 4-digit-PIN, but would mangle definitely four different PINs (been 
> there, done that...). Then I chose one and the same "good" PIN for 
> all four cards which I don't need to write down anywhere and 
> everything is OK.

This is a good point as long as we are discussing only banking card
pins. My examples were more general (an electronic password safe will
store all sorts of other secrets / web passwords). Since the OP had
asked about banking card pins, I eventually should have restricted my
answers to that.

On the other hand, I can image a bunch of cases where somebody would
like to take web passwords (and not only banking card pins) along when
going out (e.g. doing web based email in an internet cafe during
vacation). In such cases, I think there is no reason why the pins
shouldn't be stored in the password safe as well.

Thinking about your use case, I am not sure if I would try to make all
pins the same, given the fact that nowadays skimming is the main problem
(and not stealing and trying to brute-force). I am not sure if banks
will compensate if something very bad happens and all four of your
accounts get emptied when the respective cards have the same pin.
Probably most banks disallow this in their terms of service (AGBs).

After all, you don't use the same password for your eBay, Facebook and
Paypal account, do you (unfair question, because those accounts won't be
disabled after three wrong password entries, but nevertheless ...)?

Regards,

Binarus


From peter at digitalbrains.com  Tue Jul 11 16:50:06 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 11 Jul 2017 16:50:06 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
 <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
Message-ID: <fd3f83e6-cfd9-ddf4-242e-9e995364dacc@digitalbrains.com>

On 11/07/17 12:32, Binarus wrote:
> I am not completely sure if I got you right. Wouldn't that mean that I
> have to lose my card, the bad person then makes two guesses, then I get
> back my card and enter my correct pin, then I lose my card again, and
> the same bad person finds it again and makes another two guesses, then I
> get my card back again and so on?

But you were discussing both card PINs as well as web passwords with low
entropy, right? You said earlier:

> - If somebody tries to brute force the pin (or online banking password),
> the access will be permanently denied if there are more than 3 failures
> (the exact number may vary).

I still don't think you could brute-force it with just two tries in
between your regular logins. However, this seems like a nice DoS if
someone dislikes you and is mean-spirited. They get a hold of your bank
account number, attempt to log in with the three password guesses "say",
"bye" and "now" and you need to phone up your bank, they need to send
you a new letter with a new password, etcetera. Or is there some other
secret or semi-secret, like a card number, that an attacker needs to
enter in order to decrement the failure counter?

This "three strikes and you're out" scheme is generally for two-factor
auth, not for regular web passwords. For a reason.

Cheers,

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: </pipermail/attachments/20170711/5f8b04a4/attachment.sig>

From lists at binarus.de  Tue Jul 11 17:08:03 2017
From: lists at binarus.de (Binarus)
Date: Tue, 11 Jul 2017 17:08:03 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <20170711083801.00003d1d@seibercom.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1663d64c-beb6-1dd3-2cc6-56bf4018798c@gmail.com>
 <12ad0e7c-ea62-79bf-639a-acd56dfc1c6c@binarus.de>
 <20170711083801.00003d1d@seibercom.net>
Message-ID: <a11515a0-941b-a998-7a2a-8f5d73cfc174@binarus.de>

On 11.07.2017 14:38, Jerry wrote:
> On Tue, 11 Jul 2017 12:32:56 +0200, Binarus stated:
> 
> [...]
>> I am not completely sure if I got you right. Wouldn't that mean that I
>> have to lose my card, the bad person then makes two guesses, then I get
>> back my card and enter my correct pin, then I lose my card again, and
>> the same bad person finds it again and makes another two guesses, then
>> I get my card back again and so on?
>
> If you continually lose your card that often, you have more problems
> than just a lost/stolen card to deal with. I sincerely hope you are
> never trusted with confidential information.
>

Not sure if you eventually have misunderstood me. I was just trying to
understand the previous speaker by asking him what exactly he was
meaning ...

>> The only way to abuse the fail counter reset feature would be to steal
>> the card, to copy it and to return it to its owner, and to do this in a
>> way that the owner would not notice it. But again, the adversary would
>> then still have to observe the card owner to see when the counter is
>> reset and to start his next tries.
> 
> I was told, although not confirmed, that cards with embedded chips
> cannot be copied and still be usable. If anyone would like to comment
> on that, it would be welcomed.

No idea about the U.S., but talking about Germany: The main problem with
ATMs here is skimming (I am not sure if this wording is correct in the
U.S., so let me shortly explain: Skimming means that some adversary
manipulates an ATM in that he mounts an own user interface onto it,
perfectly imitating the original interface (mechanically - own
electronics, own keyboard), intercepting the data stream and the
keystrokes (pin), or mounts a pinhole camera to record people entering
their pins)).

AFAIK, at least until one or two years ago, the skimmers used to copy
the cards, but recently banks upgraded their ATMs and their customers'
cards so that they can't be copied any more. But for compatibility, the
ATMs still won't refuse old cards which can be copied.

But please don't take this as bare truth; I am really not sure.

>>> The probability to guess the correct code during the 5-years life of
>>> the card is definitely non-negligible.>  
>>>> And there is one more very important thing most people don't think
>>>> of: What happens if you have an accident or if you die? Your heirs
>>>> will have all sorts of troubles if something happens to you and
>>>> they can't access your electronic accounts because they don't have
>>>> the passwords.  
>>
>>> Usually there are other, non-technical ways. For example they just
>>> go to the bank with a death certificate.  
> 
> I have actually seen that happen. The estate lawyer had to fill out
> some paper work, but it was really no big deal. Basically, it is the
> same procedure used to get access to a deceased safe deposit box.

No chance to have it that ease here in Germany ... at least with certain
banks.

>> I already have seen cases where it was not that easy in Germany.
>> Usually, presenting a death certificate to the bank is not enough. I
>> have seen that the bank had to make sure that the people presenting the
>> death certificate actually were the legal heirs. That meant that those
>> people had to acquire all sorts of documents from all sorts of
>> authorities which has been very expensive (several hundreds of EUR),
>> but more important, was very unpleasant and time consuming, especially
>> in the situation they were.
> 
> Good for them. They should make absolutely sure before releasing the
> funds.

I agree.

>> AFAIK, there is only one thing you could do to avoid that hassle: The
>> testator and the heirs should make a contract of inheritance. Such a
>> contract must be made by a notary, so this will also have its cost, but
>> when you present such a contract to the bank (in addition to the death
>> certificate), you will have no problems.
> 
> The cost of a notary is a few dollars; therefore, negligible. Honestly,
> I would hope that it would NOT be that easy.

Here in Germany, a notary even won't take his pencil without earning a
significant amount of money. As far as I can remember, the inheritance
contract did cost about 500 EUR (about US $560) many years ago, but that
was still a small amount of money compared to the hassle the heirs would
have had if they did not have that contract.

By the way, there is no competition in this field because the money a
notary charges for an action is defined by law. There is a detailed
catalogue which lists every action a notary could (may) do, even the
most exotic ones, and how much money he will get for that. Any notary is
prohibited by law from charging less; he will lose his approbation and
get into serious trouble if he does.

Is the situation in the U.S. similar?

> I have all of my important papers, including passwords to accounts that
> have to be kept secure, in a bank safe deposit box. If I were to die,
> it wouldn't matter who had the key if they were on the allowed users
> list. My heirs would have to get a court order to have the box opened.
> Not really a big deal. Usually things like this are written into the
> will and happen all the time.
> 
> BTW, it isn't all the difficult to open a regular lock box. I have
> drilled out a few in my time after losing the key. Having it a bank is
> far more secure.

Yes, that's the reason why I have proposed that in my previous post ...

Regards,

Binarus



From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jul 11 20:32:10 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 11 Jul 2017 19:32:10 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <201707111023.v6BAN6j5024725@fire.js.berklix.net>
References: Your message "Mon, 10 Jul 2017 19:52:03 +0200." 
 <20170710175203.GA3647@c720-r314251>
 <201707111023.v6BAN6j5024725@fire.js.berklix.net>
Message-ID: <1068952996.20170711193210@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Tuesday 11 July 2017 at 11:23:06 AM, in
<mid:201707111023.v6BAN6j5024725 at fire.js.berklix.net>, Julian H.
Stacey wrote:-


> All UK cards I know of allow PIN change at the ATM.

Back in the 1980s I remember some that had no PIN change facility. And
at one time, NatWest only allowed a PIN change the first time the card
was used in one of their own ATMs.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

A woman's mind is cleaner than a man's: She changes it more often.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWUZsV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5Du6AQDlRkHz9Q6DHWfTdBcGaQeWHt5+WJm1pHYY1nC7lJAyiwD6AxjVP0zyAMlu
OjGQd6koHrRsqrPqQYvfL9pfiLI+SQuJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWUZxV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8JK8B/0TIofXyXDj+YKzJzC122GnsmwY
5in84fDv0e1OBjRnjnfou5+EVQjD2HMOC5EYdPd/sqVk/StVaJCSln4eaKcFwpkt
CkWgWqh7nB6gi7N++zOky0ju+dmV/TvUDGzcwo+eNpQ3RE+oWTrub3Ru/MqYYdNI
5pMWPPBrY9kAUM14lR7WjntrfUfrmMp1V7A4ha3i6Asgj0vXZ+KKMuOedl3777dd
NCT1WS83RhzOLOsutQcZmXl095zh2/foHy0c5e17fnt01HQR5LvBdwFC4eQAZTWw
ngDXdCntKdX2vw5J2l8k/UCAjW0JQk4MzY20cnh3TYXe0hDN2OJmg4Bt4wX8
=oqCv
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jul 11 20:38:08 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 11 Jul 2017 19:38:08 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <3499376d-11fb-9854-688a-48e054166647@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
Message-ID: <1769963444.20170711193808@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Tuesday 11 July 2017 at 8:44:48 AM, in
<mid:3499376d-11fb-9854-688a-48e054166647 at binarus.de>, Binarus wrote:-


> I am not sure if this is an intentional limitation of
> the cards (to
> prevent users from choosing idiotic pins like 1234 or
> their birthday).


Surely things like 1234 can be prevented by software.



- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Change is inevitable except from a vending machine
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWUbEV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5IqUAP9kGj8+HI9HZ64HHANDfjyg6g1bwSwwyp0yaArYioM95gD/eu+gvqI5zsnc
y2u1pnh07uR42LhQXV4GKv5liIfzswqJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWUbEV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8GiHCACz9RsSJ3Zn44MLi3SfEbD/n7yz
CWc55RaqMvSSp4Avpyxpbd/ITPkrVSspYdtAgUdq37YT3J+cDkcGGL6HBAhrTRJf
3oWSVZ1mBcLxzTsNEeurBpMROkembQRMOHeaMKf0iVT+Foe0UpHSDzm3bx7RAgav
k7EEB5A9QJVEEpdIcVPmVrU5uBbg5v3gNgszg1agi+KaXqs3i+E3n91Jtd4oRIdC
6LYarOZJdbhYOjAfG9ioAb1F+IeiB2xLviHDmzWAy+oT/Kw9QIWq/3S9BA+po2AE
eEXHydHVhgpqPbspA4MLX5Hkr8O8H2lj73uOrSKa8GkR2gyak3ehKA/rGomZ
=/Yyb
-----END PGP SIGNATURE-----



From brad at fineby.me.uk  Tue Jul 11 20:53:37 2017
From: brad at fineby.me.uk (Brad Rogers)
Date: Tue, 11 Jul 2017 19:53:37 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <1769963444.20170711193808@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
Message-ID: <20170711195337.3e68ebf7@abydos.stargate.org.uk>

On Tue, 11 Jul 2017 19:38:08 +0100
MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:

Hello MFPA,

>Surely things like 1234 can be prevented by software.

Sure.

The question is "Are they?"

I suspect(1) the answer, in many cases, is "No."

(1) My gut feeling - I have no evidence/proof.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Chose to play the fool in a six piece band
What A Waste - Ian Dury And The Blockheads
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170711/6af4be32/attachment.sig>

From guru at unixarea.de  Tue Jul 11 21:09:15 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 11 Jul 2017 21:09:15 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <1769963444.20170711193808@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
Message-ID: <20170711190915.GB27477@c720-r314251>

El d?a martes, julio 11, 2017 a las 07:38:08p. m. +0100, MFPA escribi?:

> On Tuesday 11 July 2017 at 8:44:48 AM, in
> <mid:3499376d-11fb-9854-688a-48e054166647 at binarus.de>, Binarus wrote:-
> 
> 
> > I am not sure if this is an intentional limitation of
> > the cards (to
> > prevent users from choosing idiotic pins like 1234 or
> > their birthday).
> 
> 
> Surely things like 1234 can be prevented by software.

Why 1234 is an idiotic PIN? What are idiotic PINs? Of course, idiotic is
any PIN which has in your pocket hints about this (like a sticker attached
or your birthday). But remember, you normally have 3 tries only to test
all "idiotic" PINs. 1234 is same idiotic as 2345 or as 3456 or .... or as
6666, or 7777, or ...

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170711/d51a6371/attachment-0001.sig>

From dkg at fifthhorseman.net  Wed Jul 12 01:55:52 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 11 Jul 2017 19:55:52 -0400
Subject: gpgme - raw RSA operation using GPG public/private keys?
In-Reply-To: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>
References: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>
Message-ID: <87d196y1dj.fsf@fifthhorseman.net>

On Fri 2017-07-07 18:01:03 +0200, gnupg-user at niob.at wrote:

> I am looking for a "simple" way to use a GPG public/private RSA key to
> do "raw" RSA operations. I have the impression, that gpgme only deals
> with "real" OpenPGP data structures, but this does not fit my use case.
> This is for an application that is currently based on openssl crypto.

you're right -- gpgm is only for higher-level protocol operations,
whether they're OpenPGP or CMS (cryptographic message syntax).  it
doesn't offer low-level crypto primitives.

if you want low-level crypto primitives that are GPL-compatible, you can
use libhogweed (from the nettle project) or libgcrypt.

Modern GnuPG uses libgcrypt for its crypto primitives, fwiw.

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170711/9ba31666/attachment.sig>

From lists at binarus.de  Wed Jul 12 07:51:42 2017
From: lists at binarus.de (Binarus)
Date: Wed, 12 Jul 2017 07:51:42 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <1769963444.20170711193808@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
Message-ID: <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>

On 11.07.2017 20:38, MFPA wrote:
> 
> 
> On Tuesday 11 July 2017 at 8:44:48 AM, in
> <mid:3499376d-11fb-9854-688a-48e054166647 at binarus.de>, Binarus wrote:-
> 
> 
>> I am not sure if this is an intentional limitation of
>> the cards (to
>> prevent users from choosing idiotic pins like 1234 or
>> their birthday).
> 
> 
> Surely things like 1234 can be prevented by software.
> 

But birthdays and the like probably not.

Furthermore (not being sure, so read with care), I think that the bank
does not know your pin, but it is stored in the banks' backends as some
sort of hash, and this means that such software would have to run on the
card.

Regards,

Binarus



From lists at binarus.de  Wed Jul 12 08:09:06 2017
From: lists at binarus.de (Binarus)
Date: Wed, 12 Jul 2017 08:09:06 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <20170711190915.GB27477@c720-r314251>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net> <20170711190915.GB27477@c720-r314251>
Message-ID: <59974e25-9cf9-f418-f8ce-9ec6056372ea@binarus.de>

On 11.07.2017 21:09, Matthias Apitz wrote:

> Why 1234 is an idiotic PIN? What are idiotic PINs? Of course, idiotic is
> any PIN which has in your pocket hints about this (like a sticker attached
> or your birthday). But remember, you normally have 3 tries only to test
> all "idiotic" PINs. 1234 is same idiotic as 2345 or as 3456 or .... or as
> 6666, or 7777, or ...

According to my understanding, the most idiotic PIN exactly is the one
with the highest probability of being guessed, in other words, the one
that is most often used by other people as well.

You are right in a mathematical sense, but you leave out the human
factor. If all people would choose their PINs freely, PINs for sure were
not equally distributed. 10% of the pins would be 1111, another 10%
1234, another 30% their owner's birthday and so on.

A little bit of statistics (your name sounds German):
http://www.sueddeutsche.de/wissen/unsichere-pin-codes-erwischt-1.1486312

I don't have time for a thorough research right now, but this article
gives us an idea. I don't think the situation has changed much since
2012 ...

Regards,

Binarus



From jhs at berklix.com  Wed Jul 12 11:22:07 2017
From: jhs at berklix.com (Julian H. Stacey)
Date: Wed, 12 Jul 2017 11:22:07 +0200
Subject: Changing PINs of German bank card
In-Reply-To: Your message "Wed, 12 Jul 2017 08:09:06 +0200."
 <59974e25-9cf9-f418-f8ce-9ec6056372ea@binarus.de>
Message-ID: <201707120922.v6C9M75F037873@fire.js.berklix.net>

> A little bit of statistics (your name sounds German):
> http://www.sueddeutsche.de/wissen/unsichere-pin-codes-erwischt-1.1486312

I read the German, here's English):
http://www.berklix.org/trans/	->
https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.sueddeutsche.de%2Fwissen%2Funsichere-pin-codes-erwischt-1.1486312&edit-text=&act=url

Julian
-- 
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#700k_stolen_votes


From guanx.bac at gmail.com  Wed Jul 12 11:42:11 2017
From: guanx.bac at gmail.com (Guan Xin)
Date: Wed, 12 Jul 2017 17:42:11 +0800
Subject: Changing PINs of German bank card
In-Reply-To: <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
Message-ID: <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>

On Wed, Jul 12, 2017 at 1:51 PM, Binarus <lists at binarus.de> wrote:

> On 11.07.2017 20:38, MFPA wrote:
> >
> >
> > On Tuesday 11 July 2017 at 8:44:48 AM, in
> > <mid:3499376d-11fb-9854-688a-48e054166647 at binarus.de>, Binarus wrote:-
> >
> >
> >> I am not sure if this is an intentional limitation of
> >> the cards (to
> >> prevent users from choosing idiotic pins like 1234 or
> >> their birthday).
> >
> >
> > Surely things like 1234 can be prevented by software.
> >
>
> But birthdays and the like probably not.
>
> Furthermore (not being sure, so read with care), I think that the bank
> does not know your pin, but it is stored in the banks' backends as some
> sort of hash, and this means that such software would have to run on the
> card.
>
> Such software can run on ATMs if that are the only places where one can
change the PIN.
And I don't think the bank needs the hash of the PIN. They may need the
hash of the key(s) protected by the PIN, however.

Guan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170712/ccbd379a/attachment.html>

From lists at binarus.de  Wed Jul 12 12:01:35 2017
From: lists at binarus.de (Binarus)
Date: Wed, 12 Jul 2017 12:01:35 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
Message-ID: <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>

On 12.07.2017 11:42, Guan Xin wrote:
> On Wed, Jul 12, 2017 at 1:51 PM, Binarus <lists at binarus.de
> <mailto:lists at binarus.de>> wrote:
> 
>     On 11.07.2017 20:38, MFPA wrote:
>     >
>     >
>     > On Tuesday 11 July 2017 at 8:44:48 AM, in
>     > <mid:3499376d-11fb-9854-688a-48e054166647 at binarus.de
>     <mailto:mid%3A3499376d-11fb-9854-688a-48e054166647 at binarus.de>>,
>     Binarus wrote:-
>     >
>     >
>     >> I am not sure if this is an intentional limitation of
>     >> the cards (to
>     >> prevent users from choosing idiotic pins like 1234 or
>     >> their birthday).
>     >
>     >
>     > Surely things like 1234 can be prevented by software.
>     >
> 
>     But birthdays and the like probably not.
> 
>     Furthermore (not being sure, so read with care), I think that the bank
>     does not know your pin, but it is stored in the banks' backends as some
>     sort of hash, and this means that such software would have to run on the
>     card.
> 
> Such software can run on ATMs if that are the only places where one can
> change the PIN.
> And I don't think the bank needs the hash of the PIN. They may need the
> hash of the key(s) protected by the PIN, however.

Not sure about that. Similar to serious websites which don't store your
password in clear text, but do store the password's hash instead, I
would expect that banks don't store your PIN in clear text as well.

As far as I know, no bank will be able to tell you your PIN if you have
forgotten it even if you go there and show them your passport. They can
only generate a new one (or a new card), but they can't tell you the
existing one because they just don't know it.

That means that the bank's backend will never see the PIN you choose and
thus can never decide if it is insecure (i.e. something like 1111). If a
bank decides to handle the PINs that way, they probably won't allow the
ATM to get hold of the PIN in clear text as well.

I might be wrong, though.

Regards,

Binarus








From peter at digitalbrains.com  Wed Jul 12 12:10:12 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 12 Jul 2017 12:10:12 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
Message-ID: <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>

On 12/07/17 07:51, Binarus wrote:
> Furthermore (not being sure, so read with care), I think that the bank
> does not know your pin

When my bank card is replaced because its validity is about to end, the
new card has the same PIN as the old one. I can't readily think of a way
to do that without the bank knowing my PIN, since the new card didn't
physically exist yet when the old card got its copy of the PIN.[1]
Furthermore, I see no use to the bank not knowing my PIN. If their
backend got hacked, these random 4 digits being public knowledge are the
least of the problems.

And since a pin has so low entropy, I don't see how to protect it with a
hash. Any system that can verify correctness in the time it takes to do
a PIN payment[2] can do 10,000 guesses in reasonable time.

Also, back when you could do payments with the magstripe (which, AFAIK,
can still be done in some countries, using your Dutch bank card, if you
allow it), the PIN necessarily went to the bank, there was no way for a
check by the chip in the card.

Anyway, I'm still writing this even though I questioned its usefulness.
But let's consider whether this thread really needs to go on much
longer, it seems it has run its course and is now turning into a wide
trickling delta that is no longer hurrying towards its destination but
rather seeking the path of least resistance in any random direction :-).

Cheers,

Peter.

[1] Barring any neat trickery like waiting for me to enter my PIN and
listening in so they can then program the new card.

[2] That's what they're called in The Netherlands. Well, PIN-betaling
actually, I did translate.

-- 
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: </pipermail/attachments/20170712/f87b655b/attachment-0001.sig>

From ndk.clanbo at gmail.com  Wed Jul 12 12:27:41 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Wed, 12 Jul 2017 12:27:41 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
 <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
Message-ID: <bf892a1c-dc4e-0bac-7956-6c54a4b2495c@gmail.com>

Il 12/07/2017 12:01, Binarus ha scritto:

> Not sure about that. Similar to serious websites which don't store your
> password in clear text, but do store the password's hash instead, I
> would expect that banks don't store your PIN in clear text as well.
Even with 6-digits PIN it would take *seconds* to an attacker to brute
force hashed PINs once he gets the hashed database. Salted hashes would
multiply the needed time by the number of PINs (approx).
So keeping such a database would be a really stupid thing to do --
unless it's kept in a HSM.

Passwords have way larger key space (from 10^N for N digits of the PIN
to 64^N or more for the passwords -- considering uppercase, lowercase,
digits and symbols), hence salted hashes are quite secure.

BYtE,
 Diego


From lists at binarus.de  Wed Jul 12 15:49:47 2017
From: lists at binarus.de (Binarus)
Date: Wed, 12 Jul 2017 15:49:47 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <bf892a1c-dc4e-0bac-7956-6c54a4b2495c@gmail.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
 <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
 <bf892a1c-dc4e-0bac-7956-6c54a4b2495c@gmail.com>
Message-ID: <3aa73b32-6177-3560-9f78-a0b5afe4d4c9@binarus.de>

On 12.07.2017 12:27, NdK wrote:
> Il 12/07/2017 12:01, Binarus ha scritto:
> 
>> Not sure about that. Similar to serious websites which don't store your
>> password in clear text, but do store the password's hash instead, I
>> would expect that banks don't store your PIN in clear text as well.
> Even with 6-digits PIN it would take *seconds* to an attacker to brute
> force hashed PINs once he gets the hashed database. [...]

While this is correct, it is no reason for not doing it that way (if we
choose to ignore the endless possibilities cryptography offers and
decide to store the PIN in some form in a backend at all).

 Salted hashes would
> multiply the needed time by the number of PINs (approx).
> So keeping such a database would be a really stupid thing to do --
> unless it's kept in a HSM.

Of course, I was talking about salted hashes. Besides that:

https://security.stackexchange.com/questions/88711/how-can-my-bank-issue-a-new-credit-card-with-the-same-pin-number

https://security.stackexchange.com/questions/62306/a-second-bank-card-arrived-with-the-same-pin

Some comments / answers in the first one claim that the PIN might be
stored in hashed form in some database. Most comments / answers in the
second one claim that the PIN is stored on HSM (they don't seem to be
sure if it is in clear text or encrypted there) (if I had more time for
research, I probably had found better explanations ... the two links
basically were on the first result page on Google when searching the
respective keywords).

But whatever: My key point was that the PIN *never* is stored (or
transmitted) in clear text outside an HSM, meaning that software which
could examine the PIN according to certain criteria will have to run
inside that HSM. I do not think that any bank has implemented such a thing.

Regards,

Binarus


From neal at walfield.org  Wed Jul 12 15:57:48 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 12 Jul 2017 15:57:48 +0200
Subject: OpenPGP Notations
Message-ID: <87eftlvjtv.wl-neal@walfield.org>

Hi,

I'm collection examples of notations.  If you somehow use notations,
I'd love to hear how you are using them.  (If you prefer to remain
anonymous, please feel free to reply privately.)

Also, I'm curious if anyone has a good use for unsigned ("unhashed")
notations.

Thanks!

:) Neal

Key: 8F17 7771 18A3 3DDA 9BA4  8E62 AACB 3243 6300 52D9


From lists at binarus.de  Wed Jul 12 16:15:09 2017
From: lists at binarus.de (Binarus)
Date: Wed, 12 Jul 2017 16:15:09 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
Message-ID: <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>

On 12.07.2017 12:10, Peter Lebbing wrote:
> On 12/07/17 07:51, Binarus wrote:
>> Furthermore (not being sure, so read with care), I think that the bank
>> does not know your pin
> 
> When my bank card is replaced because its validity is about to end, the
> new card has the same PIN as the old one. I can't readily think of a way
> to do that without the bank knowing my PIN, since the new card didn't
> physically exist yet when the old card got its copy of the PIN.[1]

See

https://security.stackexchange.com/questions/62306/a-second-bank-card-arrived-with-the-same-pin

and

https://security.stackexchange.com/questions/88711/how-can-my-bank-issue-a-new-credit-card-with-the-same-pin-number

> Furthermore, I see no use to the bank not knowing my PIN. If their
> backend got hacked, these random 4 digits being public knowledge are the
> least of the problems.
> 
> And since a pin has so low entropy, I don't see how to protect it with a
> hash. Any system that can verify correctness in the time it takes to do
> a PIN payment[2] can do 10,000 guesses in reasonable time.

Right, but no reason to not do it that way (if the PIN needs to be
stored at all in some backend which I doubt).
> Also, back when you could do payments with the magstripe (which, AFAIK,
> can still be done in some countries, using your Dutch bank card, if you
> allow it), the PIN necessarily went to the bank, there was no way for a
> check by the chip in the card.

I never did look into the magstripe technique ... so no clue here. I
only know that those cards could be copied easily.

> Anyway, I'm still writing this even though I questioned its usefulness.
> But let's consider whether this thread really needs to go on much
> longer, it seems it has run its course and is now turning into a wide
> trickling delta that is no longer hurrying towards its destination but
> rather seeking the path of least resistance in any random direction :-).

You are right - let's finish.

Regards,

Binarus


From damien at cassou.me  Wed Jul 12 19:35:34 2017
From: damien at cassou.me (Damien Cassou)
Date: Wed, 12 Jul 2017 19:35:34 +0200
Subject: Don't get the pinentry for passphrase in some contexts
Message-ID: <87bmoph82h.fsf@cassou.me>

Hi,

I have the attached application below that just tries to decrypt a file
with gpg2. When the gpg-agent has an empty cache (I temporarily set
max-cache-ttl to 0 while testing), the application has different
behavior when ran from a terminal or from a Firefox add-on:

1- in the terminal, I get the pinentry application that asks me to enter
   the passphrase for the gpg key used to encrypt the file;

2- when launched from a Firefox web extension's browser action (Firefox
   itself being launched with `web-ext run` from the same terminal), I
   just get an error: "Public key decryption failed: Operation
   canceled. Decryption failed: No secret key". I'm never asked for my
   passphrase.

Others have reported the exact same problem with another web-extension
and another native application (written in Go):
https://github.com/dannyvankooten/browserpass/issues/23

I checked the environment variables and they are very much similar (diff
attached).

Do you have any clue what could be different in the two environments
that could cause gpg2 to behave differently?

I sent the same message to the dedicated mailing-list at mozilla.org:
https://mail.mozilla.org/pipermail/dev-addons/2017-July/002966.html. They
suggested I contact you.

Thank you

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: index-decrypt.txt
URL: </pipermail/attachments/20170712/f155687f/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.diff
Type: text/x-patch
Size: 2296 bytes
Desc: not available
URL: </pipermail/attachments/20170712/f155687f/attachment.bin>

From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jul 13 01:19:28 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 13 Jul 2017 00:19:28 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
Message-ID: <22773540.20170713001928@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 12 July 2017 at 6:51:42 AM, in
<mid:109b00fe-7524-69e7-a3cd-94156eef75b0 at binarus.de>, Binarus wrote:-


>and this means that such software would
> have to run on the
> card.

Or The ATM.

But maybe chip and PIN cards have the capacity.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

If you save the world too often, it begins to expect it
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWauiF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5P3eAQD1OBo4LM/yLyQssGkVJEmgqn5OIpXCDt2coob3kzY5WQEA9ZhYPROmiMvt
WMpRAm0NREyj7rl8opW7BGnUjs2iogyJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWaupV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8EhLB/9zPxVUybSMna2DgDDn2oLyfRvy
jUh79wzyxmJKPCvny/IVt15ax6JaGY4nNbw2uZTgvnHpyPWS2SKNahrC6+gCR9Jz
YMYzctU42VoKvpCZQE+AouuJIAdCRy/hCkQ7r6wI4w5UC3fjvV6nfiObO0RMTf9H
o3eodkUVmbGaZBJnraa9Zl6aqoqhaUbqicbBckHdNqCgSRAGG9xKW44dmsnaIvdp
r/43xYLoVSJw1GTnfenaYChn9yD6/R0rSZB780qgu5+lmmUOqUETwZDteTnHoSKL
948ntbgD3XgfXZ5NFZkk+q+5pRbzRf/V4uMROSPNvVxuykcm2XQMYZvcVKDs
=gCEn
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jul 13 01:23:40 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 13 Jul 2017 00:23:40 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
Message-ID: <1641312905.20170713002340@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 12 July 2017 at 3:15:09 PM, in
<mid:3a6ef797-5e26-7b2c-d740-ee85d9750534 at binarus.de>, Binarus wrote:-



> (if the
> PIN needs to be
> stored at all in some backend which I doubt).

The Bank must know the PIN (or a hash). Otherwise they would not know
if you entered the correct PIN for online transactions.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

War is a matter of vital importance to the State.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWavfl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5EszAPkBdc66gr6xgI+8/wFHlBwtPb+58kIumnL+XVILJ8EZBAD9HD2PgEEKU9j5
VfvdM0iCOzT7K3ZSoUVj9Nl5XyCsLw6JAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWavfl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8AeyB/4+7JPyR9ez4d2AsXzhS2icXOr8
kawHn5FozBjiwFaNdvzkwgUNP957+3eCOwF1+q/IXJyWwm0DuV76ZNfTbfKSqGAn
2RYNIvcnq85MeoYoV1tuSKUqHW3dZO67Dj5cYRzw/mZljRamDTBy7yh2ylwo15uk
F0Eo/cbxqfSKF2QE2oCz6jNeWAvN5RfgqAx0x8CiU4lcwN7GgmQR8HzDH3Sl7tev
glxl1XJq1+Ht2UNiHL2bDK8abWqdA5sRGnBwnwxXVkaE/dp77HpsMXcvH5+egnrN
YUW7jY1/COIvdyHzuU9CfTmss+GPnvC2jo77muBYd5b7onI2YRpFEVUfiaMk
=Wz8h
-----END PGP SIGNATURE-----



From lists at binarus.de  Thu Jul 13 08:18:41 2017
From: lists at binarus.de (Binarus)
Date: Thu, 13 Jul 2017 08:18:41 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <1641312905.20170713002340@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
Message-ID: <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>

On 13.07.2017 01:23, MFPA wrote:
> 
> 
> On Wednesday 12 July 2017 at 3:15:09 PM, in
> <mid:3a6ef797-5e26-7b2c-d740-ee85d9750534 at binarus.de>, Binarus wrote:-
> 
> 
> 
>> (if the
>> PIN needs to be
>> stored at all in some backend which I doubt).
> 
> The Bank must know the PIN (or a hash). Otherwise they would not know
> if you entered the correct PIN for online transactions.

I don't think so. Banking chip cards contain mechanisms for local PIN
verification. You can see that an ATM (or the card) immediately decides
if the PIN is correct or not even if the ATM's network connection is
failing at that moment.

Banking chip cards furthermore contain a processor and software for
cryptographic operations, so that the endless capabilities of modern
cryptography are at hand. Think of asymmetric methods like RSA ...

Regards,

Binarus




From lists at binarus.de  Thu Jul 13 08:25:43 2017
From: lists at binarus.de (Binarus)
Date: Thu, 13 Jul 2017 08:25:43 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <22773540.20170713001928@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <22773540.20170713001928@riseup.net>
Message-ID: <86d11228-40a1-afc4-efd3-5cf09f77321d@binarus.de>

On 13.07.2017 01:19, MFPA wrote:
> 
> 
> On Wednesday 12 July 2017 at 6:51:42 AM, in
> <mid:109b00fe-7524-69e7-a3cd-94156eef75b0 at binarus.de>, Binarus wrote:-
> 
> 
>> and this means that such software would
>> have to run on the
>> card.
> 
> Or The ATM.

You are right. The ATM will get hold of the PIN in clear in case the
user wants to change it, because the user has to type it then. The ATM
theoretically could check the PIN for certain criteria in that moment,
and refuse it if appropriate.

> But maybe chip and PIN cards have the capacity.
> 

Wherever it might run: I never have heard about a bank having
implemented such checks ...

Regards,

Binarus


From wk at gnupg.org  Thu Jul 13 09:27:56 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Jul 2017 09:27:56 +0200
Subject: Questions using GPGME
In-Reply-To: <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com> (Andreas
 Heinlein's message of "Thu, 6 Jul 2017 14:48:47 +0200")
References: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
 <87h8ypai5d.fsf@europa.jade-hamburg.de>
 <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com>
Message-ID: <87iniwkd8j.fsf@wheatstone.g10code.de>

On Thu,  6 Jul 2017 14:48, aheinlein at gmx.com said:

> decrypt with cancel'ing the pinentry, one with missing private key and
> one with a truncated input file. All three gave
>
> print str(e): Invocation of gpgme_op_decrypt_verify: GPGME: Decryption
> failed

This has been fixed yesterday in GPGME.  You will now get back a
dedicated error code for "No secret keys", "Bad passphrase", and
"Canceled".  You need to wait for the releale of 1.9.1, though.


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: </pipermail/attachments/20170713/3517345b/attachment.sig>

From wk at gnupg.org  Thu Jul 13 09:35:18 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Jul 2017 09:35:18 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
In-Reply-To: <d3ce8d67-003e-de61-b24b-a2ea3af20968@ruhr-uni-bochum.de> (Marcus
 Brinkmann via Gnupg-users's message of "Wed, 5 Jul 2017 21:39:26
 +0200")
References: <87r2y35k2z.fsf@wheatstone.g10code.de>
 <595B6854.8030300@vulcan.xs4all.nl>
 <87podgqi57.fsf@wheatstone.g10code.de>
 <201707051613.07050.bernhard@intevation.de>
 <d3ce8d67-003e-de61-b24b-a2ea3af20968@ruhr-uni-bochum.de>
Message-ID: <87bmookcw9.fsf@wheatstone.g10code.de>

On Wed,  5 Jul 2017 21:39, gnupg-users at gnupg.org said:

>>   libgcrypt v<=?
>
> Probably all versions up to 1.7.7, starting from at least 1.2.0 (which
> is the oldest I could find).

Actaully starting at 1.6.0 which introduced the sliding window method to
catch up performance losses due to other side channel attack
mitigations.  Earlier versions than 1.6 may be affected by other side
channel attacks.


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: </pipermail/attachments/20170713/21f4028e/attachment.sig>

From aheinlein at gmx.com  Thu Jul 13 09:48:16 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 13 Jul 2017 09:48:16 +0200
Subject: Questions using GPGME
In-Reply-To: <87iniwkd8j.fsf@wheatstone.g10code.de>
References: <a87ac5e2-cf29-b8ee-f619-2cf51aa0894b@gmx.com>
 <87h8ypai5d.fsf@europa.jade-hamburg.de>
 <1f5e56bc-b484-ae43-2f3b-774637d926b4@gmx.com>
 <87iniwkd8j.fsf@wheatstone.g10code.de>
Message-ID: <0995b453-f5df-c2b3-a08f-b02b6b54c4eb@gmx.com>

Am 13.07.2017 um 09:27 schrieb Werner Koch:
> On Thu,  6 Jul 2017 14:48, aheinlein at gmx.com said:
>
>> decrypt with cancel'ing the pinentry, one with missing private key and
>> one with a truncated input file. All three gave
>>
>> print str(e): Invocation of gpgme_op_decrypt_verify: GPGME: Decryption
>> failed
> This has been fixed yesterday in GPGME.  You will now get back a
> dedicated error code for "No secret keys", "Bad passphrase", and
> "Canceled".  You need to wait for the releale of 1.9.1, though.
>
>
>
I know, I filed the bug report ;-)

Thanks again.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170713/30bbcec9/attachment.sig>

From hello at ryanlue.com  Thu Jul 13 09:03:54 2017
From: hello at ryanlue.com (Ryan Lue)
Date: Thu, 13 Jul 2017 15:03:54 +0800
Subject: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works
 fine?
In-Reply-To: <87bmp59ngc.fsf@fifthhorseman.net>
References: <20170630035446.lfjxtbmbqpdwohah@liberte>
 <87bmp59ngc.fsf@fifthhorseman.net>
Message-ID: <20170713070354.GA62499@liberte>

Hi Daniel,

Yes, thanks, this absolutely did it! Sorry for not responding earlier ?
I had intended to write a follow-up blog post that addressed this
question, along with that of forwarding the gpg-agent socket over SSH
with `ssh -R` (so that you can use your local machine's GPG private keys
in a remote session without having to manually copy them to another
machine), but figuring out how to do all that with pinentry-curses has
proven to be a real pickle.

So while I was originally going to wait until I'd finished that post and
send it back your way (as a weird kind of thank-you?), I'm just gonna
have to settle for actually saying ?thank you? for the time being.

So, thanks.

?Ryan

On 2017 Jun 30, Daniel Kahn Gillmor wrote:
> Hi Ryan--
> 
> On Fri 2017-06-30 11:54:46 +0800, Ryan Lue wrote:
> > But for some reason, it just doesn't work with `pinentry-curses`: SSH
> > (GPG) key authentication fails silently, and the server falls back to
> > password authentication. (I have made sure to set `$GPG_TTY`, so
> > `pinentry-curses` works just fine for everything else, just not SSH
> > authentication. For instance, I can `echo hello | gpg -s` and I'll get
> > the pinentry password prompt in the terminal.)
> 
> setting GPG_TTY only works for clients that know to interpret it and to
> pass its value along to gpg-agent.
> 
> when ssh is speaking to gpg-agent, it's using the ssh-agent protocol,
> which has no mechanism for passing this info to the agent.
> 
> as a result, the agent (which *isn't* running attached to the current
> tty) can't tell pinentry which tty to use.
> 
> have you tried doing this:
> 
>     GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye
> 
> from the current terminal before trying to use ssh?
> 
> i consider this a workaround (which isn't satisfactory for easy everyday
> use without better integration), but it's probably better than nothing.
> 
> please let the list know if that workarund works for you!
> 
> regards,
> 
>      --dkg




From hello at ryanlue.com  Thu Jul 13 09:29:21 2017
From: hello at ryanlue.com (Ryan Lue)
Date: Thu, 13 Jul 2017 15:29:21 +0800
Subject: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works
 fine?
In-Reply-To: <f07b1d5d-e8b4-024f-2e53-5bcfd8a61789@digitalbrains.com>
References: <20170630035446.lfjxtbmbqpdwohah@liberte>
 <f07b1d5d-e8b4-024f-2e53-5bcfd8a61789@digitalbrains.com>
Message-ID: <20170713072921.GB62499@liberte>

> However, I think many people work around this problem by a) using a
> graphical pinentry and b) using a single graphical session. As long as
> one also refrains from SSH'ing from a remote terminal, with the
> combination, you've circumvented the problem by just using the
> effectively singleton graphical session :-).

That solution has certainly occurred to me. There were two reasons I was
really angling to get this working purely in the terminal:

1) I keep my dotfiles synced between multiple machines, and so try my
   best to keep them platform-agnostic when I can. There are definitely
   times when I can use conditionals to get different behavior on
   different machines (like `if [ "$(uname)" = Darwin ]` in `.profile`),
   but I don't even know if it's possible to set up `gpg-agent.conf` to
   use `pinentry-mac` on one machine but `pinentry-gtk` on another.

2) I chanced upon this presentation from a 2015 conference where the
   presenter describes a setup for being able to ssh into a machine and
   use its private keys locally by forwarding the remote machine's
   gpg-agent socket to a local socket (slides 57?61 of 62):

   https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf

   and I imagine that just wouldn't work if you had graphical pinentry
   on the remote machine. I did also find another tip about using
   `PINENTRY_USER_DATA` to force pinentry-curses for SSH sessions, but
   I'd already burned so much time on this that I haven't been able to
   justify getting around to it again:

   https://gpgtools.tenderapp.com/kb/faq/enter-passphrase-with-pinentry-in-terminal-via-ssh-connection

   None of this was crucial, mind you; I was just trying to see what I
   could do with a new toy. -_-'

> That is a surprising characterization. Do they also think this of the
> GNOME and KDE SSH agents, to name two? I suspect those two are much more
> widely used, which might eliminate the qualification "unconventional",
> but that still begs, why "hack"?

There were a lot of strong opinions being thrown around that thread. I
suspect that a lot of people believe that taking an unconventional
approach to security is tantamount to opposing best practices.

In any case, thanks for all the insight!

?Ryan


From guru at unixarea.de  Thu Jul 13 12:49:42 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 13 Jul 2017 12:49:42 +0200
Subject: use policy of the GnuPG-card
Message-ID: <20170713104942.GA78965@c720-r314251>


Hello,

I'm using the GnuPG card for signing, SSH, password-store (Firefox web passwords)
and locking un-locking the KDE desktop on card-insert or withdraw.
After resolving some technical (FreeBSD) issues, I now have it on daily
usage on my netbook and my workstation in the office.

One problem comes obviously in mind: Someone with priv access to your workstation,
for example IT personal, could relatively easy steal your passwords, just setting your
environment and waiting for the moment that you have unlocked the card with the PIN;
than he/she could run as root:

# GNUPGHOME=/home/guru/.gnupg-ccid export GNUPGHOME
# PASSWORD_STORE_DIR=/home/guru/.password-store export PASSWORD_STORE_DIR
# pass Business/cheese-whiz-factory
gpg: WARNING: unsafe ownership on homedir '/home/guru/.gnupg-ccid'
cheese

It would also not help to just withdraw the card after any short usage, for example to
fire up a SSH session. The attacker could just sit in background waiting for this short moment,
which is long enough to copy all your passwords in to clear mode and send them away.

How is this supposed to be managed?


         matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170713/800ea5bd/attachment-0001.sig>

From peter at digitalbrains.com  Thu Jul 13 12:50:22 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 13 Jul 2017 12:50:22 +0200
Subject: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works
 fine?
In-Reply-To: <20170713072921.GB62499@liberte>
References: <20170630035446.lfjxtbmbqpdwohah@liberte>
 <f07b1d5d-e8b4-024f-2e53-5bcfd8a61789@digitalbrains.com>
 <20170713072921.GB62499@liberte>
Message-ID: <4fd225ef-4734-805d-a0ab-de6475e76696@digitalbrains.com>

On 13/07/17 09:29, Ryan Lue wrote:
> 1) I keep my dotfiles synced between multiple machines, and so try my
>    best to keep them platform-agnostic when I can. There are definitely
>    times when I can use conditionals to get different behavior on
>    different machines (like `if [ "$(uname)" = Darwin ]` in `.profile`),
>    but I don't even know if it's possible to set up `gpg-agent.conf` to
>    use `pinentry-mac` on one machine but `pinentry-gtk` on another.

Note how Debian handles system-wide, system-specific pinentry alternatives:

/etc/alternatives/pinentry -> /usr/bin/pinentry-gtk-2
/etc/alternatives/pinentry-x11 -> /usr/bin/pinentry-gtk-2
/usr/bin/pinentry -> /etc/alternatives/pinentry
/usr/bin/pinentry-curses
/usr/bin/pinentry-gtk-2
/usr/bin/pinentry-x11 -> /etc/alternatives/pinentry-x11

If you use just "pinentry" or "pinentry-x11", you then use the
alternatives system to select a specific one:

--8<---------------cut here---------------start------------->8---
# update-alternatives --config pinentry
There are 2 choices for the alternative pinentry (providing
/usr/bin/pinentry).

  Selection    Path                      Priority   Status
------------------------------------------------------------
* 0            /usr/bin/pinentry-gtk-2    85        auto mode
  1            /usr/bin/pinentry-curses   50        manual mode
  2            /usr/bin/pinentry-gtk-2    85        manual mode

Press enter to keep the current choice[*], or type selection number:
--8<---------------cut here---------------end--------------->8---

It might give you an idea how to do it for you. I suspect it might even
work if you wrap your pinentry in a shell script using if [ "$(uname)"
but it lacks elegance.

> 2) I chanced upon this presentation from a 2015 conference where the
>    presenter describes a setup for being able to ssh into a machine and
>    use its private keys locally by forwarding the remote machine's
>    gpg-agent socket to a local socket (slides 57?61 of 62):
> 
>    https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf
> 
>    and I imagine that just wouldn't work if you had graphical pinentry
>    on the remote machine.

You could also use SSH's X forwarding. I haven't tried that, though.

> There were a lot of strong opinions being thrown around that thread. I
> suspect that a lot of people believe that taking an unconventional
> approach to security is tantamount to opposing best practices.

Hmmm, an understandable knee-jerk response. Knees don't always do your
best thinking, though.

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: </pipermail/attachments/20170713/2b2f79b7/attachment.sig>

From andrewg at andrewg.com  Thu Jul 13 13:44:42 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 13 Jul 2017 12:44:42 +0100
Subject: use policy of the GnuPG-card
In-Reply-To: <20170713104942.GA78965@c720-r314251>
References: <20170713104942.GA78965@c720-r314251>
Message-ID: <75628979-d0ab-1269-a73b-0b5393b24122@andrewg.com>

On 2017/07/13 11:49, Matthias Apitz wrote:
> 
> One problem comes obviously in mind: Someone with priv access to your workstation,
> for example IT personal, could relatively easy steal your passwords, just setting your
> environment and waiting for the moment that you have unlocked the card with the PIN;
> than he/she could run as root:

*snipped evil plan*

Worse than that, they can keylog your PIN and use that to perform
unlimited crypto operations using your smartcard whenever they detect it
is plugged in. Or they can read decrypted passwords out of memory, or
replace gpg with a version that copies everything it touches to a
network connection. The possibilities are literally endless.

> How is this supposed to be managed?

Don't plug your smartcard into a computer that someone else has root
access to. That's not flippant, that's the best you can do in principle.
Smartcards can protect you against disclosure of your secret key, but
not of data encrypted to that key. If you want to protect all the data
encrypted by that key, then you still need to take all the precautions
that you need to with any other method of secret key storage, and that
means (amongst other things) don't decrypt your data on an untrusted
machine.

Remember, if someone else has root on your computer then it isn't your
computer - it's theirs.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170713/d41b31bf/attachment.sig>

From aheinlein at gmx.com  Thu Jul 13 14:30:37 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 13 Jul 2017 14:30:37 +0200
Subject: use policy of the GnuPG-card
In-Reply-To: <75628979-d0ab-1269-a73b-0b5393b24122@andrewg.com>
References: <20170713104942.GA78965@c720-r314251>
 <75628979-d0ab-1269-a73b-0b5393b24122@andrewg.com>
Message-ID: <4da713e7-95f8-4ae0-23f0-4e8f9ad3d471@gmx.com>

Am 13.07.2017 um 13:44 schrieb Andrew Gallagher:
> On 2017/07/13 11:49, Matthias Apitz wrote:
>> One problem comes obviously in mind: Someone with priv access to your workstation,
>> for example IT personal, could relatively easy steal your passwords, just setting your
>> environment and waiting for the moment that you have unlocked the card with the PIN;
>> than he/she could run as root:
> *snipped evil plan*
>
> Worse than that, they can keylog your PIN and use that to perform
> unlimited crypto operations using your smartcard whenever they detect it
> is plugged in. Or they can read decrypted passwords out of memory, or
> replace gpg with a version that copies everything it touches to a
> network connection. The possibilities are literally endless.
>> How is this supposed to be managed?
> Don't plug your smartcard into a computer that someone else has root
> access to. That's not flippant, that's the best you can do in principle.
> Smartcards can protect you against disclosure of your secret key, but
> not of data encrypted to that key. If you want to protect all the data
> encrypted by that key, then you still need to take all the precautions
> that you need to with any other method of secret key storage, and that
> means (amongst other things) don't decrypt your data on an untrusted
> machine.
>
> Remember, if someone else has root on your computer then it isn't your
> computer - it's theirs.
>
> A
+1 for that. If one can install software on a machine, one can
completely take it over. No way to prevent that.

For a private machine, you could encrypt the whole hard drive, making
attacks on the OS level require physical access two times: once for
installing a compromised boot loader that intercepts the password and
once again for decrypting the drive with the stolen password and
compromising the OS.

With physical access, there are still attack vectors using firmware or
hardware manipulation which also work with physical access only once.

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170713/130ac507/attachment.sig>

From damien at cassou.me  Thu Jul 13 15:08:23 2017
From: damien at cassou.me (Damien Cassou)
Date: Thu, 13 Jul 2017 15:08:23 +0200
Subject: Don't get the pinentry for passphrase in some contexts
In-Reply-To: <87bmoph82h.fsf@cassou.me>
References: <87bmoph82h.fsf@cassou.me>
Message-ID: <8760ew1o3c.fsf@cassou.me>

strace reveals the following. Does that ring a bell to anyone?

In Firefox
    read(5, "INQUIRE PINENTRY_LAUNCHED 22712\n", 1002) = 32
    write(5, "END", 3)                = 3
    write(5, "\n", 1)                 = 1
    read(5, "ERR 83886179 Operation cancelled <Pinentry>\n", 1002) = 44

In the terminal
    read(5, "INQUIRE PINENTRY_LAUNCHED 22990\n", 1002) = 32
    write(5, "END", 3)                = 3
    write(5, "\n", 1)                 = 1
    read(5, "D (5:value511...) = 543


-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill


From wk at gnupg.org  Thu Jul 13 15:57:47 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Jul 2017 15:57:47 +0200
Subject: use policy of the GnuPG-card
In-Reply-To: <20170713104942.GA78965@c720-r314251> (Matthias Apitz's message
 of "Thu, 13 Jul 2017 12:49:42 +0200")
References: <20170713104942.GA78965@c720-r314251>
Message-ID: <87bmooigmc.fsf@wheatstone.g10code.de>

On Thu, 13 Jul 2017 12:49, guru at unixarea.de said:

> How is this supposed to be managed?

You can't do anything about it.  The card protects your key against
compromise - but not the use of the key.

For the signing key we have a signature counter and if you can memorize
the count and the number of signatures you did, you have a way to detect
malicious use of that key.  Better malware could of course also present
you a different count - checking on a clean machine would detect that,
though.


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: </pipermail/attachments/20170713/3e5e3e72/attachment.sig>

From wk at gnupg.org  Thu Jul 13 16:06:08 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Jul 2017 16:06:08 +0200
Subject: Don't get the pinentry for passphrase in some contexts
In-Reply-To: <8760ew1o3c.fsf@cassou.me> (Damien Cassou's message of "Thu, 13
 Jul 2017 15:08:23 +0200")
References: <87bmoph82h.fsf@cassou.me> <8760ew1o3c.fsf@cassou.me>
Message-ID: <877ezcig8f.fsf@wheatstone.g10code.de>

On Thu, 13 Jul 2017 15:08, damien at cassou.me said:
> strace reveals the following. Does that ring a bell to anyone?

"debug-pinentry" in gpg-agent.conf would give you more info.  Adding
also "debug ipc" will show you the communication between gpg and
gpg-agent; that is what you strace shows.  Use "log-file FILE" to set a
log file and remember to reload gpg-agent.

> In Firefox
>     read(5, "INQUIRE PINENTRY_LAUNCHED 22712\n", 1002) = 32
>     write(5, "END", 3)                = 3
>     write(5, "\n", 1)                 = 1

The agent tells gpg that a pinentry has been launched and gpg
acknowledges that ("END").

>     read(5, "ERR 83886179 Operation cancelled <Pinentry>\n", 1002) = 44

The agent tells you that the Pinentry canceled the operation.  This is
usually due to clicking the cancel button.  Some older versions of
pinentry use cancel as a catch all error from pinentry.  Modern versions
of gpg running with "-v" will print a line identifing the pinentry used
and thus reveal possible problems, for example a missing GPG_TTY
envrionment variable.

>     read(5, "D (5:value511...) = 543

This returns some data ;-)


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: </pipermail/attachments/20170713/33022fda/attachment.sig>

From damien at cassou.me  Thu Jul 13 16:29:25 2017
From: damien at cassou.me (Damien Cassou)
Date: Thu, 13 Jul 2017 16:29:25 +0200
Subject: Don't get the pinentry for passphrase in some contexts
In-Reply-To: <20170713140549.GA23923@sh4-5.1blu.de>
References: <87bmoph82h.fsf@cassou.me> <8760ew1o3c.fsf@cassou.me>
 <20170713140549.GA23923@sh4-5.1blu.de>
Message-ID: <871spk1kca.fsf@cassou.me>

Matthias Apitz <guru at unixarea.de> writes:
> What do you use as pinentry exactly? I have:
>
> $ ls -l /usr/local/bin/pinentry
> lrwxr-xr-x  1 root  wheel  27 15 may.  14:04 /usr/local/bin/pinentry ->
> /usr/local/bin/pinentry-qt5
>
> and this pops up a Qt5 window for this.


For me, /usr/bin/pinentry is a 86-lines shell script that selects the
correct pinentry binary to use. In all cases, the binary used is
/usr/bin/pinentry-gnome3 (I'm on Gnome3) which is

    $ pinentry-gnome3 --version
    pinentry-gnome3 (pinentry) 0.9.7

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill


From rjh at sixdemonbag.org  Thu Jul 13 16:48:32 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 13 Jul 2017 10:48:32 -0400
Subject: use policy of the GnuPG-card
In-Reply-To: <20170713104942.GA78965@c720-r314251>
References: <20170713104942.GA78965@c720-r314251>
Message-ID: <23d094b4-075f-b767-36c4-de359562f590@sixdemonbag.org>

> One problem comes obviously in mind: Someone with priv access to your workstation,

You just lost.  Everything after this sentence is irrelevant.  Once an
attacker has privileged access to your machine it's all over.

> How is this supposed to be managed?

It can't be.  GnuPG is only for use in environments where you trust the
admins.  GnuPG cannot protect you from a rogue admin.  Do not fall into
the trap of thinking you can manage this: you cannot.


From david at gbenet.com  Fri Jul 14 11:59:43 2017
From: david at gbenet.com (david at gbenet.com)
Date: Fri, 14 Jul 2017 10:59:43 +0100
Subject: A Quick Question
Message-ID: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>

Hi All,

I want to back up and move all the keys I have - without moving the whole directory - I have
gpa kgpg and Kleopatra but none of these as far as I can see back up all your keys.

Help appreciated and thanks

David

-- 
?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the
kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No
delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAAD8C47D.asc
Type: application/pgp-keys
Size: 5036 bytes
Desc: not available
URL: </pipermail/attachments/20170714/4ddda138/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170714/4ddda138/attachment.sig>

From rjh at sixdemonbag.org  Fri Jul 14 15:51:12 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 14 Jul 2017 09:51:12 -0400
Subject: A Quick Question
In-Reply-To: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
Message-ID: <add7552a-06fb-26a7-4052-b9179d83292d@sixdemonbag.org>

> I want to back up and move all the keys I have - without moving the 
> whole directory - I have gpa kgpg and Kleopatra but none of these as
> far as I can see back up all your keys.

I wrote a tool that may help:

https://rjhansen.github.io/sherpa/


From youcanlinux at gmail.com  Fri Jul 14 16:01:57 2017
From: youcanlinux at gmail.com (Daniel Villarreal)
Date: Fri, 14 Jul 2017 09:01:57 -0500
Subject: A Quick Question
In-Reply-To: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
Message-ID: <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/14/17 04:59, david at gbenet.com wrote:
> Hi All,
> 
> I want to back up and move all the keys I have - without moving
> the whole directory - I have gpa kgpg and Kleopatra but none of
> these as far as I can see back up all your keys.

- -- begin quote --
- -------- Forwarded Message --------
Subject: RE: What is a reliable way to backup/restore my keys and test?
Date: Wed, 14 Sep 2016 15:01:47 -0400
From: Robert J. Hansen <rjh at sixdemonbag.org>
To: 'Duane Whitty' <duane at nofroth.com>, gnupg-users at gnupg.org

> I am relatively new to GNUPG so my apologies in advance if this >
question is trivial.

Welcome!  And your question is not trivial.

The following is the procedure I use on UNIX systems:

First, export all public certificates into a public keyring:

	$ gpg --armor --export > pub.asc

Second, export all secret certificates into a secret keyring:

	$ gpg --armor --export-secret-keys > priv.asc

Third, export ownertrust values and save those:

	$ gpg --armor --export-ownertrust > trust.asc

Fourth, copy all the *.conf files in ~/.gnupg into your current director
y:

	$ cp ~/.gnupg/*.conf .

Fifth,  put these, and all your GnuPG .conf files, all into a single
archive:

	$ tar cJf gpg-backup.txz pub.asc priv.asc trust.asc *.conf

Copy gpg-backup.txz to the new machine.  Once you've done that,
uncompress it on the new machine:

	$ tar xJf gpg-backup.txz

Import your secret certificates:

	$ gpg --import < priv.asc

Import your public certificates:

	$ gpg --import < pub.asc

Import your ownertrust values:

	$ gpg --import-ownertrust < trust.asc

Make sure your ~/.gnupg directory exists.  If it doesn't, run gpg with
no arguments and hit Ctrl-C to break out of it.

	$ gpg

Copy your .conf files into ~/.gnupg:

	$ cp *.conf ~/.gnupg

... And at that point you should be done.  This technique should work
regardless of whether you're migrating from 1.4 to 2.0, 1.4 to 2.1,
2.0 to 1.4, 2.0 to 2.1, 2.1 to 2.0, or 2.1 to 1.4.  No matter which
you're doing, you're covered.

> I've just copied my .gnupg directory to a usb key as a backup 
> measure, which I found as a method (more or less) on 
> http://www.glump.net/content/gpg_intro/.

It's a good idea to not copy the random_seed file.  PRNG states should
not be shared between computers.

> How can I make sure my private key and trust assignments were 
> copied properly?

Follow the above process and they will be.  Your private certificates
were exported, as were the trust assignments.

> Once I have completed my OS upgrade how do I restore my keys and 
> the trust levels assigned to them?

See the above process.

> I use Thunderbird/Enigmail which is using gpg2 but I originally 
> created my key pair using gpg 1.4.  Does this have any 
> ramifications?

None.

- --end quote--


- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZaM7NAAoJEPJRiTioPntJXq0H/iz1xXlP+fr+l7Af57Q7yWpA
S9KOR3nVs/HVrIxPb8Ck5/+oo+UctgazpU8SCUWJh29GEvHoRWdEN4HiqbJ3p5Hb
bFS6u9LXSQGO4OB+gsJNv+JrkjMuLxEEVinFM5/sA00l956Dw2u942GBLgyWEIv7
Z4P7gpDdyPEIDIjk6Gx0G1CMZoQHxTX4vsw6Rf+WIwtaZt1DNO+bkmPij5hy9HsW
VWrG/7A4PxVo3+hMquVaBpy5tsqEhOdLqbjcVnoAa9ykWogLclASdEtcJCPiMiOS
6byXTfBdtgbRWbGDxvJj2MSnSx/EueWefDjieBXxigQJE46qjkONujNerPTwODk=
=CGoq
-----END PGP SIGNATURE-----


From david at gbenet.com  Fri Jul 14 20:01:43 2017
From: david at gbenet.com (david at gbenet.com)
Date: Fri, 14 Jul 2017 19:01:43 +0100
Subject: A Quick Question
In-Reply-To: <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
Message-ID: <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>

On 14/07/17 15:01, Daniel Villarreal wrote:
> On 07/14/17 04:59, david at gbenet.com wrote:
Thank you for your contributions Daniel and Robert

Best Wishes

David

-- 
?See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the
kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No
delusion.? https://linuxcounter.net/user/512854.html - http://gbenet.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170714/6f426898/attachment.sig>

From peter at digitalbrains.com  Fri Jul 14 20:56:46 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 14 Jul 2017 20:56:46 +0200
Subject: A Quick Supplement
In-Reply-To: <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
Message-ID: <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>

There's an option missing that could cause data loss in its absence:

$ gpg --armor --export > pub.asc

I'd make that:

$ gpg --armor --export-options export-local-sigs --export >pub.asc

If you have made any signatures that are not exportable (so lsign and
friends), they would not be exported otherwise. That is obviously what
it is for, but if you do this to make a backup of your own keyring, you
would still want to keep those.

And symmetrically, you'll want

$ gpg --import-options import-local-sigs --import pub.asc

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: </pipermail/attachments/20170714/94e85d4c/attachment-0001.sig>

From contact at ekeen.press  Fri Jul 14 13:52:56 2017
From: contact at ekeen.press (E.Keen)
Date: Fri, 14 Jul 2017 13:52:56 +0200
Subject: How to use a generated keypair on enigmail/thunderbird and iOS Mail?
Message-ID: <d86b19bf-d880-6edd-ea47-e9d0e1dd00a5@ekeen.press>

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-encrypted
Size: 11 bytes
Desc: PGP/MIME version identification
URL: </pipermail/attachments/20170714/3be026c0/attachment.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encrypted.asc
Type: application/octet-stream
Size: 1937 bytes
Desc: OpenPGP encrypted message
URL: </pipermail/attachments/20170714/3be026c0/attachment.obj>

From fsantiago at garbage-juice.com  Fri Jul 14 21:50:56 2017
From: fsantiago at garbage-juice.com (Fabian A. Santiago)
Date: Fri, 14 Jul 2017 19:50:56 +0000
Subject: How to use a generated keypair on enigmail/thunderbird and iOS
 Mail?
In-Reply-To: <d86b19bf-d880-6edd-ea47-e9d0e1dd00a5@ekeen.press>
References: <d86b19bf-d880-6edd-ea47-e9d0e1dd00a5@ekeen.press>
Message-ID: <40E2B51A-DDD7-4C0C-8D92-04B04255F11E@garbage-juice.com>

On July 14, 2017 6:52:56 AM CDT, "E.Keen" <contact at ekeen.press> wrote:
>

Don't encrypt your message to the mailing list. 
-- 
Thanks.
Fabian S.

OpenPGP:

3c3fa072accb7ac5db0f723455502b0eeb9070fc


From 2014-667rhzu3dc-lists-groups at riseup.net  Sat Jul 15 12:36:34 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sat, 15 Jul 2017 11:36:34 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
 <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
Message-ID: <156867821.20170715113634@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 12 July 2017 at 11:01:35 AM, in
<mid:36bf468a-5752-745d-3ea8-6c80c98c0cdd at binarus.de>, Binarus wrote:-


> As far as I know, no bank will be able to tell you
> your PIN if you have
> forgotten it

They can in the UK. For example, see
<http://personal.natwest.com/personal/ccet/service/debit-card0.html>
and
<https://www.barclays.co.uk/help/cards/pin/forgot-pin/#main>.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

I would like to help you out. Which way did you come in?
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWnwOV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5F7tAQDahX3YXt78/ugOpbh8QPK2ModO2pVpvLY8V9KgMCWXkAEAvrmAl8AvHhnR
TaNn0oEcLbbdtaoEfn40m2/tDQaPewiJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWnwR18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8GYzB/4uY/UeWOI/bp02rvbn7UKNGtca
XZBgBX5i/kTfO6Q7Gje0srOcLVWJJVYsUGtD6/awqiJbycBozl2MF4KndmJjDemo
UhdAACsP9oFZjNxGiufy7kNcss6I09ojlhA7E4/Y5JkbzL+KLLnXlpSnm5EEraNU
LCoPfrpKk5q4KpP7kQuxG+1Bbmp7J7MXKmroqgMddbQFjp2GRVOU2b4fYngaBBBG
V2wRFqPSv12s1Xy0a34jee2+VvuhUhG8B31WiM+cS2TKGtp1W1bNfo8prCXEVCpI
mhf/5WSEt9tQUBdbDnfZvK4P2ikKgRz/UFhbjhOdsu7xZMy5OROQ5PKRM8o5
=kC7w
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Sat Jul 15 12:40:17 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sat, 15 Jul 2017 11:40:17 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
Message-ID: <938236004.20170715114017@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 12 July 2017 at 11:10:12 AM, in
<mid:04832f44-9111-e1e0-e6f1-04c8805aa60d at digitalbrains.com>, Peter
Lebbing wrote:-


> Also, back when you could do payments with the
> magstripe (which, AFAIK,
> can still be done in some countries, using your Dutch
> bank card, if you
> allow it), the PIN necessarily went to the bank,
> there was no way for a
> check by the chip in the card.

Same applies with online shopping.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Rose rose to put rose roes on her rows of roses.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWnxEl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5D0eAPsEM2USNmcvWzC4AIg+3+fn3jhl/nmEBLuwsxP+fFWO/wEA4N/4BKbOZOvM
gyQxzHD83+S/3v/SUlsEXr2Z7D7G6wSJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWnxEl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8BwNB/0dVkuZP9A7kT+MbYLvo6Ov0LV1
jaFslkmdwCUxCiLTlvBzuIOuqZIguDXGwU3cwW45aOY25/ly51pDwfPqJ9NIlFSE
ujF+e75m9M+fz6SQpedSenE6ur1PoxeHiXDz/oxE04ESTIgUZtvohkX/OIhcBoBI
4Mh7raMU2bAMR3zvTTwbr6yVOdGHsuZ6/KAqfTxjHeBw6HpyjuzxCt7WJhK4LyjR
teLwdaXja/+U42BsjQ+uK+JLtXgpg7iYNxQ+tjkzAM2JmRp/T2ajTJBtd1N1fCzm
i35PBmeeAmKz+DrlbqRw1bRdLz407leQTot6omV4vxmqaPX35qi7y76KPYZW
=CuAo
-----END PGP SIGNATURE-----



From andy.ruddock at rainydayz.org  Sat Jul 15 11:17:18 2017
From: andy.ruddock at rainydayz.org (Andy Ruddock)
Date: Sat, 15 Jul 2017 10:17:18 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <3499376d-11fb-9854-688a-48e054166647@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
Message-ID: <f18327aa-19e8-5a87-8034-24f1a6693daf@rainydayz.org>

Just as a point of interest

> I am not sure if this is an intentional limitation of the cards (to
> prevent users from choosing idiotic pins like 1234 or their birthday).

I know of somebody who had 1234 issued as their PIN for a UK bank
account (it IS as random a selection as any other 4-digit number).

-- 
Andy Ruddock
------------
andy.ruddock at rainydayz.org (OpenPGP Key ID 0xB0324245)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170715/770470b8/attachment.sig>

From guru at unixarea.de  Sat Jul 15 13:51:36 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sat, 15 Jul 2017 13:51:36 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <f18327aa-19e8-5a87-8034-24f1a6693daf@rainydayz.org>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
Message-ID: <c996a017-de2b-42c8-af47-2043e5d70307@unixarea.de>

On Saturday, 15 July 2017 11:17:18 CEST, Andy Ruddock 
<andy.ruddock at rainydayz.org> wrote:
> Just as a point of interest
> 
>> I am not sure if this is an intentional limitation of the cards (to
>> prevent users from choosing idiotic pins like 1234 or their birthday).
> 
> I know of somebody who had 1234 issued as their PIN for a UK bank
> account (it IS as random a selection as any other 4-digit number).
> 

One of every 10.000 will get this number, you need only luck to get ro know 
someone, as you had.

matthias



-- 
Sent from my Ubuntu phone
http://www.unixarea.de/


From 2014-667rhzu3dc-lists-groups at riseup.net  Sat Jul 15 16:40:25 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sat, 15 Jul 2017 15:40:25 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
 <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
Message-ID: <76453000.20170715154025@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Thursday 13 July 2017 at 7:18:41 AM, in
<mid:3e405e1d-507d-255a-b5db-8aa700d4324a at binarus.de>, Binarus wrote:-


> I don't think so. Banking chip cards contain
> mechanisms for local PIN
> verification. You can see that an ATM (or the card)
> immediately decides
> if the PIN is correct or not even if the ATM's
> network connection is
> failing at that moment.

> Banking chip cards furthermore contain a processor
> and software for
> cryptographic operations, so that the endless
> capabilities of modern
> cryptography are at hand. Think of asymmetric methods
> like RSA ...

All of which is irrelevant for online transactions. On the shopping
website, the customer keys in the long card number, the PIN, and the
last three digits from the signature strip. The chip on the card is
not involved.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Eat well, stay fit - Die anyway
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWWopX18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5Cc7AP9j18Q8pCQkNqNJEEhOlSn6vpzwR3bMur1sUrs6VT3C4wEAvmMeibsVwvEm
a5omVlXoCSdTXDWwh7ePDqRUTTiLLAyJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWWopa18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8HxmCACbE0YE0hekeCn9LKBUsUO1f9kU
icN3Yk3lJzqXiVJyFWzow2+chtlIfX7il+ei/++abbDtkbfe/4RoouUEwaVt++T0
2SBQJAtL+Iqx16N8O6BZ0EkMdOiqhvwXJBM5kZzb/NMnPhtEu2vxd3sN2+vEz01c
GiTF9mpQBjyL/OLwNiukR7dlmtjhIWWiNKq6lOTUgCSrw2y1rIww15Z9tfB/BJBt
kKyp9y9Hv5fcOxrhJCG6s+NywVi5o9mfR9LC8H1e1pccxmZ3fM151FP0TMe01n4S
VgDkVR1+Dc3VCDq1r+4nVEBSfA9Q0yv4WYJAYX5PQKgRKb/w/v9x/2UHXrY3
=mfLl
-----END PGP SIGNATURE-----



From brad at fineby.me.uk  Sat Jul 15 16:54:07 2017
From: brad at fineby.me.uk (Brad Rogers)
Date: Sat, 15 Jul 2017 15:54:07 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <76453000.20170715154025@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
 <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
 <76453000.20170715154025@riseup.net>
Message-ID: <20170715155407.1aab2e72@abydos.stargate.org.uk>

On Sat, 15 Jul 2017 15:40:25 +0100
MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:

Hello MFPA,

>All of which is irrelevant for online transactions. On the shopping
>website, the customer keys in the long card number, the PIN, and the

Entered a card *PIN* into a shopping web site?  Really?....

Card no. CVV & expiry date.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
It's the age of destruction, in a world of corruption
Neuromancer - Billy Idol
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170715/a7704e31/attachment.sig>

From knaack.h at gmx.de  Sat Jul 15 16:02:22 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Sat, 15 Jul 2017 16:02:22 +0200
Subject: gpg-agent/pinentry: How to verify calling application
Message-ID: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>

Hi,
on my machine running Linux and a recent KDE/Plasma, pinentry-qt
occasionally starts right after logging in and asks for my passphrase.
Is there any way to track down, which process asks gpg-agent for my private
key? Preferably, I would like pinentry to inform, which process actually is
the source of the key request.
Thanks

Hartmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: </pipermail/attachments/20170715/f3ea0757/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170715/f3ea0757/attachment.sig>

From andrewg at andrewg.com  Sat Jul 15 17:35:22 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sat, 15 Jul 2017 16:35:22 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <76453000.20170715154025@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
 <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
 <76453000.20170715154025@riseup.net>
Message-ID: <A91D02FB-523E-4335-97DE-BBD24B59FA0B@andrewg.com>


> On 15 Jul 2017, at 15:40, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:
> 
> On the shopping
> website, the customer keys in the long card number, the PIN, and the
> last three digits from the signature strip. The chip on the card is
> not involved.

No, the chip on the card is not involved. So no website should *ever* ask you for your PIN. Run away!

Andrew. 


From lists at binarus.de  Sat Jul 15 19:27:10 2017
From: lists at binarus.de (Binarus)
Date: Sat, 15 Jul 2017 19:27:10 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <156867821.20170715113634@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <CANeMGR6=zvWq6ad1O-yegy-FiTSpezDRbZmaKNz9JKiSW6FLLA@mail.gmail.com>
 <36bf468a-5752-745d-3ea8-6c80c98c0cdd@binarus.de>
 <156867821.20170715113634@riseup.net>
Message-ID: <018f59ea-a747-d327-c033-2d5f7a813ad9@binarus.de>

On 15.07.2017 12:36, MFPA wrote:
> 
> 
> On Wednesday 12 July 2017 at 11:01:35 AM, in
> <mid:36bf468a-5752-745d-3ea8-6c80c98c0cdd at binarus.de>, Binarus wrote:-
> 
> 
>> As far as I know, no bank will be able to tell you
>> your PIN if you have
>> forgotten it
> 
> They can in the UK. For example, see
> <http://personal.natwest.com/personal/ccet/service/debit-card0.html>
> and
> <https://www.barclays.co.uk/help/cards/pin/forgot-pin/#main>.
> 

That is interesting. I wouldn't have expected that. Perhaps somebody who is in cryptography deeper than me could comment if it is dangerous.

And perhaps somebody who has accounts with multiple German banks could tell us if this is possible with one of his banks as well? I am having all accounts with the same bank ...

Regards,

Binarus


 


From lists at binarus.de  Sat Jul 15 19:52:53 2017
From: lists at binarus.de (Binarus)
Date: Sat, 15 Jul 2017 19:52:53 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <76453000.20170715154025@riseup.net>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
 <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
 <76453000.20170715154025@riseup.net>
Message-ID: <d4ca9ca5-8a65-38c2-593a-0f8c3288a12c@binarus.de>

On 15.07.2017 16:40, MFPA wrote:
> 
> 
> On Thursday 13 July 2017 at 7:18:41 AM, in
> <mid:3e405e1d-507d-255a-b5db-8aa700d4324a at binarus.de>, Binarus wrote:-
> 
> 
>> I don't think so. Banking chip cards contain
>> mechanisms for local PIN
>> verification. You can see that an ATM (or the card)
>> immediately decides
>> if the PIN is correct or not even if the ATM's
>> network connection is
>> failing at that moment.
> 
>> Banking chip cards furthermore contain a processor
>> and software for
>> cryptographic operations, so that the endless
>> capabilities of modern
>> cryptography are at hand. Think of asymmetric methods
>> like RSA ...
> 
> All of which is irrelevant for online transactions. On the shopping
> website, the customer keys in the long card number, the PIN, and the
> last three digits from the signature strip. The chip on the card is
> not involved.
> 
> 

If a website would try to query my EC card's PIN, I would go to the police.

Maybe the situation might be different in other countries, but I have never entered any card number into a shopping website with the following exception: If paying via credit card (VISA and the like), the website queries the credit card's number (I think this is what you mean by "long number"), and *may* query additional three digits from a number which is on the back side of the card (near the signature strip, as you described).

Customers here in Germany can activate additional security for VISA cards (I don't know about other ones): If this is enabled, you have to enter an additional TAN (*NOT* PIN) besides the credit card number and the three digits when doing the payment. The TAN will be sent to your mobile phone. Perhaps it's that what you were referring to?

I know that there are combinations of credit and EC cards. In this case, the card *will* have a chip integrated (at least the newer ones). But still then, a shopping website must not ask for the PIN (which is only related to the EC card part). After all, you can't pay anything on a shopping website directly by EC cards (or the EC card part of a combined credit and EC card). At least, I never saw such a thing here in Germany (and I am doing a lot of online shopping).

The reason for the latter is that the PIN should *never* be transferred or be known in clear by any party (besides yourself and perhaps your bank, but see my previous posts for my opinion about that). The only method to pay by EC card would be using a certified card reader (which handles the payment safety independently from your PC). But since no consumer is ready to pay a lot of money for such a card reader, that payment option just does not exist when shopping online (at least, not here).

Regards,

Binarus




From lists at binarus.de  Sat Jul 15 19:57:45 2017
From: lists at binarus.de (Binarus)
Date: Sat, 15 Jul 2017 19:57:45 +0200
Subject: Changing PINs of German bank card
In-Reply-To: <f18327aa-19e8-5a87-8034-24f1a6693daf@rainydayz.org>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com>
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <f18327aa-19e8-5a87-8034-24f1a6693daf@rainydayz.org>
Message-ID: <c23a8a0d-3915-7680-743a-556c4c3acf1a@binarus.de>



On 15.07.2017 11:17, Andy Ruddock wrote:
> Just as a point of interest
> 
>> I am not sure if this is an intentional limitation of the cards (to
>> prevent users from choosing idiotic pins like 1234 or their birthday).
> 
> I know of somebody who had 1234 issued as their PIN for a UK bank
> account (it IS as random a selection as any other 4-digit number).
 

Yes, in a mathematical sense. Taking the human factor into account, that person has been very unlucky.

If you are interested in the details, please refer to my post from 2017-07-12 08:09.

Regards,

Binarus




From dkg at fifthhorseman.net  Sun Jul 16 09:30:03 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 16 Jul 2017 09:30:03 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
Message-ID: <87inisrg90.fsf@fifthhorseman.net>

On Sat 2017-07-15 16:02:22 +0200, Hartmut Knaack wrote:
> on my machine running Linux and a recent KDE/Plasma, pinentry-qt
> occasionally starts right after logging in and asks for my passphrase.
> Is there any way to track down, which process asks gpg-agent for my private
> key? Preferably, I would like pinentry to inform, which process actually is
> the source of the key request.

pinentry itself doesn't know the source of the request, but gpg-agent
could use getsockopt(SO_PEERCRED) to get at least the requesting
process's pid, uid, and gid.

the pid is kind-of usable (with some possibility of a race) to learn
something about which process made the request, which gpg-agent could
pass on to the pinentry.

I don't think there's currently any plan to do anything like this, but
if you want it to happen, i recommend documenting the idea in a ticket
on https://dev.gnupg.org/ so that there's somewhere to keep track of it
and potentially collect proposed patches.

Regards,

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170716/7c0359ac/attachment.sig>

From skquinn at rushpost.com  Sun Jul 16 09:48:15 2017
From: skquinn at rushpost.com (Shawn K. Quinn)
Date: Sun, 16 Jul 2017 02:48:15 -0500
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
Message-ID: <a2c50123-c878-cd9a-eec0-d2c7931cce5e@rushpost.com>

On 07/15/2017 09:02 AM, Hartmut Knaack wrote:
> Hi,
> on my machine running Linux and a recent KDE/Plasma, pinentry-qt
> occasionally starts right after logging in and asks for my passphrase.
> Is there any way to track down, which process asks gpg-agent for my private
> key? Preferably, I would like pinentry to inform, which process actually is
> the source of the key request.
> Thanks

This is a bit of a "duct tape"  but you could try:

# chmod 000 `which pinentry-qt`

then reboot and see what program throws an error (besides GnuPG).

Don't forget to change it back when done testing.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170716/4854154e/attachment.sig>

From contact at ekeen.press  Fri Jul 14 20:48:59 2017
From: contact at ekeen.press (E.Keen)
Date: Fri, 14 Jul 2017 20:48:59 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird and
 iOS Mail
Message-ID: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>



Dear community,

I am very passionate about cyber security and working against mass
surveillance. I therefore try to stay informed about security
measurements and encryption.

Nevertheless, I do have a problem which I cannot solve by myself.

I generated a keypair using enigmail on thunderbird for this email address.
Now, I'd like to use the same address with the same encryption keys on
an iOS device.
However, I don't know how to transfer the private key securely without
anyone else being able to obtain it.
Someone informed me that there might be a possibility to type in the
private key manually.

I 'd appreciate any help or further information you might give me.

Thank you very much.

Kind Regards,

E.Keen



From fsantiago at garbage-juice.com  Sun Jul 16 17:58:52 2017
From: fsantiago at garbage-juice.com (Fabian A. Santiago)
Date: Sun, 16 Jul 2017 15:58:52 +0000
Subject: How to use a the same generated keypair on
 enigmail/thunderbird and iOS Mail
In-Reply-To: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
Message-ID: <d5408119d61a9d98c01d079eb9c0207f@garbage-juice.com>

July 16, 2017 11:41 AM, "E.Keen" <contact at ekeen.press> wrote:

> Dear community,
> 
> I am very passionate about cyber security and working against mass
> surveillance. I therefore try to stay informed about security
> measurements and encryption.
> 
> Nevertheless, I do have a problem which I cannot solve by myself.
> 
> I generated a keypair using enigmail on thunderbird for this email address.
> Now, I'd like to use the same address with the same encryption keys on
> an iOS device.
> However, I don't know how to transfer the private key securely without
> anyone else being able to obtain it.
> Someone informed me that there might be a possibility to type in the
> private key manually.
> 
> I 'd appreciate any help or further information you might give me.
> 
> Thank you very much.
> 
> Kind Regards,
> 
> E.Keen
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

people out there correct me if I'm wrong,

iOS natively won't make use of gpg keys, only s/mime. so you'd be relying on a 3rd party app to handle encrypted email using the former. unless you also have an s/mime key pair to use, then iOS' mail app will use it. 

said 3rd party app may allow you to transfer the key(s) to your device by way of itunes. i forget the exact place (something to do with app syncing i think) but there would be a place you can copy the files you wish to have sync'd to your mobile device. then the app would pick it up from there. 

i've used one such app before in the distant past but forget its name and don't currently have an ios device on me to look around but you can probably find something in the app store. 

--

Thanks,

Fabian S.

OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC


From jurgenpolster at gmail.com  Sun Jul 16 19:24:49 2017
From: jurgenpolster at gmail.com (=?utf-8?Q?J=C3=BCrgen_Polster?=)
Date: Sun, 16 Jul 2017 19:24:49 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <d5408119d61a9d98c01d079eb9c0207f@garbage-juice.com>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <d5408119d61a9d98c01d079eb9c0207f@garbage-juice.com>
Message-ID: <F9E5FE24-6AD4-47FF-882D-901412BF4C6D@gmail.com>

As said by Fabian, IOS natively only supports S/ MIME keys. This works rather seamlessly. You nearly do not notice it. However to exchange or DELETE outdated S/MIME certificates of others is a real pain and made me stop working with it.

The IOS apps for working with openpg encryption are iPGMail and oPenGP. Both interact with mail by cut and paste of content and you can transfer your private keys and public keys by help of the iTunes App and a cable from your windows or Mac PC. It works but due to the cut and paste workflow use is rather inconvenient.

Kind regards
Juergen Polster

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170716/b1279502/attachment.html>

From wk at gnupg.org  Sun Jul 16 21:17:35 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 16 Jul 2017 21:17:35 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <87inisrg90.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Sun, 16 Jul 2017 09:30:03 +0200")
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net>
Message-ID: <87k238gpio.fsf@wheatstone.g10code.de>

On Sun, 16 Jul 2017 09:30, dkg at fifthhorseman.net said:

> I don't think there's currently any plan to do anything like this, but

Actually this is implemented since GnuPG 2.1.19 (Debian has 2.1.18,
though) when used withwith a pinentry from Git after 2017-02-03.  There
you will see in the titlebar something like

  [PID]@HOSTNAME (gpg --clearsign)


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: </pipermail/attachments/20170716/15e7fbe6/attachment.sig>

From guru at unixarea.de  Sun Jul 16 21:25:28 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 16 Jul 2017 21:25:28 +0200
Subject: use policy of the GnuPG-card
In-Reply-To: <87bmooigmc.fsf@wheatstone.g10code.de>
References: <20170713104942.GA78965@c720-r314251>
 <87bmooigmc.fsf@wheatstone.g10code.de>
Message-ID: <20170716192527.GA3937@c720-r314251>

El d?a jueves, julio 13, 2017 a las 03:57:47p. m. +0200, Werner Koch escribi?:

> ...
> 
> For the signing key we have a signature counter and if you can memorize
> the count and the number of signatures you did, you have a way to detect
> malicious use of that key.  Better malware could of course also present
> you a different count - checking on a clean machine would detect that,
> though.

Why we only have a counter for the signing key?

	matthias
-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
8. Mai 1945: Wer nicht feiert hat den Krieg verloren.
8 de mayo de 1945: Quien no festeja perdi? la Guerra.
May 8, 1945: Who does not celebrate lost the War.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170716/f8c737e6/attachment-0001.sig>

From peter at digitalbrains.com  Sun Jul 16 21:54:38 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 16 Jul 2017 21:54:38 +0200
Subject: use policy of the GnuPG-card
In-Reply-To: <20170716192527.GA3937@c720-r314251>
References: <20170713104942.GA78965@c720-r314251>
 <87bmooigmc.fsf@wheatstone.g10code.de> <20170716192527.GA3937@c720-r314251>
Message-ID: <ecede383-4117-ceb5-3519-42c5e5b14de2@digitalbrains.com>

On 16/07/17 21:25, Matthias Apitz wrote:
> Why we only have a counter for the signing key?

I don't think a decryption counter makes sense as you'll decrypt the
same data multiple times (a signature is made only once).

An authentication counter would make more sense. However, you can't
collect all authentications you've ever done. You could collect all the
signatures you do and compare the number of results.

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: </pipermail/attachments/20170716/086a2a6f/attachment.sig>

From knaack.h at gmx.de  Mon Jul 17 00:47:23 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Mon, 17 Jul 2017 00:47:23 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <a2c50123-c878-cd9a-eec0-d2c7931cce5e@rushpost.com>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <a2c50123-c878-cd9a-eec0-d2c7931cce5e@rushpost.com>
Message-ID: <a07c26af-c799-5b1d-7abf-248fd75358bd@gmx.de>

Shawn K. Quinn schrieb am 16.07.2017 um 09:48:
> On 07/15/2017 09:02 AM, Hartmut Knaack wrote:
>> Hi,
>> on my machine running Linux and a recent KDE/Plasma, pinentry-qt
>> occasionally starts right after logging in and asks for my passphrase.
>> Is there any way to track down, which process asks gpg-agent for my private
>> key? Preferably, I would like pinentry to inform, which process actually is
>> the source of the key request.
>> Thanks
> 
> This is a bit of a "duct tape"  but you could try:
> 
> # chmod 000 `which pinentry-qt`
> 
> then reboot and see what program throws an error (besides GnuPG).
> 
> Don't forget to change it back when done testing.
> 

Thanks for the hint. Unfortunately, it happens just very occasionally,
and I haven't figured out yet, what the reason may be. I have been logging
on at least ten times, and even fully rebooted five times today, without
getting such a request.
I have now installed the git version of pinentry and will just wait for
this issue to happen next.
Thanks,

Hartmut

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: </pipermail/attachments/20170717/b7a626b2/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170717/b7a626b2/attachment.sig>

From knaack.h at gmx.de  Mon Jul 17 00:38:50 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Mon, 17 Jul 2017 00:38:50 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <87k238gpio.fsf@wheatstone.g10code.de>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net> <87k238gpio.fsf@wheatstone.g10code.de>
Message-ID: <c363e38a-a384-e881-b25e-45a04c561604@gmx.de>

Werner Koch schrieb am 16.07.2017 um 21:17:
> On Sun, 16 Jul 2017 09:30, dkg at fifthhorseman.net said:
> 
>> I don't think there's currently any plan to do anything like this, but
> 
> Actually this is implemented since GnuPG 2.1.19 (Debian has 2.1.18,
> though) when used withwith a pinentry from Git after 2017-02-03.  There
> you will see in the titlebar something like
> 
>   [PID]@HOSTNAME (gpg --clearsign)
> 

This is much better. Somehow of a problem is just, that the pinentry window
is not resizable, so the window title gets cut off. I would say, all this
information should better be put inside the window itself.
It would also be nice, if you could release a new version, so distributors
can pick up and build it.
Thanks

Hartmut

> 
> Salam-Shalom,
> 
>    Werner
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: </pipermail/attachments/20170717/025ae64f/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170717/025ae64f/attachment.sig>

From youcanlinux at gmail.com  Mon Jul 17 01:50:58 2017
From: youcanlinux at gmail.com (Daniel Villarreal)
Date: Sun, 16 Jul 2017 18:50:58 -0500
Subject: A Quick Supplement
In-Reply-To: <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
Message-ID: <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/14/17 13:56, Peter Lebbing wrote:
> There's an option missing that could cause data loss in its 
> absence:
> 
> $ gpg --armor --export > pub.asc
> 
> I'd make that:
> 
> $ gpg --armor --export-options export-local-sigs --export >pub.asc
> 
> If you have made any signatures that are not exportable (so lsign 
> and friends), they would not be exported otherwise. That is 
> obviously what it is for, but if you do this to make a backup of 
> your own keyring, you would still want to keep those.
> 
> And symmetrically, you'll want
> 
> $ gpg --import-options import-local-sigs --import pub.asc

Are you recommending...

$ gpg --armor --export-options export-local-sigs --export >pub.asc

instead of

$ gpg --armor --export > pub.asc

and

$ gpg --import-options import-local-sigs --import pub.asc

instead of

$ gpg --import < pub.asc

?

Or should
$ gpg --import-options import-local-sigs --import pub.asc
$ gpg --armor --export-options export-local-sigs --export >pub.asc
$ gpg --import-options import-local-sigs --import pub.asc
$ gpg --import < pub.asc
all be done?


And this all functions with gpg2 in place of gpg ?

Please note that  while I greatly appreciate that Mr. Hansen wrote a
program to handle this, I still like having the option of doing things
manually.

Thanks!


Originally referencing this email...

- -- begin quote --
- -------- Forwarded Message --------
Subject: RE: What is a reliable way to backup/restore my keys and test?
Date: Wed, 14 Sep 2016 15:01:47 -0400
From: Robert J. Hansen <rjh at sixdemonbag.org>
To: 'Duane Whitty' <duane at nofroth.com>, gnupg-users at gnupg.org

> I am relatively new to GNUPG so my apologies in advance if this >
question is trivial.

Welcome!  And your question is not trivial.

The following is the procedure I use on UNIX systems:

First, export all public certificates into a public keyring:

	$ gpg --armor --export > pub.asc

Second, export all secret certificates into a secret keyring:

	$ gpg --armor --export-secret-keys > priv.asc

Third, export ownertrust values and save those:

	$ gpg --armor --export-ownertrust > trust.asc

Fourth, copy all the *.conf files in ~/.gnupg into your current director
y:

	$ cp ~/.gnupg/*.conf .

Fifth,  put these, and all your GnuPG .conf files, all into a single
archive:

	$ tar cJf gpg-backup.txz pub.asc priv.asc trust.asc *.conf

Copy gpg-backup.txz to the new machine.  Once you've done that,
uncompress it on the new machine:

	$ tar xJf gpg-backup.txz

Import your secret certificates:

	$ gpg --import < priv.asc

Import your public certificates:

	$ gpg --import < pub.asc

Import your ownertrust values:

	$ gpg --import-ownertrust < trust.asc

Make sure your ~/.gnupg directory exists.  If it doesn't, run gpg with
no arguments and hit Ctrl-C to break out of it.

	$ gpg

Copy your .conf files into ~/.gnupg:

	$ cp *.conf ~/.gnupg

... And at that point you should be done.  This technique should work
regardless of whether you're migrating from 1.4 to 2.0, 1.4 to 2.1,
2.0 to 1.4, 2.0 to 2.1, 2.1 to 2.0, or 2.1 to 1.4.  No matter which
you're doing, you're covered.

> I've just copied my .gnupg directory to a usb key as a backup 
> measure, which I found as a method (more or less) on 
> http://www.glump.net/content/gpg_intro/.

It's a good idea to not copy the random_seed file.  PRNG states should
not be shared between computers.

> How can I make sure my private key and trust assignments were 
> copied properly?

Follow the above process and they will be.  Your private certificates
were exported, as were the trust assignments.

> Once I have completed my OS upgrade how do I restore my keys and 
> the trust levels assigned to them?

See the above process.

> I use Thunderbird/Enigmail which is using gpg2 but I originally 
> created my key pair using gpg 1.4.  Does this have any 
> ramifications?

None.

- --end quote--


- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZa/vbAAoJEPJRiTioPntJN1MH/RHi9MV3CWHPZp7AOHVDfWmI
l4AOaEBs+2CRbW5jj6w6eI+LV5/IsDSmBMNEoPab7iOLdgzxc6SsTL4KjqK+9Imy
kaOHyPTiMJ99GfOpCM9iZ7OuCsavUEWqw8JN/gtBBT561LA+NxZCUrrOkyZyWBCt
pKpSI7cPtPyNe2VC7jrX4M/+SEwhzC1TmaCeXNoyBq3cTPwKPmGDuebfuv76/SVa
1HE5P/iCIDHZ+jxVWgsY2VTiOpifWN+ht54cc2MRZPkPC6KjSktIcuevo+ZDWw4+
QrR0tyn0fyNXHzJEhSie6v4wdM1QnEC6R34JR83LGMRxiH3820mrRyTmJFmvkxA=
=PMER
-----END PGP SIGNATURE-----


From wk at gnupg.org  Mon Jul 17 09:42:15 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 17 Jul 2017 09:42:15 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <c363e38a-a384-e881-b25e-45a04c561604@gmx.de> (Hartmut Knaack's
 message of "Mon, 17 Jul 2017 00:38:50 +0200")
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net>
 <87k238gpio.fsf@wheatstone.g10code.de>
 <c363e38a-a384-e881-b25e-45a04c561604@gmx.de>
Message-ID: <87bmojh5m0.fsf@wheatstone.g10code.de>

On Mon, 17 Jul 2017 00:38, knaack.h at gmx.de said:

> This is much better. Somehow of a problem is just, that the pinentry window
> is not resizable, so the window title gets cut off. I would say, all this
> information should better be put inside the window itself.

Too much info for most users.  Adding a tooltip would be possible, though.

> It would also be nice, if you could release a new version, so distributors
> can pick up and build it.

Yes, that should be done.  (https://dev.gnupg.org/T3279)


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: </pipermail/attachments/20170717/b7bd92a3/attachment.sig>

From peter at digitalbrains.com  Mon Jul 17 10:24:59 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 17 Jul 2017 10:24:59 +0200
Subject: A Quick Supplement
In-Reply-To: <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
Message-ID: <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>

On 17/07/17 01:50, Daniel Villarreal wrote:
> Are you recommending...
> [...]
> instead of

Yes, instead of, not in addition to. The export-local-sigs will add the
local sigs, the other non-local sigs will still be there as well.

> And this all functions with gpg2 in place of gpg ?

Yes, just use what you want to use, GnuPG v1.4, v2.0 and v2.1 all
support it, if I remember correctly.

> Please note that  while I greatly appreciate that Mr. Hansen wrote a
> program to handle this, I still like having the option of doing things
> manually.

I'm not sure if Rob's routine actually backs up local signatures... I
couldn't see anything explicit about it with a quick glance at the code.
That's fine if you don't use local signatures at all.

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: </pipermail/attachments/20170717/ed55bbe5/attachment.sig>

From dgouttegattat at incenp.org  Fri Jul 14 17:10:06 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 14 Jul 2017 17:10:06 +0200
Subject: [Announce] Scute 1.5.0 released
Message-ID: <4205b88b-7cc0-9df4-d1f4-ac7d9d976e91@incenp.org>

Hi,

The GnuPG Project is pleased to announce the availability of Scute
1.5.0.

Scute is a PKCS#11 module built around the GnuPG Agent and the GnuPG
Smart Card Daemon. It allows you to use your OpenPGP smart card for TLS
client authentication and S/MIME mail and document signing.


Noteworthy changes in version 1.5.0 (2017-07-14)
===================================

* Support for TLS 1.2.

* Support for S/MIME signing. This has been tested with Thunderbird (to
   sign e-mails) and with LibreOffice (to sign OpenDocument and PDF
   files).

* Support for 4096 bit RSA keys.

* Better support for GnuPG 2.1:

   - A communication bug between GnuPG Agent and Scute, leading to failed
     signatures, has been fixed.

   - Scute now relies on gpg-connect-agent to be able to always find the
     socket for GnuPG Agent, no matter where that socket is actually
     located.

* C_GenerateRandom function is implemented. This allows Firefox to seed
   its entropy pool using the OpenPGP smart card's random number
   generator.


Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
as <https://gnupg.org/download/mirrors.html>.  On the primary server the
source tarball and its digital signature are:

  ftp://ftp.gnupg.org/gcrypt/scute/scute-1.5.0.tar.bz2 (968k)
  ftp://ftp.gnupg.org/gcrypt/scute/scute-1.5.0.tar.bz2.sig

The same files are also available via HTTP:

  https://gnupg.org/ftp/gcrypt/scute/scute-1.5.0.tar.bz2
  https://gnupg.org/ftp/gcrypt/scute/scute-1.5.0.tar.bz2.sig


Copying
=======

Scute is copyrighted by g10 Code GmbH ans licensed under the GNU General
Public License version 2 or later (GPLv2+) with the following exception:

   In addition, as a special exception, g10 Code GmbH gives permission
   to link this library: with the Mozilla Foundation's code for
   Mozilla (or with modified versions of it that use the same license
   as the "Mozilla" code), and distribute the linked executables.  You
   must obey the GNU General Public License in all respects for all of
   the code used other than "Mozilla".  If you modify the software, you
   may extend this exception to your version of the software, but you
   are not obligated to do so.  If you do not wish to do so, delete this
   exception statement from your version and from all source files.


Support
=======

The Scute manual is included in the source distribution and is also
available online at <http://scute.org/scute.html/index.html>. For
community support, you may ask on the gnupg-users mailing list
<https://lists.gnupg.org/mailman/listinfo/gnupg-users>.

If you need commercial support, check out
<https://gnupg.org/service.html>.

Maintenance and development of Scute and of GnuPG as a whole is mostly
financed by donations. Please consider donating via
<https://gnupg.org/donate/>.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170714/30a5b827/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From andrewg at andrewg.com  Mon Jul 17 12:19:53 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 17 Jul 2017 11:19:53 +0100
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <F9E5FE24-6AD4-47FF-882D-901412BF4C6D@gmail.com>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <d5408119d61a9d98c01d079eb9c0207f@garbage-juice.com>
 <F9E5FE24-6AD4-47FF-882D-901412BF4C6D@gmail.com>
Message-ID: <8dc7baa5-7e41-8b35-8b0a-7d7e7f2ad24c@andrewg.com>

On 2017/07/16 18:24, J?rgen Polster wrote:
> The IOS apps for working with openpg encryption are iPGMail and
> oPenGP. Both interact with mail by cut and paste of content

In the case of iPGMail, it can also use the "mail attachment" OS hook to
automatically populate a draft email. You still need to press "send" a
second time, but you don't have to mess around with clipboards.

The disadvantage is that sending encrypted messages as attachments is
not standards compliant, and enigmail for one has great trouble dealing
with them at the other end. Unfortunately there's no way for an iOS app
to implement PGP/MIME properly, given Apple's strict restrictions on
email apps.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170717/66e701b1/attachment.sig>

From felix at audiofair.de  Mon Jul 17 12:14:49 2017
From: felix at audiofair.de (Felix Winterhalter)
Date: Mon, 17 Jul 2017 12:14:49 +0200
Subject: Selecting SSH Key in gpg-agent ssh-agent mode
Message-ID: <827f8e30-8573-a353-b9bc-282f665771f0@audiofair.de>

Hey there fellow gpg-users,

I've been using gpg-agent for a while with my Yubikey and its working 
fine. Asking me the pin once on each plugin and then silently working in 
the background.

For various reasons I also have on-disk ssh-keys with passphrases that I 
added with ssh-add to the gpg-agents keystore.

However on servers where those keys are present gpg-agent will always 
ask me to unlock these keys first even if the Yubikey is already 
unlocked. On declining pinentry it will then continue to use the 
Yubikey's keys.

Is there any setting to reorder the order in which SSH-Keys are tried 
against a server? Or rather is there also a way to specifiy to first try 
unlocked keys?

Cheers,

Felix



From rjh at sixdemonbag.org  Mon Jul 17 15:54:56 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 17 Jul 2017 09:54:56 -0400
Subject: A Quick Supplement
In-Reply-To: <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
Message-ID: <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>

> I'm not sure if Rob's routine actually backs up local signatures...
> I couldn't see anything explicit about it with a quick glance at the
> code. That's fine if you don't use local signatures at all.

The step-by-step process I posted last year didn't, because I don't use
them in my own local policy and thus didn't think about them (oops).

Sherpa doesn't, because GPGME doesn't support the exporting of local
signatures.

It is infuriatingly difficult to come up with a backup method that
applies across GnuPG 1.4 - 2.1, is crossplatform, is safe (doesn't copy
random_seed, etc.), and so on.  Ease of backing up has never been a high
priority for the GnuPG devs, and it shows.


From rjh at sixdemonbag.org  Mon Jul 17 15:59:42 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 17 Jul 2017 09:59:42 -0400
Subject: A Quick Supplement
In-Reply-To: <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
Message-ID: <898b5706-7c19-ed94-fb6a-27503b0258b6@sixdemonbag.org>

> Please note that  while I greatly appreciate that Mr. Hansen wrote a
> program to handle this, I still like having the option of doing things
> manually.

At risk of sounding arch and caustic -- which I'm not; it's just that
reality is going to sound arch and caustic -- go for it: just remember
that it's a long complex that requires some command-line juggling that's
beyond the skills of the majority of users, and this is something you
really don't want to get wrong.

If you feel you have the necessary skills to safely do it at the command
line, knock yourself out.  But if you don't, please use the tool.  It
will save you a lot of frustration.


From gnupg-user at niob.at  Mon Jul 17 13:25:43 2017
From: gnupg-user at niob.at (gnupg-user at niob.at)
Date: Mon, 17 Jul 2017 13:25:43 +0200
Subject: gpgme - raw RSA operation using GPG public/private keys?
In-Reply-To: <87d196y1dj.fsf@fifthhorseman.net>
References: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>
 <87d196y1dj.fsf@fifthhorseman.net>
Message-ID: <3ce438ef-ef56-5d60-94ac-66f5e67941b0@niob.at>

Am 12.07.2017 um 01:55 schrieb Daniel Kahn Gillmor:
> On Fri 2017-07-07 18:01:03 +0200, gnupg-user at niob.at wrote:
>> I am looking for a "simple" way to use a GPG public/private RSA key to
>> do "raw" RSA operations. I have the impression, that gpgme only deals
>> with "real" OpenPGP data structures, but this does not fit my use case.
>> This is for an application that is currently based on openssl crypto.
> you're right -- gpgm is only for higher-level protocol operations,
> whether they're OpenPGP or CMS (cryptographic message syntax).  it
> doesn't offer low-level crypto primitives.
>
> if you want low-level crypto primitives that are GPL-compatible, you can
> use libhogweed (from the nettle project) or libgcrypt.
Thanks a lot for the answer. So the next question is: How? That is: I
could not find any libgcrypt functions taking a gpg key obtainable
through gpgme.

But that is the key problem (haha): I *could* (by hand) parse a secret
key exported using gpg (or, if possible, through gpgme) and use the RSA
parameters to build up the key structure required for either libgcrypt
(or openssl). But that would make it impossible to deal with e.g. gpg
agents.

So to rephrase the question: How would I proceed to do raw RSA
operations using libcrypt for gpg keys stored in a standard key ring? Or
is this functionality not exposed directly in any library? Would it be
best to look at how gpg itself does this? Any pointers (source files,
docs, examples, etc.?)

> Modern GnuPG uses libgcrypt for its crypto primitives, fwiw.
I want to be modern as well... :-)
>        --dkg

peter



From youcanlinux at gmail.com  Tue Jul 18 14:23:36 2017
From: youcanlinux at gmail.com (Daniel Villarreal)
Date: Tue, 18 Jul 2017 07:23:36 -0500
Subject: A Quick Supplement
In-Reply-To: <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
Message-ID: <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/17/17 08:54, Robert J. Hansen wrote:
>> I'm not sure if Rob's routine actually backs up local 
>> signatures... I couldn't see anything explicit about it with a 
>> quick glance at the code. That's fine if you don't use local 
>> signatures at all.
> 
> The step-by-step process I posted last year didn't, because I
> don't use them in my own local policy and thus didn't think about
> them (oops).
> 
> Sherpa doesn't, because GPGME doesn't support the exporting of 
> local signatures.
> 
> It is infuriatingly difficult to come up with a backup method that
>  applies across GnuPG 1.4 - 2.1, is crossplatform, is safe
> (doesn't copy random_seed, etc.), and so on.  Ease of backing up
> has never been a high priority for the GnuPG devs, and it shows.

Have you ever asked Werner about what he thinks about "ease" of
backing up?" He is very accessible on this list, and he often points
out nuances of the coding, versions, etc., and he's very good about
clarifying what people bring up on the list.

While it would be nice if it were easier to be able to back up easily
as you're suggesting, shouldn't the focus of GnuPG be on security?

Werner's company has working for it someone working on Enigmail, which
lets you do key management, including importing and exporting.

Werner Koch co-founded Free Software Foundation Europe.
Everyone has the opportunity to make GnuPG better, see the following
link...
http://fsfe.org/about/basics/freesoftware.en.html

My experience with customer support for German speakers is that the
customers actually study their user documentation very thoroughly
before calling in for help. Let that sink in for a moment.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZbf23AAoJEPJRiTioPntJGXMH/iiCs9EgndE8bKtLMUmvIW0O
1NkHYZ+RaDQuBs1fkVGN8jSoIKR9rBipJIuCpGm+CIQQzVyjHCaTc+oGZI/ILpSY
8t1jAmWkgoWWDHICokGSSC6HAxV3inbHEqGwq6LHNavTg2jVuo2UbZmDbjhFJUmD
DOOKOMAeeDaENiJRCWddx416rG/PqeHnzN1ZZmeYI/RJNzCIbR7XSq1NRlYkf4q4
HmT854z0tyndQ2KzDAXK9XHCnA80Elcs4L7nMGqlwKV0cPaBpits9PutsuZps4Yb
qM38aTB5KXPIOfls43cpsEfOhh2ixFUpQDNgk11q9OzWK2eJhQoENIe6KK/t4gU=
=j5pt
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Tue Jul 18 15:36:39 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 18 Jul 2017 09:36:39 -0400
Subject: A Quick Supplement
In-Reply-To: <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
Message-ID: <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"

I have made these observations before, yes.

> While it would be nice if it were easier to be able to back up easily
> as you're suggesting, shouldn't the focus of GnuPG be on security?

This *is* a security issue.

Some versions of GnuPG use a file called "random_seed", for instance.
This file contains material for seeding a random number generator, and
for that reason it must not be backed up or shared between computers: if
the file doesn't exist it'll be recreated, but if it does... then you've
just reused RNG seeds on two different computers, which has the
potential to dramatically reduce the cryptographic security of the code.

If you don't make it easy to back up keys, people won't back up their
keys.  Then, any minor disaster has the possibility of irreparably
wrecking their keys and the Web of Trust connections they've carefully
created.  Disaster recovery is an important part of security, too.

> Werner's company has working for it someone working on Enigmail, which
> lets you do key management, including importing and exporting.

Click Enigmail -> About and see if you spot any familiar names there.
Maybe Enigmail's usability guy, who's had to wrestle with the problems
of importing and exporting keyrings, will have some interesting
thoughts.  :)

> Werner Koch co-founded Free Software Foundation Europe.

So?  He could've been the first man to walk on Mars: it would have no
bearing on whether the difficulty of backing up keyrings is a problem
that needs to be addressed.

> Everyone has the opportunity to make GnuPG better, see the following
> link...

Yep.  Sections 3.8, 3.9, and 3.10 of the FAQ mention this.  You might
also want to check out section 1.2.  It's a pretty good FAQ; someone
clearly put a lot of work into it.  :)

https://www.gnupg.org/faq/gnupg-faq.html

I do not contribute code to GnuPG -- I could: I'm a fairly good C
cryptographic engineer with a strong security background.  However, once
upon a time I worked on U.S. government contracts, so it's best for the
GnuPG project if I don't contribute code.  I still find other ways to
contribute, whether that means non-core code contributions (Sherpa),
documentation (the FAQ), usability issues (Enigmail), etc.


From ndk.clanbo at gmail.com  Tue Jul 18 18:42:11 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 18 Jul 2017 18:42:11 +0200
Subject: A Quick Supplement
In-Reply-To: <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
Message-ID: <26e4b8cb-48f1-6d68-abfe-a4ecc02398a3@gmail.com>

Il 18/07/2017 14:23, Daniel Villarreal ha scritto:

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"
Security = confidentiality + integrity + availability

If you're not considering availability, you only can have partial security.

BYtE,
 Diego


From aheinlein at gmx.com  Tue Jul 18 22:20:02 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Tue, 18 Jul 2017 22:20:02 +0200
Subject: A Quick Supplement
In-Reply-To: <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
 <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
Message-ID: <3499b279-4748-af6a-0b0a-4b053c4ac89c@gmx.com>

Am 18.07.2017 um 15:36 schrieb Robert J. Hansen:
>
>> While it would be nice if it were easier to be able to back up easily
>> as you're suggesting, shouldn't the focus of GnuPG be on security?
> This *is* a security issue.
>
> Some versions of GnuPG use a file called "random_seed", for instance.
> This file contains material for seeding a random number generator, and
> for that reason it must not be backed up or shared between computers: if
> the file doesn't exist it'll be recreated, but if it does... then you've
> just reused RNG seeds on two different computers, which has the
> potential to dramatically reduce the cryptographic security of the code.
>
> If you don't make it easy to back up keys, people won't back up their
> keys.  Then, any minor disaster has the possibility of irreparably
> wrecking their keys and the Web of Trust connections they've carefully
> created.  Disaster recovery is an important part of security, too.
Sorry if I'm asking dumb questions, but given that a) I am using the
same GnuPG version on all machines and b) I am excluding random_seed,
what would be wrong with sync'ing the whole gnupg directory (or the
whole user profile / home directory) with rsync/duplicity/whatever ?

Also, can you point me to a more in-depth explanation on the security
implications of re-using random_seed? I can imagine what you mean, but
I'd like to know more.

Thanks,
Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170718/beac4904/attachment.sig>

From rjh at sixdemonbag.org  Tue Jul 18 22:49:38 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 18 Jul 2017 16:49:38 -0400
Subject: A Quick Supplement
In-Reply-To: <3499b279-4748-af6a-0b0a-4b053c4ac89c@gmx.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
 <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
 <3499b279-4748-af6a-0b0a-4b053c4ac89c@gmx.com>
Message-ID: <e06c145e-a56e-204c-4d18-8e1a5dd5babe@sixdemonbag.org>

> Sorry if I'm asking dumb questions

Not a dumb question.

> what would be wrong with sync'ing the whole gnupg directory (or the
> whole user profile / home directory) with rsync/duplicity/whatever ?

There are a number of lockfiles, sockets, etc., that live in the
~/.gnupg directory which shouldn't be copied.

> Also, can you point me to a more in-depth explanation on the security
> implications of re-using random_seed? I can imagine what you mean, but
> I'd like to know more.

No, because GnuPG has a ton of different pseudorandom number generators
that it can use.  An in-depth explanation would require knowing specific
versions of your operating system, possibly even which chipsets you're
using (hardware accelerators, etc.) -- and at that point I'm going to
start charging you my consulting rates.  :)

In a nutshell, though: a pseudorandom number generator has some internal
data that it uses to generate the sequences.  If you restore the PRNG to
an earlier state, it'll generate the same numbers over again... at which
point, they're really not random any more.

random_seed is internal data belonging to the PRNG.

Don't share it.  :)



From wk at gnupg.org  Tue Jul 18 22:43:19 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Jul 2017 22:43:19 +0200
Subject: [Announce] Libgcrypt 1.8.0 released
Message-ID: <87bmoheas8.fsf@wheatstone.g10code.de>

Hello!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.8.0.  This is a new stable version of Libgcrypt with full API
and ABI compatibility to the 1.7 series.  Its main features are support
Blake-2, XTS mode, an improved RNG, and performance improvements for the
ARM architecture.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes between version 1.7.0 and 1.8.0:
===================================================

 * New interfaces:

   - New cipher mode XTS
   - New hash function Blake-2
   - New function gcry_mpi_point_copy.
   - New function gcry_get_config.
   - GCRYCTL_REINIT_SYSCALL_CLAMP allows to init nPth after Libgcrypt.
   - New gobal configuration file /etc/gcrypt/random.conf.

 * Extended interfaces:

   - GCRYCTL_PRINT_CONFIG does now also print build information for
     libgpg-error and the used compiler version.
   - GCRY_CIPHER_MODE_CFB8 is now supported.
   - Add Stribog OIDs.  [also in 1.7.4]

 * Performance:

   - A jitter based entropy collector is now used in addition to the
     other entropy collectors.
   - Optimized gcry_md_hash_buffers for SHA-256 and SHA-512.
   - More ARMv8/AArch32 improvements for AES, GCM, SHA-256, and SHA-1.
     [also in 1.7.4]
   - Add ARMv8/AArch32 assembly implementation for Twofish and
     Camellia.  [also in 1.7.4]
   - Add bulk processing implementation for ARMv8/AArch32.
     [also in 1.7.4]
   - Improve the DRBG performance and sync the code with the Linux
     version.  [also in 1.7.4]

 * Internal changes:

   - Libgpg-error 1.25 is now required.  This avoids stalling of nPth
     threads due to contention on internal Libgcrypt locks (e.g. the
     random pool lock).
   - The system call clamp of libgpg-error is now used to wrap the
     blocking read of /dev/random.  This allows other nPth threads to
     run while Libgcrypt is gathering entropy.
   - When secure memory is requested by the MPI functions or by
     gcry_xmalloc_secure, they do not anymore lead to a fatal error if
     the secure memory pool is used up.  Instead new pools are
     allocated as needed.  These new pools are not protected against
     being swapped out (mlock can't be used).  However, these days
     this is considered a minor issue and can easily be mitigated by
     using encrypted swap space.  [also in 1.7.4]

 * Bug fixes:

   - Fix AES CTR self-check detected failure in the SSSE3 based
     implementation.  [also in 1.7.6]
   - Remove gratuitous select before the getrandom syscall.
     [also in 1.7.6]
   - Fix regression in mlock detection.  [bug#2870] [also in 1.7.5]
   - Fix GOST 28147 CryptoPro-B S-box.   [also in 1.7.4]
   - Fix error code handling of mlock calls.  [also in 1.7.4]
   - Fix possible timing attack on EdDSA session key. [also in 1.7.7]
   - Fix long standing bug in secure memory implementation which could
     lead to a segv on free. [bug#3027] [also in 1.7.7]
   - Mitigate a flush+reload side-channel attack on RSA secret keys
     dubbed "Sliding right into disaster".  For details see
     <https://eprint.iacr.org/2017/627>.  [CVE-2017-7526] [also in 1.7.8]

For a list of interface changes relative to the 1.7.0 release see [4].


Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
at <https://gnupg.org/download/mirrors.html>.  On the primary server
the source tarball and its digital signature are:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
<https://gnupg.org/download/integrity_check.html>.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.8.0.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.8.0.tar.bz2.sig libgcrypt-1.8.0.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.8.0.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.8.0.tar.bz2

   and check that the output matches the first line from the
   this list:

b4ffb20369f2ab8249d5cc0fb8b3b31371f6b112  libgcrypt-1.8.0.tar.bz2
1c5f57008e9d0944a3d0ecec894205dd1a272752  libgcrypt-1.8.0.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.


Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
=======

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel
mailing list for discussion.

Maintenance and development of Libgcrypt is mostly financed by
donations; see <https://gnupg.org/donate/>.  We currently employ
4 full-time developers, one part-timer, and one contractor to work on
GnuPG and closely related software like Libgcrypt.


Thanks
======

We like to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Also many thanks to all our donors [3].  Special thanks to
Stephan M?ller for his entropy generator based on timing jitter.


Happy hacking,

  The GnuPG Team



[1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
[2] https://www.gnupg.org/service.html
[3] https://gnupg.org/donate/kudos.html
[4] Interface changes relative to the 1.7.0 release:
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    gcry_get_config                 NEW function.
    gcry_mpi_point_copy             NEW function.
    GCRYCTL_REINIT_SYSCALL_CLAMP    NEW macro.
    GCRY_MD_BLAKE2B_512             NEW constant.
    GCRY_MD_BLAKE2B_384             NEW constant.
    GCRY_MD_BLAKE2B_256             NEW constant.
    GCRY_MD_BLAKE2B_160             NEW constant.
    GCRY_MD_BLAKE2S_256             NEW constant.
    GCRY_MD_BLAKE2S_224             NEW constant.
    GCRY_MD_BLAKE2S_160             NEW constant.
    GCRY_MD_BLAKE2S_128             NEW constant.
    GCRY_CIPHER_MODE_XTS            NEW constant.
    gcry_md_info                    DEPRECATED.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

p.s.
This is an announcement only mailing list.  Please send replies only to
the gcrypt-devel 'at' gnupg.org mailing list.

p.p.s
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these five keys:

  2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

  rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

You may retrieve these keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20170718/e4556536/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From knaack.h at gmx.de  Wed Jul 19 00:10:34 2017
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Wed, 19 Jul 2017 00:10:34 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <87k238gpio.fsf@wheatstone.g10code.de>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net> <87k238gpio.fsf@wheatstone.g10code.de>
Message-ID: <30ba1f92-3f36-5a44-20d5-54adc2dcea4d@gmx.de>

Werner Koch schrieb am 16.07.2017 um 21:17:
> On Sun, 16 Jul 2017 09:30, dkg at fifthhorseman.net said:
> 
>> I don't think there's currently any plan to do anything like this, but
> 
> Actually this is implemented since GnuPG 2.1.19 (Debian has 2.1.18,
> though) when used withwith a pinentry from Git after 2017-02-03.  There
> you will see in the titlebar something like
> 
>   [PID]@HOSTNAME (gpg --clearsign)
> 

I hope not to get too far off topic, but I encountered that suspicious
request of pinentry right after loggin into KDE, again. So, with the PID it
provided, I checked with ps aux:

me        2486  0.0  0.0  34028  3940 ?        SL   21:46   0:00 gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 11 --no-tty --charset utf8 --enable-progress-filter --exit-on-status-write-error --display :0 --ttyname kein Terminal --ttytype xterm --decrypt --output - -- -&14

And pstree outputs:

systemd---systemd---gpg2

When hitting cancel on that pinentry window, I get another window, stating
that kwallet wants to get access to my private key.
Any idea why this is happening or how I should proceed analysing? The only
legit process I would see should be my e-mail client.
Thanks,

Hartmut

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3086 bytes
Desc: not available
URL: </pipermail/attachments/20170719/1e8b30ea/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170719/1e8b30ea/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jul 19 00:36:53 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 18 Jul 2017 23:36:53 +0100
Subject: Changing PINs of German bank card
In-Reply-To: <20170715155407.1aab2e72@abydos.stargate.org.uk>
References: <CANeMGR7BuZ=P40-WWMWwFbxvDSw9fPnBKCQ4mPwRuzGBfPAQYQ@mail.gmail.com> 
 <3499376d-11fb-9854-688a-48e054166647@binarus.de>
 <1769963444.20170711193808@riseup.net>
 <109b00fe-7524-69e7-a3cd-94156eef75b0@binarus.de>
 <04832f44-9111-e1e0-e6f1-04c8805aa60d@digitalbrains.com>
 <3a6ef797-5e26-7b2c-d740-ee85d9750534@binarus.de>
 <1641312905.20170713002340@riseup.net>
 <3e405e1d-507d-255a-b5db-8aa700d4324a@binarus.de>
 <76453000.20170715154025@riseup.net>
 <20170715155407.1aab2e72@abydos.stargate.org.uk>
Message-ID: <232717431.20170718233653@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Saturday 15 July 2017 at 3:54:07 PM, in
<mid:20170715155407.1aab2e72 at abydos.stargate.org.uk>, Brad Rogers
wrote:-

> Card no. CVV & expiry date.


Sorry, tired when I wrote that. On the shopping website, the customer
keys in the long card number, the **expiry date** and the last three
digits from the signature strip. The chip on the card is not involved.



- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

If you are afraid to speak against tyranny, then you are already a slave.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWW6NjV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5Od/AP9s4+XdlWRPv0NnmZkf7GGAX0qtOJwHy7SQkpdt+IuFnQEAnSj3pv+3TtSq
nUbqtEu1uIcUvUDVAHJxlPKAiU1dPQWJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWW6NoV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8PRBB/9y/RVTQzuCCyh1jdhcRRXiOaNq
Ua0q5rJ/QRO1Vn2IQmBoXr0KkeJteugIEQ/RvCu9oelwc6LowmjCJ4dug1uSNkkI
huVCKBk1g5uLt4UFH9wCG7LucIZ8UNsEGuL7iwBlfvz1aP3xEw17jMgQgKdZeo/j
En3uhMdBuWuyBLh9qVW0i+ZJ5GPlGYWxiRz0Qcvge1TArZZYcHfLMb9TywHVn+h4
o3v9HZ9+46ccZwAsoTRFQuThqYAc0RX3t611bg1jez51w2c2qq/pcRjEr9q0tvQZ
eQ8I84DXzsjlYbItriqlPs+ZdKikudbFQ9tYHs5PmzM0yL/PSZUhgJWkG/Dx
=igDE
-----END PGP SIGNATURE-----



From gpg at mdsresource.net  Tue Jul 18 23:30:13 2017
From: gpg at mdsresource.net (helices)
Date: Tue, 18 Jul 2017 16:30:13 -0500
Subject: How to NOT gnutar files during encryption?
Message-ID: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>

We have a simple process that has worked for thousands of files over the
years:
1) Client ZIPs up a bunch of files
2) Client GPG/PGP encrypts that ZIP file
3) Client uploads that encrypted file to us
4) Our production server automatically decrypts the file
5) Our production server automatically unzips that file
6) Our production server automatically distributes those files

Today, we have a new wrinkle.  A new client is using Kleopatra to encrypt
the zip file.

Once we decrypt the file via GPG on Linux, we cannot unzip the file.

After many hours troubleshooting, I discovered that the decrypted "zip"
file is actually inside a TAR file!

Further investigation reveals that Kleopatra is gnuTARring the ZIP file
prior to encryption.

We must have many clients using GPG4WIN, and we have never had this problem
before.

How can this new client NOT gnutar files, and still properly encrypt the
ZIP file?

What are we missing?

~ Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170718/1c3ad9b3/attachment.html>

From youcanlinux at gmail.com  Wed Jul 19 02:49:47 2017
From: youcanlinux at gmail.com (Daniel Villarreal)
Date: Tue, 18 Jul 2017 19:49:47 -0500
Subject: A Quick Supplement
In-Reply-To: <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
 <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
Message-ID: <0c63e30a-7ea2-7ce9-559e-6d582de7ac15@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/18/17 08:36, Robert J. Hansen wrote:
>> ... shouldn't the focus of GnuPG be on security?
> 
> This *is* a security issue.

Since you put it that way, I agree.


> Some ... GnuPG use a ... "random_seed"... must not be backed up or
>  shared ...

And thanks for pointing that out.


> ... Click Enigmail -> About and see if you spot any familiar names
>  there. Maybe Enigmail's usability guy, who's had to wrestle with 
> the problems of importing and exporting keyrings, will have some 
> interesting thoughts.  :)

Enigmail is developed by the Enigmail Team:
...
    Usability: Robert J. Hansen

Ah, you got me ;-) So you are a developer?


> Yep [...] [Re: GnuPG FAQ] It's a pretty good FAQ ...

"GNUPG FREQUENTLY ASKED QUESTIONS
Robert J. Hansen et al."

You got me, again !

BTW, Mozilla Firefox on multiple OS's mangled gnupg-faq.txt (was
showing some garbled characters) until I did this modification ...

View -> Text Encoding -> Western
changed to Unicode
and everything shows properly.

> I do not contribute code to GnuPG -- once upon a time I worked on 
> U.S. government contracts, so it's best for the GnuPG project if I
>  don't contribute code.  I still find other ways to contribute, 
> whether that means non-core code contributions (Sherpa), 
> documentation (the FAQ), usability issues (Enigmail), etc.

Thank you for all you do for the computing community and for taking
the time to answer my emails in a very amicable manner.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJZbqyjAAoJEPJRiTioPntJXGQH/21aD65Z+EiS1g/L1x8K9Cni
38p96LX7dedjizMBC9JMHl5+imE+jhYQ+bEqbC2A85Qo4FdtRQ49nl9JJyUAKq/Y
tVA68SlOTqiX4SxYI+tJ/FvPVK10LT3j5bFsH0Lfi6IyTjAM3Xne2cxEbvQmnLw/
KykKYGiiXhrFp7ne854/J4ka1VdRPezJBAfssmgtrh7s26WSF9GQ9kj/B4q5dHGZ
xiiZkncgm1B0RQo5ya1/wMvHIRzBXcj9BFtA/rcFONjd1QVHMn9R9zpfBrlToPEj
qzN66OdNBMeVRKiYmkm2BU2NzGt1vGUpevZnHkrFnemmZcFG9hWL5Byhbnogyd0=
=jBO6
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Wed Jul 19 02:58:33 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 18 Jul 2017 20:58:33 -0400
Subject: A Quick Supplement
In-Reply-To: <0c63e30a-7ea2-7ce9-559e-6d582de7ac15@gmail.com>
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
 <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
 <0c63e30a-7ea2-7ce9-559e-6d582de7ac15@gmail.com>
Message-ID: <cae61881-75f9-d442-3d8a-1c1e776ce992@sixdemonbag.org>

> Ah, you got me ;-) So you are a developer?

In my day job I'm a developer, among other things.  However, due to my
taking research funding from the U.S. government in the past, I do not
contribute code to either GnuPG or Enigmail.  I find other, non-code,
ways to help the GnuPG and Enigmail teams.

> Thank you for all you do for the computing community and for taking
> the time to answer my emails in a very amicable manner.

You're quite welcome.  :)



From peter at digitalbrains.com  Wed Jul 19 11:50:29 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 19 Jul 2017 11:50:29 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <30ba1f92-3f36-5a44-20d5-54adc2dcea4d@gmx.de>
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net> <87k238gpio.fsf@wheatstone.g10code.de>
 <30ba1f92-3f36-5a44-20d5-54adc2dcea4d@gmx.de>
Message-ID: <e473c77a-1f57-f7fc-2532-a8fae12c32fd@digitalbrains.com>

On 19/07/17 00:10, Hartmut Knaack wrote:
>[...], I checked with ps aux:
> 
> me        2486  0.0  0.0  34028  3940 ?        SL   21:46   0:00 gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 11 --no-tty --charset utf8 --enable-progress-filter --exit-on-status-write-error --display :0 --ttyname kein Terminal --ttytype xterm --decrypt --output - -- -&14
> 
> And pstree outputs:
> 
> systemd---systemd---gpg2

Hah, that's not helpful, thanks, systemd! All we've learned is that
whatever is invoking gpg2 is using systemd for that, I suppose. Well,
*that* narrows it down! Perhaps you can find something with journalctl,
which allows you to read systemd logs, I dunno. I'm still pretty new to
the systemd world. I do intend to learn.

I never use pstree, I use ps's "f" (forest) option. Does that show the
same thing? If you just add the "f" to your options, it would be ps
faux, sounds French fake but will work :-). Is there anything
informative in the full command line of those systemd processes?

> When hitting cancel on that pinentry window, I get another window, stating
> that kwallet wants to get access to my private key.

That is a lot more informative. I believe kwallet is the credential
manager for KDE, keeping passwords and stuff.

I've got two guesses:

1) At some point you permitted kwallet to encrypt all your credentials
using your OpenPGP key. It is simply trying to decrypt your "wallet" so
it can be accessed.

2) It wants to add your private key to its credentials and manage it for
you from now on.

1) is pretty benign and actually cool, 2) might not be to your liking at
all. Personally, my neck hair rises remembering the way gnome-keyring
"interacted" with GnuPG back in the day. This is water under the bridge
now, gnome-keyring is a fine citizen again these days, and I thank them
for that.

However, I don't know kwallet other than its basic function. I hope my
contribution helps you along, small as it is.

HTH,

Peter.

PS: I just had a similar thing the other day where an ssh-agent was
launched against my will, but it had no parents at all in the process
tree! Cost me a long time of fruitless bug hunting until I thought of
replacing /usr/bin/ssh-agent with a shell script that logged "ps fx"
output at the moment it was invoked, when it still had a parent. Then
everything went quickly from there on.

-- 
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: </pipermail/attachments/20170719/b39fe37b/attachment-0001.sig>

From einarr at pvv.org  Wed Jul 19 10:35:45 2017
From: einarr at pvv.org (Einar Ryeng)
Date: Wed, 19 Jul 2017 10:35:45 +0200
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
Message-ID: <20170719083545.GK23963@pvv.ntnu.no>

Hi,

On Tue, Jul 18, 2017 at 04:30:13PM -0500, helices wrote:
> 
> After many hours troubleshooting, I discovered that the decrypted "zip"
> file is actually inside a TAR file!
> 
> Further investigation reveals that Kleopatra is gnuTARring the ZIP file
> prior to encryption.
> 
> How can this new client NOT gnutar files, and still properly encrypt the
> ZIP file?
> 
> What are we missing?

Sounds like either a bug or a somewhat stupid default setting in Kleopatra
(which I have never used). A workaround on the receiving end could be to detect
that the file is a tar file and unpack it before further processing.

Something like this:

#!/bin/bash
FILENAME=$1
FILE_MIMETYPE=$(file -iN $FILENAME)

if [[ "$FILE_MIMETYPE" =~ "$FILENAME: application/x-tar; charset=binary" ]]
then
    tar xvf $FILENAME
fi

As usual, du NOT run code from random people on the Internet.

-- 
Einar Ryeng



From wk at gnupg.org  Wed Jul 19 12:36:24 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Jul 2017 12:36:24 +0200
Subject: A Quick Supplement
In-Reply-To: <e06c145e-a56e-204c-4d18-8e1a5dd5babe@sixdemonbag.org> (Robert
 J. Hansen's message of "Tue, 18 Jul 2017 16:49:38 -0400")
References: <c4f5a94d-f825-ad00-447f-f654d1582edc@gbenet.com>
 <86fb1969-f463-21b8-1744-9bdbd24f714e@gmail.com>
 <9abf3a1b-28e5-c270-00c5-42cbc49900e6@gbenet.com>
 <63fc12f1-f77a-0935-09ef-fe94b6086c5a@digitalbrains.com>
 <832516c3-8f03-5047-1c07-545773e64fb1@gmail.com>
 <e6851909-b5ae-4993-dc1c-ffbf1c644e97@digitalbrains.com>
 <45049eac-2f33-30c8-d5c2-9f63c9711d7a@sixdemonbag.org>
 <83bdb050-ad66-7e91-e40b-7aba4fe26fee@gmail.com>
 <9a4f0d8b-4398-f959-7044-4244e03a8b6e@sixdemonbag.org>
 <3499b279-4748-af6a-0b0a-4b053c4ac89c@gmx.com>
 <e06c145e-a56e-204c-4d18-8e1a5dd5babe@sixdemonbag.org>
Message-ID: <87vamod87r.fsf@wheatstone.g10code.de>

On Tue, 18 Jul 2017 22:49, rjh at sixdemonbag.org said:

> random_seed is internal data belonging to the PRNG.

That is right.  However we always add at least 128 bit of fresh random
which would be enough - at least on all systems with /dev/random or on
Windows.  It is just that we are ultra-conservative and use a huge state
of 4800 bits.  The random_seed file gives an initial value to that
state.  From a pure mathematical point of view the 128 bits we always
add are enough.  For key generation we have even stronger requirements.


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: </pipermail/attachments/20170719/ee773ec0/attachment.sig>

From wk at gnupg.org  Wed Jul 19 12:43:41 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Jul 2017 12:43:41 +0200
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
 (helices's message of "Tue, 18 Jul 2017 16:30:13 -0500")
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
Message-ID: <87r2xcd7vm.fsf@wheatstone.g10code.de>

On Tue, 18 Jul 2017 23:30, gpg at mdsresource.net said:

> Further investigation reveals that Kleopatra is gnuTARring the ZIP file
> prior to encryption.

That should only happen when you select multipe files or a directory.
This invokes the pgp-zip method of encrypting multiple files.  Despite
the name it is not ZIP but USTAR format (which any tar implementation
can handle).


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: </pipermail/attachments/20170719/885f0ee7/attachment.sig>

From wk at gnupg.org  Wed Jul 19 12:59:30 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Jul 2017 12:59:30 +0200
Subject: gpg-agent/pinentry: How to verify calling application
In-Reply-To: <30ba1f92-3f36-5a44-20d5-54adc2dcea4d@gmx.de> (Hartmut Knaack's
 message of "Wed, 19 Jul 2017 00:10:34 +0200")
References: <980c339a-5fde-7022-f51e-d6c00fedf6c9@gmx.de>
 <87inisrg90.fsf@fifthhorseman.net>
 <87k238gpio.fsf@wheatstone.g10code.de>
 <30ba1f92-3f36-5a44-20d5-54adc2dcea4d@gmx.de>
Message-ID: <87mv80d759.fsf@wheatstone.g10code.de>

On Wed, 19 Jul 2017 00:10, knaack.h at gmx.de said:

> me        2486  0.0  0.0  34028  3940 ?        SL   21:46   0:00 gpg2 --enable-special-filenames --batch --no-sk-comments --status-fd 11 --no-tty --charset utf8 --enable-progress-filter --exit-on-status-write-error --display :0 --ttyname kein Terminal --ttytype xterm --decrypt --output - -- -&14

FWIW: That looks like an gpg invovation via GPGME.


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: </pipermail/attachments/20170719/3519d5d8/attachment.sig>

From SIVA.MADDALA at serco.com  Wed Jul 19 11:44:50 2017
From: SIVA.MADDALA at serco.com (SIVA MADDALA)
Date: Wed, 19 Jul 2017 10:44:50 +0100
Subject: GPG Installation on AIX 6.1 & RedHat Linux 6.8 & RedHat 5.11
Message-ID: <A25871DBB568B2458FE2E1B76195E4330D1C8E30B3@COREEXCHCCR06.ad.serco.com>

Hi Team,

We need to install the GPG software in our AIX & LINUX machines, however first we need to install GPG on AIX servers and need your support in order to install the software. Kindly share us the link & document to download the relevant software and to install the software and procedure to configure it? Along with rollback process in case of issues. Awaiting reply.

Regards,
Siva Naresh M
------------------------------------------
Technical Support Engineer
Serco IT Shared Services-OMC-UNIX
Email : siva.maddala at serco.com<mailto:siva.maddala at serco.com>
Phone : +44(0)845-408-3689


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170719/f9f77377/attachment.html>

From aheinecke at intevation.de  Wed Jul 19 13:38:03 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Wed, 19 Jul 2017 13:38:03 +0200
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
Message-ID: <4017042.4QS3ESkqnm@esus>

Hi,

On Tuesday, July 18, 2017 4:30:13 PM CEST helices wrote:
> How can this new client NOT gnutar files, and still properly encrypt the
> ZIP file?

The client could create a ZIP Archive with the files and then encrypt that as a 
single file. Kleopatra has no built in support for ZIP + Encrypt.

FWIW Kleopatra would have automatically chosen a filename like archive.tar.gpg 
so your client must have manually changed that to have some kind of zip 
extension.

On the other hand you could extend your process to also accept tarballs ;-)

Regards,
Andre


-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170719/6b2b7a16/attachment.sig>

From damien at cassou.me  Wed Jul 19 15:29:11 2017
From: damien at cassou.me (Damien Cassou)
Date: Wed, 19 Jul 2017 15:29:11 +0200
Subject: Don't get the pinentry for passphrase in some contexts
In-Reply-To: <877ezcig8f.fsf@wheatstone.g10code.de>
References: <87bmoph82h.fsf@cassou.me> <8760ew1o3c.fsf@cassou.me>
 <877ezcig8f.fsf@wheatstone.g10code.de>
Message-ID: <87o9sg5zdk.fsf@cassou.me>

Werner Koch <wk at gnupg.org> writes:
> "debug-pinentry" in gpg-agent.conf would give you more info.  Adding
> also "debug ipc" will show you the communication between gpg and
> gpg-agent; that is what you strace shows.  Use "log-file FILE" to set a
> log file and remember to reload gpg-agent.


I tried this configuration

    enable-ssh-support
    log-file /home/cassou/.gnupg/gpg-agent.log
    debug-level guru
    max-cache-ttl 0
    debug-pinentry 1
    debug 1024

The generated log files in both cases are quite similar but show the
differences below. I put _XXX_ to hide some values that are the same in
both outputs and _YYY_/_ZZZ_ when values differ.

--- firefox.log	2017-07-19 15:20:17.988440200 +0200
+++ terminal.log	2017-07-19 15:20:24.128297587 +0200
@@ -2,9 +2,9 @@
 DBG: chan_6 -> OK Pleased to meet you, process _PID_
 DBG: chan_6 <- RESET
 DBG: chan_6 -> OK
-DBG: chan_6 <- OPTION ttyname=/dev/pts/2
+DBG: chan_6 <- OPTION ttyname=/dev/pts/0
 DBG: chan_6 -> OK
-DBG: chan_6 <- OPTION ttytype=dumb
+DBG: chan_6 <- OPTION ttytype=xterm-256color
 DBG: chan_6 -> OK
 DBG: chan_6 <- OPTION display=:0
 DBG: chan_6 -> OK
@@ -16,8 +16,6 @@
 DBG: chan_6 -> OK
 DBG: chan_6 <- OPTION putenv=QT_IM_MODULE=ibus
 DBG: chan_6 -> OK
-DBG: chan_6 <- OPTION putenv=INSIDE_EMACS=25.2.1,comint
-DBG: chan_6 -> OK
 DBG: chan_6 <- OPTION lc-ctype=en_US.UTF-8
 DBG: chan_6 -> OK
 DBG: chan_6 <- OPTION lc-messages=en_US.UTF-8
@@ -46,12 +44,11 @@
 DBG: chan_6 <- PKDECRYPT
 DBG: chan_6 -> S INQUIRE_MAXLEN 4096
 DBG: chan_6 -> INQUIRE CIPHERTEXT
-DBG: chan_6 <- [ 44 ... ...(_YYY_ byte(s) skipped) ]
+DBG: chan_6 <- [ 44 ... ...(_ZZZ_ byte(s) skipped) ]
 DBG: chan_6 <- END
 DBG: keygrip: _XXX_
-DBG: cipher:  _XXX_ _YYY_ _XXX_
+DBG: cipher:  _XXX_ _ZZZ_ _XXX_
 DBG: agent_get_cache '_XXX_' (mode 2) ...
-DBG:   expired '_XXX_' (0s after creation)
 DBG: ... miss
 DBG: agent_get_cache '_XXX_' (mode 2) (stored cache key) ...
 DBG: ... miss
@@ -59,10 +56,5 @@
 DBG: connection to PIN entry established
 DBG: chan_6 -> INQUIRE PINENTRY_LAUNCHED _PID_
 DBG: chan_6 <- END
-DBG: error calling pinentry: Operation cancelled <Pinentry>
-failed to unprotect the secret key: Operation cancelled
-failed to read the secret key
-command 'PKDECRYPT' failed: Operation cancelled <Pinentry>
-DBG: chan_6 -> ERR 83886179 Operation cancelled <Pinentry>
-DBG: chan_6 <- [eof]
-handler 0x7f8e1fa24700 for fd 6 terminated
+DBG: agent_put_cache 'XXXXXX' (mode 2) requested ttl=0
+DBG: rsa_decrypt data:+XXXXX


>>     read(5, "ERR 83886179 Operation cancelled <Pinentry>\n", 1002) = 44
>
> The agent tells you that the Pinentry canceled the operation.  This is
> usually due to clicking the cancel button.  Some older versions of
> pinentry use cancel as a catch all error from pinentry.  Modern versions
> of gpg running with "-v" will print a line identifing the pinentry used
> and thus reveal possible problems, for example a missing GPG_TTY
> envrionment variable.


I have 2.1.13 and only got that in Firefox console:

--------------------------stdout:

--------------------------stderr:
gpg: public key is XXX
gpg: using subkey XXX instead of primary key YYY
gpg: encrypted with 4096-bit RSA key, ID XXX, created 2015-04-17
      "Damien Cassou <damien at cassou.me>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key



Do you have any more clue?

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill


From gpg at mdsresource.net  Wed Jul 19 15:17:26 2017
From: gpg at mdsresource.net (helices)
Date: Wed, 19 Jul 2017 08:17:26 -0500
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <87r2xcd7vm.fsf@wheatstone.g10code.de>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
 <87r2xcd7vm.fsf@wheatstone.g10code.de>
Message-ID: <CACNUArDe5z4EJKL2ah=qE76D0abdMkQ0bGTK7qijxqU64BZNRA@mail.gmail.com>

How to NOT gnutar files during encryption?


Thank you for your responses; but, you are all missing my point - and not
answering my question.

First, before encryption by Kleopatra, the file IS one (1) real ZIP file
(e.g., filename.zip)

After encryption and upload to us, the file is now an encrypted TAR file,
with the ZIP file inside (e.g., filename.zip.gpg)

Notice that there is NO indication of TAR anywhere in the filename.

Yes, I can rewrite our production processes to look for files of type TAR,
and automate that. We receive ~1000 encrypted files per day, and we have
never needed this before.

However, if they can turn OFF that TAR subprocess - which you state ought
only to happen when requested to encrypt multiple files - then, this
client's files will automatically process just like the thousands of other
clients' files we process without incident every single day.

So, to repeat myself:

    How to NOT gnutar files during encryption?

Please, advise. Thank you.

~ Mike


On Wed, Jul 19, 2017 at 5:43 AM, Werner Koch <wk at gnupg.org> wrote:

> On Tue, 18 Jul 2017 23:30, gpg at mdsresource.net said:
>
> > Further investigation reveals that Kleopatra is gnuTARring the ZIP file
> > prior to encryption.
>
> That should only happen when you select multipe files or a directory.
> This invokes the pgp-zip method of encrypting multiple files.  Despite
> the name it is not ZIP but USTAR format (which any tar implementation
> can handle).
>
>
> Shalom-Salam,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170719/efd02d1e/attachment.html>

From gpg at mdsresource.net  Wed Jul 19 16:30:55 2017
From: gpg at mdsresource.net (helices)
Date: Wed, 19 Jul 2017 09:30:55 -0500
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <CACNUArDe5z4EJKL2ah=qE76D0abdMkQ0bGTK7qijxqU64BZNRA@mail.gmail.com>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
 <87r2xcd7vm.fsf@wheatstone.g10code.de>
 <CACNUArDe5z4EJKL2ah=qE76D0abdMkQ0bGTK7qijxqU64BZNRA@mail.gmail.com>
Message-ID: <CACNUArD7Wa_WVq_91SYfne5B6v_yFoj_cYqB_M=9XdqoZO_mcQ@mail.gmail.com>

OK, for the record, I think that I've found the solution.

I looked in Kleopatra Settings and found nothing.

Then, I imported a proper key and began signing and encrypting a file:
Archive.zip

In Kleopatra's Sign/Encrypt Files dialog, there is a checkbox: Archive
files with: TAR (PGP-compatible), which is checked by default.

Unchecking that box and encrypting, this file decrypted and unzipped
without incident: Archive.zip.gpg

I'm waiting for our client to upload a file encrypted this way.


HOWEVER, they right click the ZIP file and select "sign and encrypt" to
process files. Will the UNchecked checkbox for "Archive files with: TAR
(PGP-compatible)" be default now?

~ Mike


On Wed, Jul 19, 2017 at 8:17 AM, helices <gpg at mdsresource.net> wrote:

> How to NOT gnutar files during encryption?
>
>
> Thank you for your responses; but, you are all missing my point - and not
> answering my question.
>
> First, before encryption by Kleopatra, the file IS one (1) real ZIP file
> (e.g., filename.zip)
>
> After encryption and upload to us, the file is now an encrypted TAR file,
> with the ZIP file inside (e.g., filename.zip.gpg)
>
> Notice that there is NO indication of TAR anywhere in the filename.
>
> Yes, I can rewrite our production processes to look for files of type TAR,
> and automate that. We receive ~1000 encrypted files per day, and we have
> never needed this before.
>
> However, if they can turn OFF that TAR subprocess - which you state ought
> only to happen when requested to encrypt multiple files - then, this
> client's files will automatically process just like the thousands of other
> clients' files we process without incident every single day.
>
> So, to repeat myself:
>
>     How to NOT gnutar files during encryption?
>
> Please, advise. Thank you.
>
> ~ Mike
>
>
> On Wed, Jul 19, 2017 at 5:43 AM, Werner Koch <wk at gnupg.org> wrote:
>
>> On Tue, 18 Jul 2017 23:30, gpg at mdsresource.net said:
>>
>> > Further investigation reveals that Kleopatra is gnuTARring the ZIP file
>> > prior to encryption.
>>
>> That should only happen when you select multipe files or a directory.
>> This invokes the pgp-zip method of encrypting multiple files.  Despite
>> the name it is not ZIP but USTAR format (which any tar implementation
>> can handle).
>>
>>
>> Shalom-Salam,
>>
>>    Werner
>>
>> --
>> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170719/a6da43c9/attachment.html>

From peter at digitalbrains.com  Wed Jul 19 16:49:17 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 19 Jul 2017 16:49:17 +0200
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <CACNUArD7Wa_WVq_91SYfne5B6v_yFoj_cYqB_M=9XdqoZO_mcQ@mail.gmail.com>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
 <87r2xcd7vm.fsf@wheatstone.g10code.de>
 <CACNUArDe5z4EJKL2ah=qE76D0abdMkQ0bGTK7qijxqU64BZNRA@mail.gmail.com>
 <CACNUArD7Wa_WVq_91SYfne5B6v_yFoj_cYqB_M=9XdqoZO_mcQ@mail.gmail.com>
Message-ID: <f3eb59ba-ee37-0f77-cbb5-d0ef92235669@digitalbrains.com>

On 19/07/17 16:30, helices wrote:
> Unchecking that box and encrypting, this file decrypted and unzipped
> without incident: Archive.zip.gpg

And if you keep the box checked, does it produce a file named
Archive.zip.gpg or Archive.zip.tar.gpg? Because IMO, it should be the
latter. A good alternative would be: supposing the file is at
.../foldername/Archive.zip, call the tarred and encrypted file
foldername.tar.gpg. But naming it Archive.zip.gpg looks just confusing
and wrong to me. The chain of extensions is just incorrect; if we're
dropping "inner" extensions, it should be Archive.gpg, which just loses
all information.

If your client saw the filename "Archive.zip.tar.gpg" or
"foldername.tar.gpg", they might notice and think "Hey, where did this
come from?" instead of just sending it to you and leading to confusion
all round. Similarly, you might have noticed.

Cheers,

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: </pipermail/attachments/20170719/2643adc6/attachment.sig>

From rjh at sixdemonbag.org  Wed Jul 19 17:08:20 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 19 Jul 2017 11:08:20 -0400
Subject: GPG Installation on AIX 6.1 & RedHat Linux 6.8 & RedHat 5.11
In-Reply-To: <A25871DBB568B2458FE2E1B76195E4330D1C8E30B3@COREEXCHCCR06.ad.serco.com>
References: <A25871DBB568B2458FE2E1B76195E4330D1C8E30B3@COREEXCHCCR06.ad.serco.com>
Message-ID: <c6c704fe-4a0e-e8c7-82ce-906b09d54724@sixdemonbag.org>

> We need to install the GPG software in our AIX & LINUX machines

The Linux machines should be easy, if you'll tell us what distro you're
using.

I'll give someone else the chance to answer your AIX question, as I
haven't used it in many years.


From gpg at mdsresource.net  Wed Jul 19 17:54:16 2017
From: gpg at mdsresource.net (helices)
Date: Wed, 19 Jul 2017 10:54:16 -0500
Subject: How to NOT gnutar files during encryption?
In-Reply-To: <f3eb59ba-ee37-0f77-cbb5-d0ef92235669@digitalbrains.com>
References: <CACNUArAo7B-FeGcfGohZdCsvdCcpVVoVZBHOr9pV-Pb4LEqKgQ@mail.gmail.com>
 <87r2xcd7vm.fsf@wheatstone.g10code.de>
 <CACNUArDe5z4EJKL2ah=qE76D0abdMkQ0bGTK7qijxqU64BZNRA@mail.gmail.com>
 <CACNUArD7Wa_WVq_91SYfne5B6v_yFoj_cYqB_M=9XdqoZO_mcQ@mail.gmail.com>
 <f3eb59ba-ee37-0f77-cbb5-d0ef92235669@digitalbrains.com>
Message-ID: <CACNUArAKBwx=G=RpNKAO3c9iH9S50r+YHgqrWRzU7CRF4g8BSQ@mail.gmail.com>

On Wed, Jul 19, 2017 at 9:49 AM, Peter Lebbing <peter at digitalbrains.com>
wrote:

> On 19/07/17 16:30, helices wrote:
> > Unchecking that box and encrypting, this file decrypted and unzipped
> > without incident: Archive.zip.gpg
>
> And if you keep the box checked, does it produce a file named
> Archive.zip.gpg or Archive.zip.tar.gpg?
>

Archive.zip.gpg - which is why it took me so long to identify why I could
not unzip it ;-)

Grrrrr ... gmail makes it tedious to reply to list mail ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170719/8183949f/attachment-0001.html>

From dirkx at webweaving.org  Thu Jul 20 20:04:48 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Thu, 20 Jul 2017 20:04:48 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry 
Message-ID: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>

With gpg2; it seems that as soon as you cat a batch.command sequence in - one can no longer use a pure terminal style TTY approach to having the agent fetch your password (gpg: signing failed: Inappropriate ioctl for device, gpg: make_keysig_packet failed: Inappropriate ioctl for device) as soon as the TTY is used for the patch file.

Instead on 2.1.15 one has to use allow-loopback-pinentry in the gpg-agent.conf to make constructs such as:

	cat batch.commands | gpg2 --no-tty ?batch ?passphrase-XX XX --command-fd 0 --pinentry-mode loopback  ?

possible to make this work.  And that works fine.

Now obviously that leaves the tasks of getting the password to something to put it in file, filedescriptor or cmd-arg. Which is not ideal. As gpg-agent and pineentry are made for that.

So - is there any way to allow a (for the occasionally specially started gpg-agent) to ask and pre-cache the password ?

And then let the batch.commands (which does a complex dance of subkey renewal and some chip card shuffling) run against that ?

Or to somehow use a pure TTY based pinentry in such a setting (it is an off line machine with barely more than a serial connection).

Insights much appreciated !

Dw.







From wk at gnupg.org  Fri Jul 21 08:46:50 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Jul 2017 08:46:50 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 (Dirk-Willem van Gulik's message of "Thu, 20 Jul 2017 20:04:48 +0200")
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
Message-ID: <87lgni9tid.fsf@wheatstone.g10code.de>

On Thu, 20 Jul 2017 20:04, dirkx at webweaving.org said:

> 	cat batch.commands | gpg2 --no-tty ?batch ?passphrase-XX XX --command-fd 0 --pinentry-mode loopback  ?

This is not going to work.  --command-fd must always be used in
conjunction with --status-fd so that a GET_foo status line output
triggers input to the command fd descriptor.

> And then let the batch.commands (which does a complex dance of subkey renewal and some chip card shuffling) run against that ?

Please check wether some of the new --quick-foo commands can be helpful.

> Or to somehow use a pure TTY based pinentry in such a setting (it is an off line machine with barely more than a serial connection).

GnuPG has examples on how to write simple pinentries
(/tests/fake-pinentries/).  Based on such an example and with the envvar
PINENTRY_USER_DATA you can provide passphrases or PINs to gpg-agent.


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: </pipermail/attachments/20170721/ad75ca5a/attachment.sig>

From dirkx at webweaving.org  Fri Jul 21 10:05:22 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Fri, 21 Jul 2017 10:05:22 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <87lgni9tid.fsf@wheatstone.g10code.de>
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
Message-ID: <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>


> On 21 Jul 2017, at 08:46, Werner Koch <wk at gnupg.org> wrote:
> 
> On Thu, 20 Jul 2017 20:04, dirkx at webweaving.org said:
> 
>> 	cat batch.commands | gpg2 --no-tty ?batch ?passphrase-XX XX --command-fd 0 --pinentry-mode loopback  ?
> 
> This is not going to work.  --command-fd must always be used in
> conjunction with --status-fd so that a GET_foo status line output
> triggers input to the command fd descriptor.

Ok - I?ll need to investigate as to why this does work for our setting (auto renewal of expiry date of keys on chipcard (included below).

>> And then let the batch.commands (which does a complex dance of subkey renewal and some chip card shuffling) run against that ?
> 
> Please check wether some of the new --quick-foo commands can be helpful.

Thanks - that is a nice treasure trove you unearthed for me. Thanks !

>> Or to somehow use a pure TTY based pinentry in such a setting (it is an off line machine with barely more than a serial connection).
> 
> GnuPG has examples on how to write simple pinentries
> (/tests/fake-pinentries/).  Based on such an example and with the envvar
> PINENTRY_USER_DATA you can provide passphrases or PINs to gpg-agent.

So this we have working.

What I was hoping that there is a way to ?trigger? a ?real? pinentry request by gpg-agent (and allowing it to cache the result for N seconds) prior to going to gpg2 into command mode.  I.e. to warm up the cache.

As to rely as much as possible on the existing security of gpg-agent and its cache (cleanup) management.

Thanks,

Dw.

#!/bin/sh
set -e

PWFILE=${PWFILE:-passwd.txt}
DAYS=${DAYS:-120}


if [ $# != 1 ]; then
        echo Syntax: $0 \<keyid\> > /dev/stderr
        exit 1
fi

if !  test -f $PWFILE; then
        echo No pwd $PWFILE > /dev/stderr
        exit 1
fi

KEYID=$1

cat <<EOM | gpg2 --no-tty --batch --passphrase-file "$PWFILE" --command-fd 0 --pinentry-mode loopback --edit-key "$KEYID"
key 1
expire
$DAYS
key 1
key 2
expire
$DAYS
key 2
key 3
expire
$DAYS
save
EOM

srm passwd.txt


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: </pipermail/attachments/20170721/29dc8ec6/attachment.sig>

From dirkx at webweaving.org  Fri Jul 21 10:32:48 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Fri, 21 Jul 2017 10:32:48 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
Message-ID: <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>


> On 21 Jul 2017, at 10:05, Dirk-Willem van Gulik <dirkx at webweaving.org> wrote:
> 
>>> And then let the batch.commands (which does a complex dance of subkey renewal and some chip card shuffling) run against that ?
>> 
>> Please check wether some of the new --quick-foo commands can be helpful.
> 
> Thanks - that is a nice treasure trove you unearthed for me. Thanks !

Those ?quick commands are a huge help. The one thing missing seems to be one for the routine extension of the expiry of subkeys.

Or is there a clever syntax for the ?fpr of the primary key to refer to a subkey by number or otherwise (referring to it by fingerprint gives me a ?<fpr> is not the primary fingerprint? ?

Kind regards,

Dw



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: </pipermail/attachments/20170721/61868ecf/attachment.sig>

From wk at gnupg.org  Fri Jul 21 10:39:23 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Jul 2017 10:39:23 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
 (Dirk-Willem van Gulik's message of "Fri, 21 Jul 2017 10:05:22 +0200")
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
Message-ID: <87fudq9oas.fsf@wheatstone.g10code.de>

On Fri, 21 Jul 2017 10:05, dirkx at webweaving.org said:

> Thanks - that is a nice treasure trove you unearthed for me. Thanks !

Some examples are give at 

  https://gnupg.org/faq/whats-new-in-2.1.html#quickgen


> Ok - I?ll need to investigate as to why this does work for our setting (auto renewal of expiry date of keys on chipcard (included below).

It works because we dod not introduce no new prompts and kept the order
of existing prompts.  As soon as we add new prompts, or change the
behaviour of e.g. --expert, your script will break.

> What I was hoping that there is a way to ?trigger? a ?real? pinentry request by gpg-agent (and allowing it to cache the result for N seconds) prior to going to gpg2 into command mode.  I.e. to warm up the cache.

That should be possible with gpg-preset-passphrase command.  See its man
page.


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: </pipermail/attachments/20170721/88651f25/attachment.sig>

From wk at gnupg.org  Fri Jul 21 11:20:42 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Jul 2017 11:20:42 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>
 (Dirk-Willem van Gulik's message of "Fri, 21 Jul 2017 10:32:48 +0200")
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
 <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>
Message-ID: <878tji9mdx.fsf@wheatstone.g10code.de>

On Fri, 21 Jul 2017 10:32, dirkx at webweaving.org said:

> Those ?quick commands are a huge help. The one thing missing seems to be one for the routine extension of the expiry of subkeys.

In general I think that it is easier to just add a new subkey.  However<
I can see that it makes sense for subkeys on a card to change their
expiration date.

> Or is there a clever syntax for the ?fpr of the primary key to refer to a subkey by number or otherwise (referring to it by fingerprint gives me a ?<fpr> is not the primary fingerprint? ?

Not yet.  Stay tuned.


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: </pipermail/attachments/20170721/bd95bc09/attachment.sig>

From dirkx at webweaving.org  Fri Jul 21 11:37:06 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Fri, 21 Jul 2017 11:37:06 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <878tji9mdx.fsf@wheatstone.g10code.de>
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
 <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>
 <878tji9mdx.fsf@wheatstone.g10code.de>
Message-ID: <E659FFCB-6628-4B76-AC4A-A6BE42272621@webweaving.org>


> On 21 Jul 2017, at 11:20, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 21 Jul 2017 10:32, dirkx at webweaving.org said:
> 
>> Those ?quick commands are a huge help. The one thing missing seems to be one for the routine extension of the expiry of subkeys.
> 
> In general I think that it is easier to just add a new subkey.  However<
> I can see that it makes sense for subkeys on a card to change their
> expiration date.

Thanks. That is exactly what I am doing ? updating the scripts to move from disk-based to openpgp card applets.

>> Or is there a clever syntax for the ?fpr of the primary key to refer to a subkey by number or otherwise (referring to it by fingerprint gives me a ?<fpr> is not the primary fingerprint? ?
> 
> Not yet.  Stay tuned.

Keep up the good work! That december/2.1.17 addition made things a lot simpler already.

And I really would not mind to be able to refer to subkeys by number -and- fpr; as the fpr of a subkey is a but cumbersome to extract afaik (double ?fingerprint).

Dw.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: </pipermail/attachments/20170721/84a61dfe/attachment.sig>

From wk at gnupg.org  Fri Jul 21 18:34:59 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Jul 2017 18:34:59 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <E659FFCB-6628-4B76-AC4A-A6BE42272621@webweaving.org>
 (Dirk-Willem van Gulik's message of "Fri, 21 Jul 2017 11:37:06 +0200")
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
 <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>
 <878tji9mdx.fsf@wheatstone.g10code.de>
 <E659FFCB-6628-4B76-AC4A-A6BE42272621@webweaving.org>
Message-ID: <87zibx92a4.fsf@wheatstone.g10code.de>

On Fri, 21 Jul 2017 11:37, dirkx at webweaving.org said:

> And I really would not mind to be able to refer to subkeys by number -and- fpr; as the fpr of a subkey is a but cumbersome to extract afaik (double ?fingerprint).

Using the number with the quick commands is not a good idea because
another process might have changed the keys in the meantime.  For
--edit-key this is not a problem because you work on a copy and last
save wins.  So I went with subkey fingerprints:

  --quick-set-expire fpr expire [*|subfprs]

    With two arguments given, directly set the expiration time of the
    primary key identified by fpr to expire.  To remove the expiration
    time 0 can be used.  With three arguments and the third given as an
    asterisk, the expiration time of all non-revoked and not yet expired
    subkeys are set to expire.  With more than two arguments and a list
    of fingerprints given for subfprs, all non-revoked subkeys matching
    these fingerprints are set to expire.

This is in master and will be part of the next release.  Examples:

  $ gpg --status-fd 2 -v --quick-set-expire \
       502D1A5365D1C0CAA69945390BA52DF0BAA59D9C 2019-12-31

This is the standard thing to only chnage the primary keys expiration.

  $ gpg --status-fd 2 -v --quick-set-expire \
       502D1A5365D1C0CAA69945390BA52DF0BAA59D9C 2018-06-15 \*

This sets all the subkeys to 2018-06-15.  However subkeys which are
revoked or already expired are skipped.

  $ gpg --status-fd 2 -v --quick-set-expire \
       502D1A5365D1C0CAA69945390BA52DF0BAA59D9C 2017-12-30 \
       54E9BD99E3D78AFD6D7639A214B40CE8A84937FD \
       A70BE7404FF5D10FFFDA63DF701798F40CA0BC98

This sets the 54E9BD99E3D78AFD6D7639A214B40CE8A84937FD and
A70BE7404FF5D10FFFDA63DF701798F40CA0BC98 to 2017-12-30.  Noet that this
form also works for expired subkyes (but not for revoked subkeys).

Since some 2.1 version the fingerprints of the subkeys are always
included when you do

  gpg --list-keys --with-colons

(or --list-secret-keys).

To see them in the standard output format (which shall not be used by a
script) I have "with-subkey-fingerprint" in my gpg.conf.  In contrast to
using --with-fingerprint twice, --with-subkey-fingerprint has the
advantage that the fingerprints are printed without spaces and are thus
easier to c+p.


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: </pipermail/attachments/20170721/cb326af1/attachment-0001.sig>

From karel-v_g at tutanota.com  Sat Jul 22 00:01:45 2017
From: karel-v_g at tutanota.com (karel-v_g at tutanota.com)
Date: Sat, 22 Jul 2017 00:01:45 +0200 (CEST)
Subject: Test symmetrically encrypted files for errors - make sure they can
 be decrypted
Message-ID: <Kpb9veD--3-0@tutanota.com>

Hello!I am using GnuPG 1.4.x to symmetrically encrypt files before I transfer them to "the cloud" for backup reasons.Is there any way to test these encrypted files for errors, i.e. to make sure they can be decrypted correctly without actually having to decrypt them again?Providing the passphrase again etc. is no problem, I only want to avoid to write the whole file to my disk a third time (unencrypted original, encrypted backup, decrypted test).If I can test the file somehow will I get back an errorlevel on success or error?In short I am searching for something like the test option for packed files that most archivers offer.Thanks Karel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170722/aba520fe/attachment.html>

From peter at digitalbrains.com  Mon Jul 24 12:10:36 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 24 Jul 2017 12:10:36 +0200
Subject: Test symmetrically encrypted files for errors - make sure they
 can be decrypted
In-Reply-To: <Kpb9veD--3-0@tutanota.com>
References: <Kpb9veD--3-0@tutanota.com>
Message-ID: <25dbbddc-8df3-f419-4930-d20b8fc68cf5@digitalbrains.com>

Hi!

On 22/07/17 00:01, karel-v_g at tutanota.com wrote:
> In short I am searching for something like the test option for packed
> files that most archivers offer.

I don't know what OS you're using, so the details might differ but this
works for me:

$ gpg --batch -o /dev/null -d test.txt.gpg ; echo $?
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: encrypted message has been manipulated!
2

I deliberately corrupted the file. I say it should decrypt and output to
/dev/null, which on OS'es which have a /dev/null means "discard the
output". With an uncorrupted file, the exit status is 0, but here it is
2. Any non-interactive use should carry the --batch parameter so GnuPG
knows it's not currently talking to a human, and it should specify the
command (-d).

Alternatively, you could parse the status fd. The best way to
programmatically interact with GnuPG is through GPGME, but my gut
feeling says that for this really limited case, --status-fd is good
enough and cleaner than just relying on exit status. Perhaps exit status
is already good enough as long as data is not signed (which would
influence exit status), I'm not sure.

$ gpg --status-fd 3 --batch -o /dev/null -d test.txt.gpg 3>&1
1>/dev/null 2>&1
[GNUPG:] NEED_PASSPHRASE_SYM 7 3 2
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 2 7
[GNUPG:] PLAINTEXT 62 1500889574 test.txt
[GNUPG:] PLAINTEXT_LENGTH 4
[GNUPG:] BADMDC
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

I'm just keeping what is printed on FD 3 here, be gone with all the
other cruft. What you actually want is a line that says DECRYPTION_OKAY.
If you parse the status-fd output for that line, I'd say you can be
pretty sure that the file is okay. Don't rely on the opposite
(DECRYPTION_FAILED); you want positive confirmation the file is OKAY, so
that's what you should check.

The only way to verify correctness of every byte of data is to decrypt
it; only then can the Modification Detection Code be computed and
verified. But there is no need to write the decrypted data to disk, as I
demonstrated.

HTH,

Peter.

Disclaimer: I don't usually script GnuPG, I might be forgetting about
something important like --batch (which I did remember).

-- 
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: </pipermail/attachments/20170724/147fbb97/attachment.sig>

From neal at walfield.org  Mon Jul 24 13:15:41 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 24 Jul 2017 13:15:41 +0200
Subject: Test symmetrically encrypted files for errors - make sure they
 can be decrypted
In-Reply-To: <Kpb9veD--3-0@tutanota.com>
References: <Kpb9veD--3-0@tutanota.com>
Message-ID: <87y3ret7aa.wl-neal@walfield.org>

At Sat, 22 Jul 2017 00:01:45 +0200 (CEST),
<karel-v_g at tutanota.com> wrote:
> I am using GnuPG 1.4.x to symmetrically encrypt files before I
> transfer them to "the cloud" for backup reasons.
> Is there any way to test these encrypted files for errors, i.e. to
> make sure they can be decrypted correctly without actually having to
> decrypt them again?
> Providing the passphrase again etc. is no problem, I only want to
> avoid to write the whole file to my disk a third time (unencrypted
> original, encrypted backup, decrypted test).
> If I can test the file somehow will I get back an errorlevel on
> success or error?
> In short I am searching for something like the test option for packed
> files that most archivers offer.

Probably the easiest solution is to sign and encrypt, and then verify
the signature.  If the encrypted data is somehow corrupted, then the
signature will be wrong.  This, of course, embeds the signature in the
OpenPGP message, which might not be desired.


From stefan.claas at posteo.de  Mon Jul 24 16:27:14 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 24 Jul 2017 16:27:14 +0200
Subject: Operation not supported by device
Message-ID: <3xGNxJ4k0wz105R@submission01.posteo.de>

Hi all,

when clear signing a text file, with the latest version of GnuPG under
macOS, i get the following message:

gpg --clearsign loremipsum.txt
gpg: selecting openpgp failed: Operation not supported by device

The file is signed and can be verified. Just wondering (after googling)
what this means, because i have no card reader etc. for GnuPG.

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 506 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170724/aab3f95b/attachment.sig>

From wk at gnupg.org  Tue Jul 25 08:04:40 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Jul 2017 08:04:40 +0200
Subject: Operation not supported by device
In-Reply-To: <3xGNxJ4k0wz105R@submission01.posteo.de> (Stefan Claas's message
 of "Mon, 24 Jul 2017 16:27:14 +0200")
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
Message-ID: <87a83t6ohz.fsf@wheatstone.g10code.de>

On Mon, 24 Jul 2017 16:27, stefan.claas at posteo.de said:

> macOS, i get the following message:

Please do

  gpg --version

  gpg -v --clearsign loremipsum.txt

and show us the full output.


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: </pipermail/attachments/20170725/422a08fa/attachment.sig>

From Jerry.Flowers at alorica.com  Mon Jul 24 20:20:30 2017
From: Jerry.Flowers at alorica.com (Jerry Flowers)
Date: Mon, 24 Jul 2017 18:20:30 +0000
Subject: gpg2 decryption issues
Message-ID: <BLUPR0701MB10287E8AD85F57E2FD8A3DE4E0BB0@BLUPR0701MB1028.namprd07.prod.outlook.com>

Presently on below version.
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3

I've sent vendor public key and received files back encrypted with our key.
I can decrypt file when using the pinentry and manually enter passphrase.
I've tried several variation of command in batch mode but all give error
gpg: public key decryption failed: Bad passphrase
gpg: decryption failed: No secret key


gpg2 -v --batch --yes --no-tty --passphrase-file <(echo testpp) -o tempain24 -d PAIN.024.pgp

cat /export/home/applmgr/testpp | gpg2 --batch --passphrase-fd 0 --armor --decrypt /export/home/applmgr/PAIN.024.pgp

echo <passphrase> | gpg2 --batch --passphrase-fd 0 --armor --decrypt /export/home/applmgr/PAIN.024.pgp

Thanks
jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170724/c1f6c9e1/attachment-0001.html>

From wk at gnupg.org  Tue Jul 25 14:23:36 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Jul 2017 14:23:36 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170623080244.p75yzi4pw4x7gioz@albatross.lehel.madduck.net>
 (martin f. krafft's message of "Fri, 23 Jun 2017 10:02:44 +0200")
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <871sqdplzl.fsf@europa.jade-hamburg.de>
 <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
 <943123696.20170622233324@riseup.net>
 <87tw379mp7.fsf@wheatstone.g10code.de>
 <20170623080244.p75yzi4pw4x7gioz@albatross.lehel.madduck.net>
Message-ID: <87wp6w66yf.fsf@wheatstone.g10code.de>

On Fri, 23 Jun 2017 10:02, madduck at madduck.net said:

> Are you saying that gnupg 2.1.18 added the self-signature in the
> wrong place?

There is no right or wrong place.  gpg uses the latest valid
self-signature according to the timestamp in the self-signature.  Use
--with-colons to see the full timestamps (cf. doc/DETAILS).

Probably unrelated: --list-keys does not check the key signatures; you
need to use --check-sigs.


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: </pipermail/attachments/20170725/63aad347/attachment.sig>

From stefan.claas at posteo.de  Tue Jul 25 16:31:52 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 25 Jul 2017 16:31:52 +0200
Subject: Operation not supported by device
In-Reply-To: <87a83t6ohz.fsf@wheatstone.g10code.de>
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
 <87a83t6ohz.fsf@wheatstone.g10code.de>
Message-ID: <3xH10D3F8yz10H4@submission01.posteo.de>

On Tue, 25 Jul 2017 08:04:40 +0200, Werner Koch wrote:
> On Mon, 24 Jul 2017 16:27, stefan.claas at posteo.de said:
> 
> > macOS, i get the following message:  
> 
> Please do
> 
>   gpg --version
> 
>   gpg -v --clearsign loremipsum.txt
> 
> and show us the full output.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 

O.k. here we go:

$ gpg --version
gpg (GnuPG) 2.1.21
libgcrypt 1.7.8
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /Users/XXXXXXXXXXXXXXX/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

$ gpg -v --clearsign loremipsum.txt
gpg: no running gpg-agent - starting '/usr/local/gnupg-2.1/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
gpg: selecting openpgp failed: Operation not supported by device
gpg: using "2BAF85F9281ABD543823C7C5981EB7C382EC52B4" as default secret key for signing
gpg: writing to 'loremipsum.txt.asc'
gpg: pinentry launched (787 unknown 0.9.4 ? ? ?)
gpg: RSA/SHA256 signature from: "981EB7C382EC52B4 Stefan Claas <stefan.claas at posteo.de>"

GnuPG downloaded from here:

https://sourceforge.net/p/gpgosx/docu/Download/

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 506 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170725/4813941c/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jul 25 20:15:51 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 25 Jul 2017 19:15:51 +0100
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
Message-ID: <262069443.20170725191551@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Friday 14 July 2017 at 7:48:59 PM, in
<mid:29f09c5b-c3c6-0955-f803-a41533699b71 at ekeen.press>, E.Keen wrote:-


> However, I don't know how to transfer the private key
> securely without
> anyone else being able to obtain it.

I would think you could transfer the private key file to the moblle
device by bluetooth, or by using a USB cable, or by email. So long as
the private key is protected by a decent passphrase, anybody else
getting a copy of the file should be of no consequence.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Amateurs built the ark. Professionals built the Titanic.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXeK2V8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5BPrAQCGoFfJn5IQnG5aaj0EFLPTNDF8jF4ADdVhbl5A7hIijAEA48UASqwS2rDC
MlYkdmU0O0nRASVVsTdkHFmTVDObqQiJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXeK2V8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8PbJCACypL9BLEGvqxMEqv1FxxnM0JWU
xbZ4iDrn9Rt88siRvgq3QwNwdeAEYdFHMEHa4uaXdg0RrhVVKZMbUx3y938kNwfZ
ZbFwUsYHKYF60cnhxZ/m5qQzMRsUMIzRvc2CDeWd2OtXIs2lbNh01SZk6bu0zoXO
oSTdJ0LN1Thy2fCjyBrP/nrC73F7z68JG757jjmu4EFsf3d4xeoJjNpiWk1ei6QQ
nir2wp7TeCUeJKxPKCk6CyPNpqznZ+pB2da71uZzh/q2gE0jSsBmEfDaE2AnegeA
39osnm4fYjefT4aXqiefKhfIp9Y0Vhm6eFyvhfgp8IAUei0npeyWw7FibtLE
=dfyc
-----END PGP SIGNATURE-----



From rjh at sixdemonbag.org  Tue Jul 25 20:34:10 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 25 Jul 2017 14:34:10 -0400
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <262069443.20170725191551@riseup.net>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <262069443.20170725191551@riseup.net>
Message-ID: <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>

> I would think you could transfer the private key file to the moblle
> device by bluetooth, or by using a USB cable, or by email. So long as
> the private key is protected by a decent passphrase, anybody else
> getting a copy of the file should be of no consequence.

This is correct.

I've often volunteered to publish my private key in the _New York
Times_, if someone will just pay for the listing.  With a strong
passphrase, private keys are pretty darn safe against casual snooping.



From aheinlein at gmx.com  Tue Jul 25 22:49:15 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Tue, 25 Jul 2017 22:49:15 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
Message-ID: <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>

Am 25.07.2017 um 20:34 schrieb Robert J. Hansen:
>> I would think you could transfer the private key file to the moblle
>> device by bluetooth, or by using a USB cable, or by email. So long as
>> the private key is protected by a decent passphrase, anybody else
>> getting a copy of the file should be of no consequence.
> This is correct.
>
> I've often volunteered to publish my private key in the _New York
> Times_, if someone will just pay for the listing.  With a strong
> passphrase, private keys are pretty darn safe against casual snooping.

I still would not recommend that to non-technical people. While the
users on this list probably know what a 'decent' passphrase is, most
normal users don't. They tend to choose passwords which are too short,
contain dictionary words - or they are written down right under the
keyboard... Having a second line of defense, i.e. keeping the private
key secure, is usually a good idea. That's the whole point of the
OpenPGP smartcard, after all.

Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170725/48724d5a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170725/48724d5a/attachment.sig>

From lukele at gpgtools.org  Tue Jul 25 21:42:47 2017
From: lukele at gpgtools.org (Lukas Pitschl | GPGTools)
Date: Tue, 25 Jul 2017 21:42:47 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
Message-ID: <8B5CE44A-A0F9-4A08-BAAE-F1DE7F81750F@gpgtools.org>

Since its release, Canary Mail is probably your best option, since it support OpenPGP out-of-the-box.
If you rather prefer to keep using iOS Mail, you?ll have to resort to the much less than user friendly options oPenGP and iPGMail (as others have mentioned). They work, but the user experience is really not pleasant if you receive a lot of encrypted messages. Also I don?t think they support verification of PGP/MIME messages (due to restrictions imposed by iOS). 

Best,

Lukas
GPGTools

> Am 14.07.2017 um 20:48 schrieb E.Keen <contact at ekeen.press>:
> 
> 
> 
> Dear community,
> 
> I am very passionate about cyber security and working against mass
> surveillance. I therefore try to stay informed about security
> measurements and encryption.
> 
> Nevertheless, I do have a problem which I cannot solve by myself.
> 
> I generated a keypair using enigmail on thunderbird for this email address.
> Now, I'd like to use the same address with the same encryption keys on
> an iOS device.
> However, I don't know how to transfer the private key securely without
> anyone else being able to obtain it.
> Someone informed me that there might be a possibility to type in the
> private key manually.
> 
> I 'd appreciate any help or further information you might give me.
> 
> Thank you very much.
> 
> Kind Regards,
> 
> E.Keen
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



From marfig at gmx.com  Tue Jul 25 22:30:17 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Tue, 25 Jul 2017 21:30:17 +0100
Subject: gpg-agent cache keygrip
Message-ID: <20170725213017.3d4ef828@Archbox>

Hello everyone,

I've been trying to understand gpg-agent cache behavior in the presence
of two distinct keys with the same passphrase. Namely, why is that it
only asks for the passphrase once, regardless of the key being used?

So I've read the Assuan protocol documentation at (1), in particular
the text in the linked page and the descriptions for PRESET_PASSPHRASE
and GET_PASSPHRASE. But it isn't getting me any closer to understand
this behavior, because from my own interpretation, it enters into
contradiction with what I am experiencing.

I would normally expect the gpg-agent cache to operate on a per-key
basis, regardless of passphrase. And this is precisely what the
description for the keygrip on the Assuan protocol seems to indicate.
However, that is not what happens and gpg-agent seems to ignore the key
being used and instead reuse the previously used passphrase from
another key, which just happens to be the same passphrase for the new
key.

Is this a bug, or expected behavior? And if the latter, what is the
rationale for it? Since it seems to only worsen an already weak
decision security-wise, which is to choose the same passphrase for two
distinct keys. 

 (1)
https://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html#Agent-Protocol

-- 
Sinceramente / Best regards,

M?rio J.G.P. Figueiredo
Luanda, Angola
(email) marfig at gmx.com (alt) krugar at openmailbox.org
(phone) +244 934 535 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170725/789a75d0/attachment-0001.sig>

From write2mark1 at gmail.com  Tue Jul 25 23:28:23 2017
From: write2mark1 at gmail.com (mark M)
Date: Tue, 25 Jul 2017 21:28:23 +0000
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <8B5CE44A-A0F9-4A08-BAAE-F1DE7F81750F@gpgtools.org>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>,
 <8B5CE44A-A0F9-4A08-BAAE-F1DE7F81750F@gpgtools.org>
Message-ID: <CY4PR19MB092061F164E424D72E759326F3B80@CY4PR19MB0920.namprd19.prod.outlook.com>

But these are all paid apps are there any open source or free apps to do PGP on iOS

________________________________
From: Gnupg-users <gnupg-users-bounces at gnupg.org> on behalf of Lukas Pitschl | GPGTools <lukele at gpgtools.org>
Sent: Tuesday, July 25, 2017 12:42:47 PM
To: E.Keen
Cc: gnupg-users at gnupg.org
Subject: Re: How to use a the same generated keypair on enigmail/thunderbird and iOS Mail

Since its release, Canary Mail is probably your best option, since it support OpenPGP out-of-the-box.
If you rather prefer to keep using iOS Mail, you?ll have to resort to the much less than user friendly options oPenGP and iPGMail (as others have mentioned). They work, but the user experience is really not pleasant if you receive a lot of encrypted messages. Also I don?t think they support verification of PGP/MIME messages (due to restrictions imposed by iOS).

Best,

Lukas
GPGTools

> Am 14.07.2017 um 20:48 schrieb E.Keen <contact at ekeen.press>:
>
>
>
> Dear community,
>
> I am very passionate about cyber security and working against mass
> surveillance. I therefore try to stay informed about security
> measurements and encryption.
>
> Nevertheless, I do have a problem which I cannot solve by myself.
>
> I generated a keypair using enigmail on thunderbird for this email address.
> Now, I'd like to use the same address with the same encryption keys on
> an iOS device.
> However, I don't know how to transfer the private key securely without
> anyone else being able to obtain it.
> Someone informed me that there might be a possibility to type in the
> private key manually.
>
> I 'd appreciate any help or further information you might give me.
>
> Thank you very much.
>
> Kind Regards,
>
> E.Keen
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170725/2af007c6/attachment.html>

From wk at gnupg.org  Wed Jul 26 08:52:12 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Jul 2017 08:52:12 +0200
Subject: gpg-agent cache keygrip
In-Reply-To: <20170725213017.3d4ef828@Archbox> (Mario Figueiredo's message of
 "Tue, 25 Jul 2017 21:30:17 +0100")
References: <20170725213017.3d4ef828@Archbox>
Message-ID: <87bmo76677.fsf@wheatstone.g10code.de>

On Tue, 25 Jul 2017 22:30, marfig at gmx.com said:

> I've been trying to understand gpg-agent cache behavior in the presence
> of two distinct keys with the same passphrase. Namely, why is that it
> only asks for the passphrase once, regardless of the key being used?

There is a kludge in gpg and gpg-agent described in this comment:

  /* The standard use of GPG keys is to have a signing and an
     encryption subkey.  Commonly both use the same
     passphrase.  We try to help the user to enter the
     passphrase only once by silently trying the last
     correctly entered passphrase.  Checking one additional
     passphrase should be acceptable; despite the S2K
     introduced delays. The assumed workflow is:

       1. Read encrypted message in a MUA and thus enter a
          passphrase for the encryption subkey.

       2. Reply to that mail with an encrypted and signed
          mail, thus entering the passphrase for the signing
          subkey.

     We can often avoid the passphrase entry in the second
     step.  We do this only in normal mode, so not to
     interfere with unrelated cache entries.  */

"normal modes" is one of the cache classes we have in gpg-agent.  This
one is for unprotecting gpg or gpgsm keys.

If you want to follow what is going on, you may add

  verbose
  debug ipc,cache
  log-file socket://

into gpg-agent.conf, restart the agent and run 

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

on another tty.



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: </pipermail/attachments/20170726/8ff7d6ce/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jul 26 11:27:19 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 26 Jul 2017 10:27:19 +0100
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press> 
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
 <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
Message-ID: <645364014.20170726102719@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Tuesday 25 July 2017 at 9:49:15 PM, in
<mid:1d6cfe36-b4d0-28d3-233d-1e3a40a7708c at gmx.com>, Andreas Heinlein
wrote:-


> I still would not recommend that to non-technical
> people. While the
> users on this list probably know what a 'decent'
> passphrase is, most
> normal users don't. They tend to choose passwords
> which are too short,
> contain dictionary words - or they are written down
> right under the
> keyboard... Having a second line of defense, i.e.
> keeping the private
> key secure, is usually a good idea. That's the whole
> point of the
> OpenPGP smartcard, after all.

Do "most normal users" make use of an OpenPGP smartcard? Those that do
might be able to use the same keypair on their mobile phone by means
of an NFC-enabled smartcard.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Ultimate consistency lies in being consistently inconsistent
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXhgfl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5AsfAP9hhucd8ifzPhIsSZiFSHJmsuOw1CBYE6bAcKFXSi8kIQD+IH+kDNLW6WTU
9TLUlqINxgJe+UE0/XaAxaD/t6Xc7A2JAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXhgj18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8NLQB/9Z66y179mYiHkgNXX2oW6cdFgo
VoaPcImpg+nKzMITS6XXynRxUoc2mWBD3SI1bV5EyEuDk47qd+PmKyGXf6dPUoog
IF9psxhLmPyVIELKZduZn0rAdE7a3kvup4OJJdTPmLdh5iNbdWwoufaCvU3gxipF
730imQUUgAaVYTXxLvB4DFzUcHXmML8ci9VJdbaRxEyRwmzBNTyiL02gMtlvmuch
pxdkJal7qCnUf1RYwHlUHNxNlIek/9pDgxs1PP/HzwrpvAFoxMUMZJPA95Ld6f6Z
ekKmsYxOJBwLKKCO+OQnPk7nrtxPO9e9sqIbMEHURE8FfXTNDvEeotoocvOt
=Az0j
-----END PGP SIGNATURE-----



From gnupg-user at niob.at  Wed Jul 26 02:21:40 2017
From: gnupg-user at niob.at (gnupg-user at niob.at)
Date: Wed, 26 Jul 2017 02:21:40 +0200
Subject: gpgme - raw RSA operation using GPG public/private keys?
In-Reply-To: <3ce438ef-ef56-5d60-94ac-66f5e67941b0@niob.at>
References: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>
 <87d196y1dj.fsf@fifthhorseman.net>
 <3ce438ef-ef56-5d60-94ac-66f5e67941b0@niob.at>
Message-ID: <2f5827cd-b73f-b6b4-fca4-515db0f013e1@niob.at>

Hello List!

One more question for this topic: Am I right that secret key export is
not really implemented, even though there is the
GPGME_EXPORT_MODE_SECRET flag to gpgme_op_export_keys()?

If this is correct: Why is there such a flag?

sincerely

peter


Am 17/07/17 um 13:25 schrieb gnupg-user at niob.at:
> Am 12.07.2017 um 01:55 schrieb Daniel Kahn Gillmor:
>> On Fri 2017-07-07 18:01:03 +0200, gnupg-user at niob.at wrote:
>>> I am looking for a "simple" way to use a GPG public/private RSA key to
>>> do "raw" RSA operations. I have the impression, that gpgme only deals
>>> with "real" OpenPGP data structures, but this does not fit my use case.
>>> This is for an application that is currently based on openssl crypto.
>> you're right -- gpgm is only for higher-level protocol operations,
>> whether they're OpenPGP or CMS (cryptographic message syntax).  it
>> doesn't offer low-level crypto primitives.
>>
>> if you want low-level crypto primitives that are GPL-compatible, you can
>> use libhogweed (from the nettle project) or libgcrypt.
> Thanks a lot for the answer. So the next question is: How? That is: I
> could not find any libgcrypt functions taking a gpg key obtainable
> through gpgme.
>
> But that is the key problem (haha): I *could* (by hand) parse a secret
> key exported using gpg (or, if possible, through gpgme) and use the RSA
> parameters to build up the key structure required for either libgcrypt
> (or openssl). But that would make it impossible to deal with e.g. gpg
> agents.
>
> So to rephrase the question: How would I proceed to do raw RSA
> operations using libcrypt for gpg keys stored in a standard key ring? Or
> is this functionality not exposed directly in any library? Would it be
> best to look at how gpg itself does this? Any pointers (source files,
> docs, examples, etc.?)
>
>> Modern GnuPG uses libgcrypt for its crypto primitives, fwiw.
> I want to be modern as well... :-)
>>        --dkg
> peter
>
>




From aheinlein at gmx.com  Wed Jul 26 13:27:20 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Wed, 26 Jul 2017 13:27:20 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <645364014.20170726102719@riseup.net>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
 <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
 <645364014.20170726102719@riseup.net>
Message-ID: <8a519420-457e-e872-ee17-e268c3178910@gmx.com>

Am 26.07.2017 um 11:27 schrieb MFPA:
> Do "most normal users" make use of an OpenPGP smartcard? Those that do
> might be able to use the same keypair on their mobile phone by means
> of an NFC-enabled smartcard.
Surely not. I guess most "normal users" don't even know that such a
thing exists.

Besides that, AFAIK the NFC-functionality on several SmartCards is not
for use with OpenPGP, it's just there for additional purposes with other
applications.

Bye,
Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170726/74e878b9/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jul 26 14:24:31 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 26 Jul 2017 13:24:31 +0100
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <8a519420-457e-e872-ee17-e268c3178910@gmx.com>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press> 
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
 <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
 <645364014.20170726102719@riseup.net>
 <8a519420-457e-e872-ee17-e268c3178910@gmx.com>
Message-ID: <436574568.20170726132431@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 26 July 2017 at 12:27:20 PM, in
<mid:8a519420-457e-e872-ee17-e268c3178910 at gmx.com>, Andreas Heinlein
wrote:-



> Besides that, AFAIK the NFC-functionality on several
> SmartCards is not
> for use with OpenPGP, it's just there for additional
> purposes with other
> applications.

At least on some, NFC works with OpenPGP. For example, see
<https://www.grepular.com/An_NFC_PGP_SmartCard_For_Android>.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

No matter what a man's past may have been, his future is spotless.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXiKAl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5HqlAQCmFewc0eqa/TU4CxS9vmYtu+YM4xog3tRdWRJ5HjuyegD/XIl17phzyFt+
hPIQRw4Golp3ysr6EnDFamMudTVlTAKJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXiKEF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8LeDCACAd6ycOQY0aLE0ip+2WWNAnScX
5/0jE439gGT2QghAEunYrpQnTnV66f1Nej7jokGU1+1YR2cxAckcBThmBOuZL4/s
pLI1VqY3ky8TKKvoQf3JcyoMZ9RV63B6Ws0yLu7ER6U0thHwuMsPbTPhl2f7NQx3
quArOYYzCAgWR6aVGyyPGje0OcrBY4PyGSNn2dYAPWsVBRnwhySS7Tz2sqXyPA90
16mfCm3KmRh65bOwhP0VyUDaWXG0kOeZYy55oWiRgFQxkOL1UTOmtKGQstShrl8W
TWlupHWJi5LFisHC5Rt8h8tvG+H8USn64smk/7nxOIQnwzAZXaHWj30hr7PB
=dnYV
-----END PGP SIGNATURE-----



From dekkzz78 at gmail.com  Wed Jul 26 14:05:37 2017
From: dekkzz78 at gmail.com (dekkzz78 at gmail.com)
Date: Wed, 26 Jul 2017 13:05:37 +0100
Subject: How to use a the same generated keypair on
 enigmail/thunderbird and iOS Mail
In-Reply-To: <8a519420-457e-e872-ee17-e268c3178910@gmx.com>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
 <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
 <645364014.20170726102719@riseup.net>
 <8a519420-457e-e872-ee17-e268c3178910@gmx.com>
Message-ID: <20170726120537.GA10611@TP-x61s.localdomain>

On 07/26, Andreas Heinlein wrote:
>Am 26.07.2017 um 11:27 schrieb MFPA:
>> Do "most normal users" make use of an OpenPGP smartcard? Those that do
>> might be able to use the same keypair on their mobile phone by means
>> of an NFC-enabled smartcard.
>Surely not. I guess most "normal users" don't even know that such a
>thing exists.
>
>Besides that, AFAIK the NFC-functionality on several SmartCards is not
>for use with OpenPGP, it's just there for additional purposes with other
>applications.
>
>Bye,
>Andreas
>

When you say not for use with OpenPGP, do you mean most "smartcards" marked as SLE4442 compatible won't work with 
GnuPG?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170726/af0dde14/attachment.sig>

From aheinlein at gmx.com  Wed Jul 26 16:12:14 2017
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Wed, 26 Jul 2017 16:12:14 +0200
Subject: How to use a the same generated keypair on enigmail/thunderbird
 and iOS Mail
In-Reply-To: <20170726120537.GA10611@TP-x61s.localdomain>
References: <29f09c5b-c3c6-0955-f803-a41533699b71@ekeen.press>
 <262069443.20170725191551@riseup.net>
 <93cef2b2-3171-dc14-36e9-5f92f4a5b927@sixdemonbag.org>
 <1d6cfe36-b4d0-28d3-233d-1e3a40a7708c@gmx.com>
 <645364014.20170726102719@riseup.net>
 <8a519420-457e-e872-ee17-e268c3178910@gmx.com>
 <20170726120537.GA10611@TP-x61s.localdomain>
Message-ID: <5202a17a-7f93-cad1-4d7d-a1ff5a5e50ff@gmx.com>

Am 26.07.2017 um 14:05 schrieb dekkzz78 at gmail.com:
> On 07/26, Andreas Heinlein wrote:
>> Am 26.07.2017 um 11:27 schrieb MFPA:
>>> Do "most normal users" make use of an OpenPGP smartcard? Those that do
>>> might be able to use the same keypair on their mobile phone by means
>>> of an NFC-enabled smartcard.
>> Surely not. I guess most "normal users" don't even know that such a
>> thing exists.
>>
>> Besides that, AFAIK the NFC-functionality on several SmartCards is not
>> for use with OpenPGP, it's just there for additional purposes with other
>> applications.
>>
>> Bye,
>> Andreas
>>
>
> When you say not for use with OpenPGP, do you mean most "smartcards"
> marked as SLE4442 compatible won't work with GnuPG?

Actually the one OpenPGP smartcard I know of is sold by FLOSS-Shop
(ex-kernel-concepts):
https://www.floss-shop.de/de/security-privacy/smartcards/4/openpgp-smart-card-v2.1-mifare-desfire?c=41

This one has an NFC chip but which is not for use with OpenPGP.

There may be other smartcards out there which can also be used with
GnuPG but they're usually not called "OpenPGP card".

Andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170726/980b233c/attachment.sig>

From wk at gnupg.org  Wed Jul 26 18:03:51 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Jul 2017 18:03:51 +0200
Subject: gpgme - raw RSA operation using GPG public/private keys?
In-Reply-To: <2f5827cd-b73f-b6b4-fca4-515db0f013e1@niob.at>
 (gnupg-user@niob.at's message of "Wed, 26 Jul 2017 02:21:40 +0200")
References: <7586036c-544c-a9c8-2534-782a7e33839e@niob.at>
 <87d196y1dj.fsf@fifthhorseman.net>
 <3ce438ef-ef56-5d60-94ac-66f5e67941b0@niob.at>
 <2f5827cd-b73f-b6b4-fca4-515db0f013e1@niob.at>
Message-ID: <87zibr423c.fsf@wheatstone.g10code.de>

On Wed, 26 Jul 2017 02:21, gnupg-user at niob.at said:

> One more question for this topic: Am I right that secret key export is
> not really implemented, even though there is the
> GPGME_EXPORT_MODE_SECRET flag to gpgme_op_export_keys()?

No, it is implemented.  You may use the run-export test program from
the gpgme build directory to test it:

  $ ./run-export --openpgp --secret patrice.lumumba at example.net
  keyid: 139563682A020D0A  (fpr: B21DEAB4F875FB3DA42F1D1D139563682A020D0A)
  exporting secret keys!
  Begin Result:
  -----BEGIN PGP PRIVATE KEY BLOCK-----
  
  lIYEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
  nTEoBRn+BwMCg63ihXzAmZ3h0IU0FKiAxZOSy5VAKrU1M1f9/euePQpNXK1X50ef
  WWb2zuE37junfzr5TITbl/3EC4YgbH/FmhvztZJxjoqcg6CNhTUtzLQbcGF0cmlj
  ZS5sdW11bWJhQGV4YW1wbGUubmV0iHkEExYIACEFAldqPV0CGwMFCwkIBwIGFQgJ
  CgsCBBYCAwECHgECF4AACgkQE5VjaCoCDQqZDQEAxQ3MCVM7Mbu2iVIj3aWF4+Ll
  Wq612pMRBPJhhaLVoSwA/Rh+K6iw2CBNzShFNLPjpLeLRCMCWlfB9TTTzzzIit4N
  nIsEV2o9jRIKKwYBBAGXVQEFAQEHQBZ55mXPfU7ipOYgqvcJmGVFRdkXFzdgrKgJ
  fIhkEFFrAwEIB/4HAwK7JqxPETtQvuFYDuRCIj/saGn4B+5WgpRdDlW78NkfNIi/
  c9wS2u6zvhIM8LboJgH6hxQR1wcNR1OTdGYaNCqbBroYu0RvNL8ad476PLiQiGEE
  GBYIAAkFAldqPY0CGwwACgkQE5VjaCoCDQrLhQD/QaZVpfNd6Yu+/VfDjLERrP8p
  8ooZzhEn7fx/KpTPDw0BAKiFD6SLcjl/zgRctkSJSIuydW06fUc3G80P+BZOIVkE
  =SgH0
  -----END PGP PRIVATE KEY BLOCK-----
  End Result.


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: </pipermail/attachments/20170726/08cb954c/attachment.sig>

From marfig at gmx.com  Wed Jul 26 21:08:28 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Wed, 26 Jul 2017 20:08:28 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <87bmo76677.fsf@wheatstone.g10code.de>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de>
Message-ID: <20170726200828.7376fc14@Archbox>

On Wed, 26 Jul 2017 08:52:12 +0200
Werner Koch <wk at gnupg.org> wrote:

> There is a kludge in gpg and gpg-agent described in this comment:
> [...]

Hello Werner,

Thank you for the information and debug method. And hopefully this
problem will be fixed sometime in the near future. My brain is old
and tired and it can't just commit to yet another unique password of
any decent quality.

The sharing of passwords between different keys becomes inevitable
after a certain threshold. And I suspect for everyone, not just old
people. And the gpg-agent just isn't dealing with this situation in an
acceptable way.

-- 
Sinceramente / Best regards,

M?rio J.G.P. Figueiredo
Luanda, Angola
(email) marfig at gmx.com (alt) krugar at openmailbox.org
(phone) +244 934 535 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170726/bd5c968b/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Jul 26 22:38:48 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 26 Jul 2017 22:38:48 +0200
Subject: gpg-agent cache keygrip
In-Reply-To: <20170726200828.7376fc14@Archbox>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de> <20170726200828.7376fc14@Archbox>
Message-ID: <7ea30842-5b49-0aef-7f33-7ddf353e6cb5@sumptuouscapital.com>

On 07/26/2017 09:08 PM, Mario Figueiredo wrote:
> On Wed, 26 Jul 2017 08:52:12 +0200
> Werner Koch <wk at gnupg.org> wrote:
> 
>> There is a kludge in gpg and gpg-agent described in this comment:
>> [...]
> 
> Hello Werner,
> 
> Thank you for the information and debug method. And hopefully this
> problem will be fixed sometime in the near future. My brain is old
> and tired and it can't just commit to yet another unique password of
> any decent quality.
> 
> The sharing of passwords between different keys becomes inevitable
> after a certain threshold. And I suspect for everyone, not just old
> people. And the gpg-agent just isn't dealing with this situation in an
> acceptable way.
> 

Have you considered using smartcards/tokens to ensure the secret key
material is only available when you expect to do operations using the
particular keys (as well as protecting against several other threat
vectors)?

-- 
----------------------------
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
----------------------------
Fabricando fit faber
Practice makes perfect

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170726/c33b6b38/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Jul 26 23:41:23 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 26 Jul 2017 23:41:23 +0200
Subject: Operation not supported by device
In-Reply-To: <3xGNxJ4k0wz105R@submission01.posteo.de>
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
Message-ID: <e835d027-5c8e-7ef0-2265-5cf379c2af01@sumptuouscapital.com>

On 07/24/2017 04:27 PM, Stefan Claas wrote:
> The file is signed and can be verified. Just wondering (after googling)
> what this means, because i have no card reader etc. for GnuPG.

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2

-- 
----------------------------
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
----------------------------
Amantes sunt amentes
Lovers are lunatics

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170726/f60f92ed/attachment-0001.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jul 27 11:24:46 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 27 Jul 2017 10:24:46 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <20170726200828.7376fc14@Archbox>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de> 
 <20170726200828.7376fc14@Archbox>
Message-ID: <192775988.20170727102446@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wednesday 26 July 2017 at 8:08:28 PM, in
<mid:20170726200828.7376fc14 at Archbox>, Mario Figueiredo wrote:-


> The sharing of passwords between different keys
> becomes inevitable
> after a certain threshold. And I suspect for
> everyone, not just old
> people.


Have you considered using a password manager to remember them?


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Can you imagine a world with no hypothetical situations?
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXmxZV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5DonAQD5cRWxsdnp2NklcT07FSE4RC+jLKPeywbvZhTbu30lRAEAsoHz30Invp8t
kr3qhXAM1zNp7NQGO46/QYSMB2HFQQWJAZIEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXmxcF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8NF4B/jayHrd1Ah+0EIhT5KVu7IkQ97Z
TmFSyofuGkSQg9aweww+/iM860r6GbEaTK2mJPDnDwNhhoi+kzyISUDpcEMVHaPk
eLkgBZtD/fcneFZ2Ky3SY2Y6A9caZqz0OoNnR7yo/qWh84ApuytutSBVD/k1k714
SBBADgUNDn6GiezcEZ1kJdYEEpSwfws6DTP8YPDpiZ7T8+OO03kKSMHlp0ReSeKF
J1yKmX4ydLnv01hQewnKP2DbbX2OgQccHAhDVJ1g5AkufYdUR7LVH8C5DLLDaLgF
MNgWqCXVv+RVh8iAiwU3bD5XrzKqcxfzBcRTkMG+KyexCYAlSxgtzAPXVhg=
=lZs0
-----END PGP SIGNATURE-----



From peter at digitalbrains.com  Thu Jul 27 11:46:33 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 27 Jul 2017 11:46:33 +0200
Subject: gpg-agent cache keygrip
In-Reply-To: <192775988.20170727102446@riseup.net>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de> <20170726200828.7376fc14@Archbox>
 <192775988.20170727102446@riseup.net>
Message-ID: <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>

On 27/07/17 11:24, MFPA wrote:
> Have you considered using a password manager to remember them?

What would be the purpose?

I already fail to see the problem of GnuPG filling in a passphrase it
already knows... surely an attacker would try the same thing as well, I
don't know what GnuPG not trying a known passphrase would actually gain
you in security. GnuPG is not your attacker.

Adding a passphrase manager only introduces another layer of indirection
plus extra steps for the user to unlock their key, but it seems to solve
no actual problem. It just moves the item that is of interest to the
attacker.

Mario, if you for some reason don't like to unlock both keys at once,
for instance so you notice the first time during your session you use
your key, you could also add a number to the passphrase. For instance,
if your passphrase for both keys is "This is surely suboptimal", you
could give one key the passphrase "This is surely suboptimal1" and the
other "This is surely suboptimal2". Then GnuPG won't unlock both keys at
once, but you still don't need to remember more than when you shared the
passphrase. If you can't remember which is 1 and which is 2, use
something you can recognise. For instance, if the pinentry asks you
"Please unlock key 0x6228A8BC", you could append a C, the very last
digit of the identifier.

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: </pipermail/attachments/20170727/eca2ecfd/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jul 27 13:27:30 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 27 Jul 2017 12:27:30 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de> 
 <20170726200828.7376fc14@Archbox> <192775988.20170727102446@riseup.net>
 <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
Message-ID: <427141094.20170727122730@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Thursday 27 July 2017 at 10:46:33 AM, in
<mid:e74cc71a-5049-403b-32e0-ba9f0fe3f4a8 at digitalbrains.com>, Peter
Lebbing wrote:-


> On 27/07/17 11:24, MFPA wrote:
>> Have you considered using a password manager to
>> remember them?

> What would be the purpose?

I guess I should have trimmed my quote less severely. Using a password
manager would enable somebody who says they cannot remember multiple
decent-quality unique passwords to not share passwords between
different keys.



> Adding a passphrase manager only introduces another
> layer of indirection
> plus extra steps for the user to unlock their key,

Extra steps to open the password manager. Once open there are no extra
steps for subsequent unlocking of the user's GnuPG key; it may even
speed things up in the event that the password manager types
passphrases quicker than the user can type them.


> but it seems to solve
> no actual problem. It just moves the item that is of
> interest to the
> attacker.

The single point of failure stops being a passphrase used across
multiple keys; it becomes the password required to open the password
manager that protects the multiple passphrases.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

COMMITTEE: A body that keeps minutes and wastes hours.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXnOJ18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5AZ3AQCaNMl2oJ3kDWTPScP4OvPcVmsyWa7C7+ZF/aBd9m8hSAD+KuwBpBMkbpp+
y5gn1fXIMZ5NLR8OXKIWF8nR32oNvASJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXnOMl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8Hl8B/4xUCdIUueGMVTrU0bSd79ityjN
oJQWk15Hz5tX/3BnVnn8xJMECTquow1Nf1XmwxKyaqME9pDtXPbFBHp+WzV04glT
FD/4SgE0BPTtyadGbDHYaE0rHHPL1bzFg4f3F8uRz9otSHC6KeTLAhBJxBYQaK++
qYe2npD+IAUUU1sPluWGhrPWnu99c2Tw8REq/BH0T2sk4zwIkYTedGX1eExzH7Hw
Kjdh9uMuBa1rWfaaYfsOnDrzvkdW3kmiu8ngdE4BCVEVtzqSvmDBP8+dxgZKzESK
Bc5+HY2/pyB+0tWJ+Yaa8ilFeD9LDIbokrr/Iiyw0Frv3sVhXgrLhPYW2YYW
=2vsb
-----END PGP SIGNATURE-----



From peter at digitalbrains.com  Thu Jul 27 14:23:44 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 27 Jul 2017 14:23:44 +0200
Subject: gpg-agent cache keygrip
In-Reply-To: <427141094.20170727122730@riseup.net>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de> <20170726200828.7376fc14@Archbox>
 <192775988.20170727102446@riseup.net>
 <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
 <427141094.20170727122730@riseup.net>
Message-ID: <01234e98-d4fc-4e87-7b8f-3f5ddcb556b3@digitalbrains.com>

On 27/07/17 13:27, MFPA wrote:
> I guess I should have trimmed my quote less severely. Using a password
> manager would enable somebody who says they cannot remember multiple
> decent-quality unique passwords to not share passwords between
> different keys.

Ah yes :-). I agree.

> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.

Let's look at multiple cases of passphrase reuse:

1) Using the same passphrase for multiple remote systems

If one of the remote systems is compromised, all your accounts with the
same passphrase are compromised. Sounds to me like a bad idea. There are
many different actors and implementations. All it takes is one bad apple.

2) Using the same passphrase in multiple different programs on your own
computer.

When an attacker can compromise one of the programs, but only that, the
attacker still gains access to the encrypted data held in multiple
programs, even if the others are safe by themselves. Possible ways of
compromise that spring to mind are some way to access a running program
remotely, such as by feeding it crafted data exploiting a vulnerability
in the program, or by the fact that data at rest is not well encrypted,
using a file from a backup the attacker gained access to.

3) Using the same passphrase for multiple instances of data in the same
program.

If an attacker is able to compromise one instance, why couldn't they do
another? You might be lucky if it is an attack that requires a running
computer and the attacker only manages to entice the program once. If it
is an attack at data at rest, at poor encryption of the file, then the
workload increases a mere factor two. If they need five days to crack
the encryption of one instance, they only need yet another five days to
crack the other even if the passphrases were different.

For case 3), I'd say it is sheer luck if an attacker only learns one
passphrase rather than the multiple passphrases you use with the same
program. It's not a significant increase in security.

This way of reasoning gets you quite far. It's not completely
conclusive; for one, it depends on all instances being treated the same
way, i.e., all secret keys are stored on the same system /and/ in the
same backups. And suppose some form of key derivation can be cracked
quicker if there are multiple derivations of the same data and salting
is somehow compromised. Then it would be a bad idea to reuse a
passphrase for multiple instances, but I'd say that key derivation or
the random number generator involved is bad anyway and shouldn't be used
at all, even when you don't reuse passphrases. And there are probably a
few different scenarios where you might make yourself weaker.

But personally, without further details convincing me otherwise, I would
not be overly worried about using the same key for multiple instances in
the same program on the same system.

Furthermore, I'd say that the way GnuPG uses a passphrase is safe and an
encrypted private key file doesn't help an attacker to gain access to
the same passphrase in a different program.

Now let's get on to a passphrase manager and GnuPG specifically. A
different way to look at it is this: would you use GnuPG to protect your
passphrase manager? This is actually a feature request I've seen
multiple times: please provide a way to use my OpenPGP key to unlock my
passphrase manager. In that way, the security of the passphrase manager
is utterly dependent on the security of GnuPG. Crack GnuPG, and the
passphrase manager falls immediately as well.

Now there is one avenue left: would we mind if the security of GnuPG is
utterly dependent on the security of the passphrase manager? If you
propose to store the GnuPG passphrases in the passphrase manager,
apparently you're okay with that as well. Crack the passphrase manager,
and GnuPG has no further protections.

Okay, so let's say we don't mind if the security of GnuPG utterly
depends on the security of the passphrase manager, *or* vice versa.
Furthermore, I state pretty confidently that the way GnuPG uses
passphrases does not cause an interaction with other data being
encrypted with the same passphrase in a different program; there is no
way to crack some other piece of data, say your passphrase manager
database, quicker because you have access to the *encrypted* private
keys of GnuPG. Conversely, there is no way to crack an encrypted private
key in GnuPG quicker because some other key derivation function is used
with the same passphrase (other than to crack that other key derivation
by itself).

Then why don't you just use the same passphrase for your passphrase
manager as for your private keys in GnuPG? Again, this only goes if you
belong to both user groups touched upon: those who would consider it a
good thing if the passphrase manager unlocks with their OpenPGP private
key, and those who would store their GnuPG passphrases in a passphrase
manager.

By the way, to reiterate, merely considering data at rest, I dare to
state that reusing passphrases in GnuPG does not compromise the
encrypted data in any way. If an attacker has access to two encrypted
private keys from GnuPG, encrypted with the same passphrase, they are no
further in cracking it than if they had only the one. Once they do crack
it, they can access both. But the cracking itself is, and remains,
impossible for a good passphrase, no matter how many pieces of data from
GnuPG with the same passphrase the attacker has. That's an important
property of a good key derivation function.

My 2 cents,

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: </pipermail/attachments/20170727/d7c17a4e/attachment.sig>

From marfig at gmx.com  Thu Jul 27 14:46:10 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Thu, 27 Jul 2017 13:46:10 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <427141094.20170727122730@riseup.net>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de>
 <20170726200828.7376fc14@Archbox>
 <192775988.20170727102446@riseup.net>
 <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
 <427141094.20170727122730@riseup.net>
Message-ID: <20170727134610.313d983b@Archbox>

On Thu, 27 Jul 2017 12:27:30 +0100
MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:

> 
> The single point of failure stops being a passphrase used across
> multiple keys; it becomes the password required to open the password
> manager that protects the multiple passphrases.

I already use a password manager. I use 'pass'. Most my keys are
generated with `pwgen -s` (for some reason I prefer it to pass own
generator). All told, I have 83 password file entries
in .password-store/.

But these are non essential passwords. Forums, internet services, etc.
You must understand, I use old systems that I maintain for 10 years or
more. Despite backups there is always the fear that I might one day
lose this central password storage. So essential passwords are created
differently; GnuPG keys, my 2 main email addresses, system boot,
banking, taxes website, CC pin,... this world is not an easy place to
live in.

They do too have their entries on the password store, of course. But
they must be committed to memory too. As such, for these type of
passwords, you understand that a password manager acts simply as an
unreliable backup store and not and not as a management tool. 

-- 
Sinceramente / Best regards,

M?rio J.G.P. Figueiredo
Luanda, Angola
(email) marfig at gmx.com (alt) krugar at openmailbox.org
(phone) +244 934 535 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170727/4f0a0d3d/attachment-0001.sig>

From marfig at gmx.com  Thu Jul 27 14:50:47 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Thu, 27 Jul 2017 13:50:47 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de>
 <20170726200828.7376fc14@Archbox>
 <192775988.20170727102446@riseup.net>
 <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
Message-ID: <20170727135047.6cf330ec@Archbox>

On Thu, 27 Jul 2017 11:46:33 +0200
Peter Lebbing <peter at digitalbrains.com> wrote:

[...]
> shared the passphrase. If you can't remember which is 1 and which is
> 2, use something you can recognise. For instance, if the pinentry
> asks you "Please unlock key 0x6228A8BC", you could append a C, the
> very last digit of the identifier.

Excellent idea in fact!
Thank you.

-- 
Sinceramente / Best regards,

M?rio J.G.P. Figueiredo
Luanda, Angola
(email) marfig at gmx.com (alt) krugar at openmailbox.org
(phone) +244 934 535 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170727/137203fb/attachment.sig>

From marfig at gmx.com  Thu Jul 27 16:33:07 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Thu, 27 Jul 2017 15:33:07 +0100
Subject: gpg-agent cache keygrip
In-Reply-To: <01234e98-d4fc-4e87-7b8f-3f5ddcb556b3@digitalbrains.com>
References: <20170725213017.3d4ef828@Archbox>
 <87bmo76677.fsf@wheatstone.g10code.de>
 <20170726200828.7376fc14@Archbox>
 <192775988.20170727102446@riseup.net>
 <e74cc71a-5049-403b-32e0-ba9f0fe3f4a8@digitalbrains.com>
 <427141094.20170727122730@riseup.net>
 <01234e98-d4fc-4e87-7b8f-3f5ddcb556b3@digitalbrains.com>
Message-ID: <20170727153307.6c66d12d@Archbox>

On Thu, 27 Jul 2017 14:23:44 +0200
Peter Lebbing <peter at digitalbrains.com> wrote:

> Now let's get on to a passphrase manager and GnuPG specifically. A
> different way to look at it is this: would you use GnuPG to protect
> your passphrase manager? This is actually a feature request I've seen
> multiple times: please provide a way to use my OpenPGP key to unlock
> my passphrase manager. In that way, the security of the passphrase
> manager is utterly dependent on the security of GnuPG. Crack GnuPG,
> and the passphrase manager falls immediately as well.

This is precisely what 'pass' (1) does. I never looked back since I
started using it.

Of note also the fact pass is not a a compiled program, but instead a
shell script smartly wrapping GnuPG functionality into the shape of a
password manager. For this reason, I don't know if anyone ever ported
the idea to Windows, but from what little I remember of Powershell, it
would be perfectly doable.

I use pass with rofi-pass to facilitate the integration with browsers
and applications, allowing me to quickly enter passwords without typing
them into any type of program that accepts keyboard input from the
clipboard. And without *any* need for plugins of any sort on those
pesky browsers.


> and those who would store their GnuPG passphrases in a
> passphrase manager.

This indeed is not so bad if is also GnuPG that is handling your
password manager. Although, I'd agree that is one thing to discover the
GnuPG passphrase for a password manager and it is another thing to also
discover that you now have the victim passwords for the remainder GnuPG
keys accessible to you.

But there are other considerations. Who am I? What I do in life? Who
are my enemies? Depending on how good we are answering these questions
in a rational way, I find that a large part of the general population
has little to no reason to fear storing sensitive GnuPG specific data
in their personal entirely-offline password store. 

As an FYI, I do not store the actual passphrases, but I do store the
0-type revocation certificates with 'pass'. I don't feel that
threatening and it tremendously facilitates things for someone without
any access to reliable and secure physical storage. There is no reason
why I couldn't store the passphrases also. I will eventually, the day I
start fearing my brain.

-- 
Sinceramente / Best regards,

M?rio J.G.P. Figueiredo
Luanda, Angola
(email) marfig at gmx.com (alt) krugar at openmailbox.org
(phone) +244 934 535 121
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170727/37ae2ae1/attachment.sig>

From sandhya.sharma at morpho.com  Thu Jul 27 15:00:29 2017
From: sandhya.sharma at morpho.com (SHARMA Sandhya (MORPHO))
Date: Thu, 27 Jul 2017 13:00:29 +0000
Subject: Invalid Crypto Error
Message-ID: <ed927bd4eadf47119da8342bd86ca277@Y0032RM.rd1.rf1>

Hello All,

I have to use GPG for windows.For that i have installed GPG4Win in my system and try to use it through C++ code using DLL libgpgme-glib-11.
Getting "Invalid crytpto Engine" while calling "gpgme_engine_check_version".

Plz find the code snippet::
void _stdcall LoadGPG()
{
gpgme_error_t error;
char* p;
gpgme_key_t recipients[2] = {NULL, NULL};
gpgme_data_t clear_text, encrypted_text;
gpgme_encrypt_result_t result;
gpgme_engine_info_t info;
gpgme_keylist_mode_t keymode;
gpgme_protocol_t proto;

/* Initialize the locale environment. */
setlocale(LC_ALL, "");
int n =gpgme_set_global_flag("disable-gpgconf","1");

n = gpgme_set_global_flag("bindir","C://Program Files (x86)GNUGnuPG");

p = (char *) gpgme_check_version (NULL);//to initialize gpg



gpgme_set_locale (NULL, LC_CTYPE, setlocale (LC_CTYPE, NULL));
#ifdef LC_MESSAGES
gpgme_set_locale (NULL, LC_MESSAGES, setlocale (LC_MESSAGES, NULL));
#endif
gpgme_ctx_t *context = (gpgme_ctx_t *)malloc(sizeof *context);
error = gpgme_new(context);
error = gpgme_set_protocol (*context, GPGME_PROTOCOL_OpenPGP);

keymode = gpgme_get_keylist_mode(*context);
info = gpgme_ctx_get_engine_info(*context);

/* Setting the output type must be done at the beginning */
gpgme_set_armor(*context, 1);

error = gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP);
pEngineinfoerror1 = gpgme_strerror(error) ;
gpgme_data_t data;
gpgme_data_t cipher;

gpgme_error_t e = gpgme_data_new(&data);

e = gpgme_data_new(&cipher);

gpgme_data_set_file_name(data, "C:\\Logs\\test.txt");
error= gpgme_op_encrypt(*context,0,(gpgme_encrypt_flags_t)0,data,cipher);
pEngineinfoerror1 = gpgme_strerror(error) ;

}
Please let me know the solution for it ASAP.


Thanks & Regards
Sandhya Sharma

#
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170727/84a26249/attachment.html>

From stefan.claas at posteo.de  Thu Jul 27 17:29:21 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 27 Jul 2017 17:29:21 +0200
Subject: Operation not supported by device
In-Reply-To: <e835d027-5c8e-7ef0-2265-5cf379c2af01@sumptuouscapital.com>
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
 <e835d027-5c8e-7ef0-2265-5cf379c2af01@sumptuouscapital.com>
Message-ID: <3xJG9b2f1xz107j@submission01.posteo.de>

On Wed, 26 Jul 2017 23:41:23 +0200, Kristian Fiskerstrand wrote:
> On 07/24/2017 04:27 PM, Stefan Claas wrote:
> > The file is signed and can be verified. Just wondering (after
> > googling) what this means, because i have no card reader etc. for
> > GnuPG.  
> 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2
> 
Thanks for the Info.

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 506 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170727/c72dc2be/attachment.sig>

From kristian.fiskerstrand at sumptuouscapital.com  Thu Jul 27 17:35:55 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 27 Jul 2017 17:35:55 +0200
Subject: Operation not supported by device
In-Reply-To: <3xJG9b2f1xz107j@submission01.posteo.de>
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
 <e835d027-5c8e-7ef0-2265-5cf379c2af01@sumptuouscapital.com>
 <3xJG9b2f1xz107j@submission01.posteo.de>
Message-ID: <315cd397-d588-632d-1531-e9aae067d279@sumptuouscapital.com>

On 07/27/2017 05:29 PM, Stefan Claas wrote:
> On Wed, 26 Jul 2017 23:41:23 +0200, Kristian Fiskerstrand wrote:
>> On 07/24/2017 04:27 PM, Stefan Claas wrote:
>>> The file is signed and can be verified. Just wondering (after
>>> googling) what this means, because i have no card reader etc. for
>>> GnuPG.  
>>
>> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=a8dd96826f8484c0ae93c954035b95c2a75c80f2
>>
> Thanks for the Info.

A bit more verbosely, if no scdaemon exists you will get an error value
that was not suppressed for a few versions, you can safely ignore the
warning and it is fixed in alter versions again, or you can
install/build gnupg with scdaemon even if not using a smartcard and it
will get the necessary info and be silent.

-- 
----------------------------
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
----------------------------
"By three methods we may learn wisdom: First, by reflection, which is
noblest; Second, by imitation, which is easiest; and third by
experience, which is the bitterest."
(Confucius)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170727/7192f501/attachment-0001.sig>

From stefan.claas at posteo.de  Thu Jul 27 19:10:07 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 27 Jul 2017 19:10:07 +0200
Subject: Operation not supported by device
In-Reply-To: <315cd397-d588-632d-1531-e9aae067d279@sumptuouscapital.com>
References: <3xGNxJ4k0wz105R@submission01.posteo.de>
 <e835d027-5c8e-7ef0-2265-5cf379c2af01@sumptuouscapital.com>
 <3xJG9b2f1xz107j@submission01.posteo.de>
 <315cd397-d588-632d-1531-e9aae067d279@sumptuouscapital.com>
Message-ID: <3xJJQ03WQtz10HZ@submission01.posteo.de>

On Thu, 27 Jul 2017 17:35:55 +0200, Kristian Fiskerstrand wrote:

> A bit more verbosely, if no scdaemon exists you will get an error
> value that was not suppressed for a few versions, you can safely
> ignore the warning and it is fixed in alter versions again, or you can
> install/build gnupg with scdaemon even if not using a smartcard and it
> will get the necessary info and be silent.
> 

Thanks again, however i do have scdaemon installed in
/usr/local/gnupg-2.1/libexec/scdaemon. But no problem.

I was just curious about that gpg message output.

Regards
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 506 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170727/a8df7755/attachment.sig>

From rajesh.solaris10 at gmail.com  Thu Jul 27 12:23:35 2017
From: rajesh.solaris10 at gmail.com (Rajesh Gaddam)
Date: Thu, 27 Jul 2017 15:53:35 +0530
Subject: Required gnupg installation steps and pre reqest
In-Reply-To: <CAKU8amnO-ws3PXw6htnKhKCA+XO2uCU=9Q1hxdeuAG5djUAPXg@mail.gmail.com>
References: <CAKU8amkNHPcG1X680nqbST-0jhKTebUbmDfxtjF94CxoVDH20g@mail.gmail.com>
 <CAKU8ammA+O1wP_UZx2T7DzXRGE2HnGOEUE79w4Aku0g5jqMPsA@mail.gmail.com>
 <CAKU8ammE8y7ah0FSA+ZvbWOTnLB0hZOy=LjbX1TO3unOvCmVpQ@mail.gmail.com>
 <CAKU8amnO-ws3PXw6htnKhKCA+XO2uCU=9Q1hxdeuAG5djUAPXg@mail.gmail.com>
Message-ID: <CAKU8ammmdBGfW=1AqBOwLWgSN0YumyJPL-J_XDkEncw9EYkW9g@mail.gmail.com>

Hi team,

Could you please send me the  gnupg-2.1.21 installation steps by using
librarys   solaris10 and rhel6&7 I am not able access gnupg http from Unix
server because of proxy so downloaded all libs and gnupg pkg ,
Rajesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170727/22636757/attachment.html>

From rjh at sixdemonbag.org  Fri Jul 28 08:44:55 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 28 Jul 2017 02:44:55 -0400
Subject: Invalid Crypto Error
In-Reply-To: <ed927bd4eadf47119da8342bd86ca277@Y0032RM.rd1.rf1>
References: <ed927bd4eadf47119da8342bd86ca277@Y0032RM.rd1.rf1>
Message-ID: <c299d23e-0e19-8198-38ea-db8eb07b00fa@sixdemonbag.org>

> I have to use GPG for windows.For that i have installed GPG4Win in my
> system and try to use it through C++ code using DLL libgpgme-glib-11.
> Getting "Invalid crytpto Engine" while calling "gpgme_engine_check_version".

Where are you getting libgpgme-glib-11.dll?  My copy of GnuPG provides
these libraries and executable for using GPGME.  Note that all of them
must be present in the same directory as your executable.

* gpgme-w32spawn.exe
* libassuan-0.dll
* libgpg-error-0.dll
* libgpgme-11.dll

Check that you have all the DLLs, and the supporting gpgme-w32spawn.exe
executable.


From wk at gnupg.org  Fri Jul 28 21:03:02 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Jul 2017 21:03:02 +0200
Subject: [Announce] GnuPG 2.1.22 released
Message-ID: <87a83o4c61.fsf@wheatstone.g10code.de>

Hello!

The GnuPG team is pleased to announce the availability of a new release
of GnuPG: version 2.1.22.  See below for a list of new features and bug
fixes.


About GnuPG
=============

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  A wealth of frontend applications
and libraries making use of GnuPG are available.  As an Universal Crypto
Engine GnuPG provides support for S/MIME and Secure Shell in addition to
OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.1.22
====================================

  * gpg: Extend command --quick-set-expire to allow for setting the
    expiration time of subkeys.

  * gpg: By default try to repair keys during import.  New sub-option
    no-repair-keys for --import-options.

  * gpg,gpgsm: Improved checking and reporting of DE-VS compliance.

  * gpg: New options --key-origin and --with-key-origin.  Store the
    time of the last key update from keyservers, WKD, or DANE.

  * agent: New option --ssh-fingerprint-digest.

  * dimngr: Lower timeouts on keyserver connection attempts and made
    it configurable.

  * dirmngr: Tor will now automatically be detected and used.  The
    option --no-use-tor disables Tor detection.

  * dirmngr: Now detects a changed /etc/resolv.conf.

  * agent,dirmngr: Initiate shutdown on removal of the GnuPG home
    directory.

  * gpg: Avoid caching passphrase for failed symmetric encryption.

  * agent: Support for unprotected ssh keys.

  * dirmngr: Fixed name resolving on systems using only v6
    nameservers.

  * dirmngr: Allow the use of TLS over http proxies.

  * w32: Change directory of the daemons after startup.

  * wks: New man pages for client and server.


A detailed description of the changes found in this 2.1 branch can be
found at <https://gnupg.org/faq/whats-new-in-2.1.html>.


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.1.22 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.22.tar.bz2 (6377k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.22.tar.bz2.sig

or via FTP:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.22.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.22.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.22_20170728.exe (3792k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.22_20170728.exe.sig

or via FTP:

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.22_20170728.exe
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.22_20170728.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  The Windows installer comes with
TOFU support, many translations, support for Tor, and support for HKPS
and the Web Key Directory.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.1.22.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.22.tar.bz2.sig gnupg-2.1.23.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.22.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.22.tar.bz2

   and check that the output matches the next line:

706b806f7d8d328b4ffa67954c613fdd3dfed1b9  gnupg-2.1.22.tar.bz2
9e517a550da5619445be6820a614faf3e1bb5a46  gnupg-w32-2.1.22_20170728.exe
c14b7ad4c03707438e7329de3f2dbf99e2f85dc7  gnupg-w32-2.1.22_20170728.tar.xz


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
French, German, Japanese, Norwegian, Russian, and Ukrainian being almost
completely translated.  We are now in string freeze for 2.2 and updated
translations are very welcome.


Documentation
=============

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available as are the manual.  It is also possible to read the
complete manual online in HTML format at

  https://gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

You may also want to follow our postings at <https://gnupg.org/blob/>
and <https://twitter.com/gnupg>.


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  If you need commercial
support check out <https://gnupg.org/service.html>.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.

Maintenance and development of GnuPG is mostly financed by donations.
The GnuPG project employs 4 full-time developers, one part-timer, and
one contractor.  They all work exclusivly on GnuPG and closely related
software like Libgcrypt, GPGME, and GPA.  Please consider to donate via:

                  https://gnupg.org/donate/


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, answering questions on the mailing
lists, and donating money.


Happy hacking,

   Your GnuPG Team


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users'at'gnupg.org mailing list.

p.p.s
List of Release Signing Keys:

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these five keys:

  2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

  rsa3072/4B092E28 2017-03-17 [expires: 2027-03-15]
  Key fingerprint = 5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

You may retrieve these keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9 BCEF7E294B092E28

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20170728/c2589dc1/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From 2014-667rhzu3dc-lists-groups at riseup.net  Sat Jul 29 15:58:09 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sat, 29 Jul 2017 14:58:09 +0100
Subject: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG
 2.1.22)
Message-ID: <1783960517.20170729145809@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


I have installed the W32 package for GnuPG 2.1.22 and I find keys
cannot be sent to keyservers, or fetched/refreshed. The operation
fails with the message "keyserver send failed: Resource temporarily
unavailable".

In the event the dirmngr from 2.1.21 is already running, the operation
succeeds.



[path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
gpg: using character set 'utf-8'
gpg: no running Dirmngr - starting
'[path_to]\GnuPG_2_1_22\bin\dirmngr.exe'

gpg: waiting for the dirmngr to come up ... (5s)
gpg: waiting for the dirmngr to come up ... (4s)
gpg: connection to the dirmngr established
gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
- --allow-non-selfsigned-uid

gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: keyserver send failed: Resource temporarily unavailable
gpg: keyserver send failed: Resource temporarily unavailable





Compare with:

[path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
gpg: using character set 'utf-8'
gpg: WARNING: server 'dirmngr' is older than us (2.1.21 < 2.1.22)
gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
- --allow-non-selfsigned-uid

gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked




- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

It's not hard to meet expenses, they're everywhere.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXyUeV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5MMNAQC4QqhxRYa/L8rMfoyfcYDixQOr6uskMoN/bDwdBmPCwwEAtlNVH+dlE5h/
xLesXjjiB8+rU1KK+mSJnhGgFPEFVAqJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXyUkV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8FC0CADAWYNuxXCeEdVIc1L8HC6WZHG/
oUYEyGnPIgFfczjzLgU+fHbpJnzk4PdJZVEhlTqYb3rg+5Wr55UcTStskbmP6tcR
xBBKx+8hk7s9pIH4iCZgbN9DF9oT9ENdFV/ODSBgpI8IVDiE+02DHXaZLQCTjIP2
YOvInshDJheKAq+ZnL4T9BBma3NCvvzoCD61Z+35VuUcxSq8uCjw6vEnMAHGoCdG
sCCSa6X0Ch+becbsWJmkeSoOL7eDE/TVuLBpy85F+O3xlRrcqGxzERAqsXKP34t/
OVt2Q+HUFVfObPnHxG4DUk3nYA3ja+yS1QvwD8z3Bz/WnYb4hGJpikBKuXkT
=yPGQ
-----END PGP SIGNATURE-----



From dirkx at webweaving.org  Sat Jul 29 20:24:07 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sat, 29 Jul 2017 20:24:07 +0200
Subject: (pre)cache password rather than use allow-loopback-pinentry
In-Reply-To: <87zibx92a4.fsf@wheatstone.g10code.de>
References: <6DB92A48-B034-4C9F-9ED8-0C6DBCD0F22D@webweaving.org>
 <87lgni9tid.fsf@wheatstone.g10code.de>
 <D250583A-F961-49BC-8B83-05845238C71C@webweaving.org>
 <4F571CE2-F0CD-4ECA-9312-7E8435D7852C@webweaving.org>
 <878tji9mdx.fsf@wheatstone.g10code.de>
 <E659FFCB-6628-4B76-AC4A-A6BE42272621@webweaving.org>
 <87zibx92a4.fsf@wheatstone.g10code.de>
Message-ID: <25385242-589C-469B-9CF0-7338E73245CF@webweaving.org>

On 21 Jul 2017, at 18:34, Werner Koch <wk at gnupg.org> wrote:
> 
> On Fri, 21 Jul 2017 11:37, dirkx at webweaving.org said:
> 
>> And I really would not mind to be able to refer to subkeys by number -and- fpr; as the fpr of a subkey is a but cumbersome to extract afaik (double ?fingerprint).
> 
> Using the number with the quick commands is not a good idea because
> another process might have changed the keys in the meantime.  For
> --edit-key this is not a problem because you work on a copy and last
> save wins.  So I went with subkey fingerprints:
> 
>  --quick-set-expire fpr expire [*|subfprs]

Works absolutly spendlidly (tested in 2.1.22 on openbsd). And has made things much more robust with smart-card subkeys.

Thanks !

> Since some 2.1 version the fingerprints of the subkeys are always
> included when you do
> 
>  gpg --list-keys --with-colons

Lovely. Is there any way one can suppress the fingerprint of the primary key (as when doing line oriented things; bith the ?sec? and ?ssb? line are followed by structurally identical ?fpr? lines)?

Dw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: </pipermail/attachments/20170729/ba8c541b/attachment.sig>

From cai.0407 at gmail.com  Sun Jul 30 04:41:01 2017
From: cai.0407 at gmail.com (Kosuke Kaizuka)
Date: Sun, 30 Jul 2017 11:41:01 +0900
Subject: Dirmngr fails to communicate with keyservers (W32 binaries for
 GnuPG 2.1.22)
In-Reply-To: <1783960517.20170729145809@riseup.net>
References: <1783960517.20170729145809@riseup.net>
Message-ID: <fe0e4b34-2fe8-9819-e1de-15abc41a3bf0@gmail.com>

On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
> I have installed the W32 package for GnuPG 2.1.22 and I find keys
> cannot be sent to keyservers, or fetched/refreshed. The operation
> fails with the message "keyserver send failed: Resource temporarily
> unavailable".
> 
> In the event the dirmngr from 2.1.21 is already running, the operation
> succeeds.
> 
> 
> 
> [path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
> gpg: using character set 'utf-8'
> gpg: no running Dirmngr - starting
> '[path_to]\GnuPG_2_1_22\bin\dirmngr.exe'
> 
> gpg: waiting for the dirmngr to come up ... (5s)
> gpg: waiting for the dirmngr to come up ... (4s)
> gpg: connection to the dirmngr established
> gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
> --allow-non-selfsigned-uid
> 
> gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: keyserver send failed: Resource temporarily unavailable
> gpg: keyserver send failed: Resource temporarily unavailable
> 
> 
> 
> 
> 
> Compare with:
> 
> [path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
> gpg: using character set 'utf-8'
> gpg: WARNING: server 'dirmngr' is older than us (2.1.21 < 2.1.22)
> gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
> --allow-non-selfsigned-uid
> 
> gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked

Same issue with gpg 2.1.22 on Win7 x64.

I've tried search, send-keys and recv-keys commands but all failed with
"Resource temporarily unavailable" messages.

gpg 2.1.21 works fine.

-- 
Kosuke Kaizuka <cai.0407 at gmail.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170730/6556eeb2/attachment.sig>

From dirkx at webweaving.org  Sun Jul 30 12:39:34 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sun, 30 Jul 2017 12:39:34 +0200
Subject: gpgsm, keygrip
Message-ID: <02E40C08-434F-4080-AC5C-D1610E92CEFE@webweaving.org>

Tools such as 

	gpg-preset-passphrase 

require the 40 character keygrip. The manpage of gpg-preset-passphrase(1) suggest that this is best extracted from 

	gpgsm

and that works nicely

 gpgsm --dump-secret-key | grep keygrip:
      keygrip: 1234567890123456789012345678901234567890

however a 'nice to parse' version of that:

	gpgsm --dump-secret-key --with-colons

does not seem to emit the keygrip.

Any way of rectifying that - or another place to get the keygrip in a robust parsable format ?

Dw.



From dirkx at webweaving.org  Sun Jul 30 14:52:14 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sun, 30 Jul 2017 14:52:14 +0200
Subject: gpgsm, keygrip
In-Reply-To: <02E40C08-434F-4080-AC5C-D1610E92CEFE@webweaving.org>
References: <02E40C08-434F-4080-AC5C-D1610E92CEFE@webweaving.org>
Message-ID: <72263B41-F746-4469-B292-D49A1095BF41@webweaving.org>


> On 30 Jul 2017, at 12:39, Dirk-Willem van Gulik <dirkx at webweaving.org> wrote:
> 
> Tools such as 
> 
> 	gpg-preset-passphrase 
> 
> require the 40 character keygrip. The manpage of gpg-preset-passphrase(1) suggest that this is best extracted from 
> 
> 	gpgsm
> 
> and that works nicely
> 
> gpgsm --dump-secret-key | grep keygrip:
>      keygrip: 1234567890123456789012345678901234567890
> 
> however a 'nice to parse' version of that:
> 
> 	gpgsm --dump-secret-key --with-colons
> 
> does not seem to emit the keygrip.
> 
> Any way of rectifying that - or another place to get the keygrip in a robust parsable format ?

Replying to my own question ? the man page of of gpg-preset-passphrase  should perhaps suggest to use ?gpg ?with-keygrip ..? or ?gpg ?with-colons ..?.

Dw.

From dirkx at webweaving.org  Sun Jul 30 15:26:33 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sun, 30 Jul 2017 15:26:33 +0200
Subject: caching of keys (passwords) during signing v.s. during
 --quick-add-subkey.
Message-ID: <ACD3D50B-BF3F-4717-A314-AD75BC6E3EF5@webweaving.org>


When I pre-cache a password of a fresh key:
	 

	# Generate key
	gpg2 --batch --passphrase foo --quick-generate-key test at test.com rsa4096 sign 5

	.. extract keygrip of just regenated keys...

	# Precache password for next operations:
	gpg-preset-passphrase  --preset -P foo 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7 
	
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 <- PRESET_PASSPHRASE 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7 -1 666F6F
		2017-07-30 09:12:51 gpg-agent[10565] DBG: agent_put_cache '6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7' (mode 1) requested ttl=-1
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 -> OK

I find that this works spendidly on a normal sign operations
	
	echo foo | gpg2  --sign --armour

		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 <- HAVEKEY 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 -> OK
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 <- KEYINFO 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7
		2017-07-30 09:12:51 gpg-agent[10565] DBG: agent_get_cache '6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7' (mode 2) ...
		2017-07-30 09:12:51 gpg-agent[10565] DBG: ... hit
		?.
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_10 <- SETKEYDESC Please+enter?.
		?
		2017-07-30 09:12:51 gpg-agent[10565] DBG: agent_get_cache '6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7' (mode 2) ... 

but fails on a quick-key-add:

	gpg2  --batch --quick-add-key B447C69E35DF57D7691AA4B6B98648C42890DF09 rsa4096 sign 2 

	
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 <- KEYINFO 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7
		2017-07-30 09:12:51 gpg-agent[10565] DBG: agent_get_cache '6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7' (mode 2) ...
		2017-07-30 09:12:51 gpg-agent[10565] DBG: ... hit
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 -> S KEYINFO 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7 D - - 1 P - - -
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 -> OK
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 <- SETKEYDESC Please+enter+?..
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 -> OK
		2017-07-30 09:12:51 gpg-agent[10565] DBG: chan_14 <- PASSWD  --verify 6E81A32570329F1FB5A24106B2E0F3C0CC4B3FD7
		2017-07-30 09:12:51 gpg-agent[10565] starting a new PIN Entry 

Which then goes into the usual pinentry sequence (which completes fine when given the password).

The gpg-agent.conf has longish TTLs and lax settings:

	allow-preset-passphrase
	default-cache-ttl 300
	max-cache-ttl 300

Is there any setting that needs to be added to allow the ?special? sort of sign case ?

With kind regards.

Dw.

#!/bin/sh
set -e
set -x

TMPDIR=${TMPDIR:-/tmp}
VOLNAME=${VOLNAME:-gnupg.tmp.$$}
TMPSTORE=${TMPDIR}/${VOLNAME}
GNUPGHOME=/Volumes/${VOLNAME}
PASSWD='foo'

PGP=/usr/local/bin/gpg2
SM=/usr/local/bin/gpgsm
PRESET=/usr/local/libexec/gpg-preset-passphrase

SIZE=5M


export DAYS=5
export SUBDAYS=2

# Use an emphemeral disk if we can.
#
if test -f /usr/bin/hdiutil; then
	export RANDFILE=~/.openssl.rand.state
	openssl rand -base64 128 |\
       		/usr/bin/hdiutil hdiutil create -attach -stdinpass -quiet \
       		-encryption -size $SIZE -fs HFS+ \
       		-volname ${VOLNAME} ${TMPSTORE} 
	rm -f ${TMPSTORE}.dmg
else
	GNUPGHOME=${TMPSTORE}
	mkdir -p ${GNUPGHOME}
	chmod 700 ${GNUPGHOME}
fi


(
export GNUPGHOME 

cat > ${GNUPGHOME}/gpg-agent.conf <<EOM

# Bit annoying we need this - despite no user interaction.
pinentry-program /usr/bin/pinentry-curses

debug-quick-random
allow-preset-passphrase
default-cache-ttl 300
max-cache-ttl 300
# batch

debug-level guru
log-file /tmp/sc.log
EOM

${PGP} --verbose --homedir ${GNUPGHOME} \
	--batch --passphrase "${PASSWD}" \
	--quick-generate-key \
	test at test.com rsa4096 sign ${DAYS}

IFS=:
set $( ${PGP} --homedir ${GNUPGHOME} --list-secret-keys --with-colons | grep ^fpr: )

FPR=${10}
LEN=$(/bin/echo -n $FPR | wc -c)
if [ $LEN -ne 40 ]; then
	echo Generation failed, FPR not 40 bytes.
	exit 1
fi

# gpg-preset-passphrase
# set $(${SM} --homedir ${GNUPGHOME} --dump-secret-key | grep keygrip:)
# KEYGRIP=${2}

# set $( gpg-connect-agent --homedir ${GNUPGHOME} 'keyinfo --list' /bye | head -1 )
# KEYGRIP=${3}

set $( ${PGP} --homedir ${GNUPGHOME} --with-keygrip --list-secret-keys --with-colons | grep ^grp: )
KEYGRIP=${10}
${PRESET} --homedir ${GNUPGHOME} --preset -P "${PASSWD}" ${KEYGRIP} 

# Chehck that siging forks.
i#
echo foo | ${PGP} --homedir ${GNUPGHOME} --sign --armour 

${PGP} --homedir ${GNUPGHOME} \
       --batch  \
       --quick-add-key \
	$FPR rsa4096 sign $SUBDAYS

${PGP} --homedir ${GNUPGHOME} \
       --batch \
       --quick-add-key \
	$FPR rsa4096 encr $SUBDAYS

${PGP} --homedir ${GNUPGHOME} \
       --batch \
       --quick-add-key \
	$FPR rsa4096 auth $SUBDAYS

${PGP} --homedir ${GNUPGHOME} \
	--verbose --list-secret-keys --with-fingerprint --with-fingerprint

? lots of validation stuff snipped ?.

)
E=$?

gpgconf --kill gpg-agent
gpgconf --kill scdaemon
gpgconf --kill dirmngr

if test -f /usr/bin/hdiutil; then
	hdiutil unmount -force ${GNUPGHOME}
else
	rm -rf ${GNUPGHOME}
fi

exit $E



From dirkx at webweaving.org  Sun Jul 30 19:29:29 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sun, 30 Jul 2017 19:29:29 +0200
Subject: Scripted reset of PINs on smartcards.
Message-ID: <E88B079C-309C-431A-B210-BE860475D267@webweaving.org>

Am I right in understanding that, unless one wants to get into chat-expect and a fair bit of state logic behind a `fake? pinentry ? one cannot easily edit the PINs on a (fresh) smartcard by piping in a command sequence?

And in order to do so - does one really have to talk to the scdaemon directly ? Or is there a way to pass the (binary) PINs? through a normal gpg-connect-agent channel (with the SCD prefix) ?

Dw.

#!/bin/sh

# Factory default
OLDMASTER=12345678

NEWMASTER=${MASTER:-87654321}
NEWPIN=${PIN:-654321}
NEWRESET=${RESET:-010101}

# Reset the OpenPGP applet on the card.
#
cat <<EOM | gpg-connect-agent
/hex
scd serialno
??..snipped ?..
scd apdu 00 44 00 00
EOM

# Set the PINs to non-factory defaults.
#
(
	echo PASSWD 3
	((echo -n D $OLDMASTER; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END
	((echo -n D $NEWMASTER; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END

	echo PASSWD --reset 1
	((echo -n D $NEWMASTER; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END
	((echo -n D $NEWPIN; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END

	echo PASSWD --reset 2
	((echo -n D $NEWMASTER; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END
	((echo -n D $NEWRESET; dd bs=1 count=90 if=/dev/zero status=none) | dd bs=1 count=90 status=none; echo ) | dd status=none
	echo END

	??..snipped ?..
	echo BYE
) |  nc -U  $XXXX/S.scdaemon 



From dirkx at webweaving.org  Sun Jul 30 22:19:22 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Sun, 30 Jul 2017 22:19:22 +0200
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
Message-ID: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>

I see a growing number of keys that have well managed & expired separate subkeys for Signing, Encryption and Authentication switch from ?SC? on the master key to just ?C? (all RSA, ignoring DSA).

Would anyone know if there is some documented best practice ?

Dw

From andrewg at andrewg.com  Mon Jul 31 00:37:05 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 30 Jul 2017 23:37:05 +0100
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
Message-ID: <AC9CE712-5557-4446-919F-6DBC63FCD7B8@andrewg.com>


> On 30 Jul 2017, at 21:19, Dirk-Willem van Gulik <dirkx at webweaving.org> wrote:
> 
> I see a growing number of keys that have well managed & expired separate subkeys for Signing, Encryption and Authentication switch from ?SC? on the master key to just ?C? (all RSA, ignoring DSA).
> 
> Would anyone know if there is some documented best practice ?

I don't think it particularly matters if you have both an S primary and an S subkey. I can't think of any use case where it would be a problem (although I'm sure now I've said it someone will correct me). 

What I have found problematic myself is having an A primary and an A subkey. This is because my primary is offline and I use smartcards for my subkeys, and there exist some applications which only accept one auth key. There have been times when I have mixed up my online and offline A pubkeys, which is not a security issue, but is a usability one.

So I personally would not recommend having more than one valid A (sub)key at any one time - purely for your own sanity. 

A


From rjh at sixdemonbag.org  Mon Jul 31 00:46:54 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 30 Jul 2017 18:46:54 -0400
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
Message-ID: <6ba4f9fb-8109-a1ef-986b-e38f6077ac02@sixdemonbag.org>

> Would anyone know if there is some documented best practice ?

The standard advice applies: stick with the defaults.


From aheinecke at intevation.de  Mon Jul 31 10:35:24 2017
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 31 Jul 2017 10:35:24 +0200
Subject: Dirmngr fails to communicate with keyservers (W32 binaries for
 GnuPG 2.1.22)
In-Reply-To: <fe0e4b34-2fe8-9819-e1de-15abc41a3bf0@gmail.com>
References: <1783960517.20170729145809@riseup.net>
 <fe0e4b34-2fe8-9819-e1de-15abc41a3bf0@gmail.com>
Message-ID: <1989502.Z2ZSEliuAJ@esus>

Hi,

On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote:
> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
> > I have installed the W32 package for GnuPG 2.1.22 and I find keys
> > cannot be sent to keyservers, or fetched/refreshed. The operation
> > fails with the message "keyserver send failed: Resource temporarily
> > unavailable".
> > 
> > In the event the dirmngr from 2.1.21 is already running, the operation
> > succeeds.

Yes, slipped our testing. We are working on it:

https://dev.gnupg.org/T3318

Regards,
Andre
-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20170731/35c94b48/attachment.sig>

From marfig at gmx.com  Mon Jul 31 16:44:52 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Mon, 31 Jul 2017 15:44:52 +0100
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
Message-ID: <20170731154452.37ce66c2@Archbox>

On Sun, 30 Jul 2017 22:19:22 +0200
Dirk-Willem van Gulik <dirkx at webweaving.org> wrote:

> I see a growing number of keys that have well managed & expired
> separate subkeys for Signing, Encryption and Authentication switch
> from ?SC? on the master key to just ?C? (all RSA, ignoring DSA).
> 
> Would anyone know if there is some documented best practice ?

Could probably be a direct application of this Debian article (1) on
subkeys. And meant to to facilitate the recovery of the web of trust in
case of disaster.

On a separate tutorial (2), Alan Eliasen strongly advises against this
practice.


(1) https://wiki.debian.org/Subkeys?action=show&redirect=subkeys
(2) https://futureboy.us/pgp.html#PerfectKeypair

MF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170731/a1ce4838/attachment.sig>

From andrewg at andrewg.com  Mon Jul 31 17:28:27 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 31 Jul 2017 16:28:27 +0100
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <20170731154452.37ce66c2@Archbox>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
Message-ID: <b91e7bac-59b3-684f-3f45-726794615cd1@andrewg.com>

On 2017/07/31 15:44, Mario Figueiredo wrote:
> On a separate tutorial (2), Alan Eliasen strongly advises against 
> this practice.

He does, but his argument is weak. The meat of it is:

> Unless everyone that you communicate with regularly does something 
> like:
> 
> gpg --refresh-keys
> 
> to find out that keys have been revoked, they may never even know 
> that you revoked the signing key, and they will continue to trust 
> your signature.
> 
> If the person who stole your laptop (and thus your secret keys) could
> ever impersonate you (because they guessed the password for your
> secret key), then they can forever decrypt all the communications
> sent to you with that same key if you follow the "perfect keypair"
> advice.
> 
> Allowing your attacker to read your encrypted communications forever,
> and pretending it didn't happen, is extremely bad and wrong 
> cryptographic practice, obviously. If your decryption key is stolen,
> revoke that entire keypair and never use any part of it again!
> Otherwise, your attacker can forever read messages encrypted to your
> public key.

There are two enormous holes in this argument:

1. If the people you communicate with regularly don't do "gpg
--refresh-keys" regularly they won't find out whether *anything* has
*ever* been revoked. So they will continue to trust your bad signature
regardless of whether you're using a subkey, a primary key, a wax seal,
thumbprints in blood, whatever. This is a completely separate argument.

2. He seems to be operating under the impression that encryption subkeys
can't be individually revoked, which is complete nonsense. And no matter
what you do after your encryption key is compromised, yes of course all
your past communications using that key are still readable by the
attacker. But again, that's the case with or without subkeys.

And of course he overlooks the strongest argument in favour of using
subkeys, and that's so you can put them on a hardware token and not have
to store them on your laptop at all.

The only bit where he has (half) a point is that it may be a good idea
to revoke your entire key because it is noisy, and therefore more likely
to be noticed (and your compromise paid due attention to) than if you
simply rolled your subkeys. But so long as your passphrase is good, it
shouldn't matter whether an attacker has a copy of your encrypted
privkey (see: RJH's NYT small ads offer) and rolling your subkeys is a
precaution against your passphrase having been keylogged at some point
prior to losing your laptop (remembering of course that if your laptop
had malware, it's Game Over anyway).

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170731/fc9ed19c/attachment.sig>

From rjh at sixdemonbag.org  Mon Jul 31 17:41:58 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 31 Jul 2017 11:41:58 -0400
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <20170731154452.37ce66c2@Archbox>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
Message-ID: <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>

> Could probably be a direct application of this Debian article (1) on
> subkeys. And meant to to facilitate the recovery of the web of trust in
> case of disaster.
> 
> On a separate tutorial (2), Alan Eliasen strongly advises against this
> practice.

I hate to say something bad about a tutorial someone put so much obvious
love into, but most of these tutorials are _just plain bad_.  And even
the good ones, I don't recommend.

A newcomer to GnuPG needs to be told the defaults are safe for the vast
majority of users, that GnuPG does not require any special tuning before
use, and that the developers chose the defaults very carefully to be
applicable to the vast majority of users.

Debian may have specific needs which GnuPG does not meet in its default
configuration.  So if Debian wants to put together a tutorial teaching
people how to configure GnuPG in a way that meets the Debian developer
needs, I'm all in favor of that -- but I wince every time I see a
newcomer to GnuPG think that process is somehow necessary for them to
follow.  It's not.  Use the defaults until and unless you can articulate
a specific and compelling reason to deviate from them.


From dirkx at webweaving.org  Mon Jul 31 17:49:00 2017
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Mon, 31 Jul 2017 17:49:00 +0200
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
 <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>
Message-ID: <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>


> On 31 Jul 2017, at 17:41, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> Could probably be a direct application of this Debian article (1) on
>> subkeys. And meant to to facilitate the recovery of the web of trust in
>> case of disaster.
>> 
>> On a separate tutorial (2), Alan Eliasen strongly advises against this
>> practice.
> 
> I hate to say something bad about a tutorial someone put so much obvious
> love into, but most of these tutorials are _just plain bad_.  And even
> the good ones, I don't recommend.
> 
> A newcomer to GnuPG needs to be told the defaults are safe for the vast
> majority of users, that GnuPG does not require any special tuning before
> use, and that the developers chose the defaults very carefully to be
> applicable to the vast majority of users.
> 
> Debian may have specific needs which GnuPG does not meet in its default
> configuration.  So if Debian wants to put together a tutorial teaching
> people how to configure GnuPG in a way that meets the Debian developer
> needs, I'm all in favor of that -- but I wince every time I see a
> newcomer to GnuPG think that process is somehow necessary for them to
> follow.  It's not.  Use the defaults until and unless you can articulate
> a specific and compelling reason to deviate from them.

For what it is worth - the various best practices at `riseup.net?[1] seem to strike a good middle ground.

This was also were my question came form; while historically (given DSA & patents of that time) it made sense to have S or SC on the master key ? the contemporary use seems to be mainly ?C?.

So one could surmise that the historic default of SC for a non DSA (e.g. RSA or ECC) is a bit out of date.

Hence the question as to what good practice is today.

Dw.

1: https://riseup.net/en/security/message-security/openpgp/best-practices <https://riseup.net/en/security/message-security/openpgp/best-practices> et.al.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170731/c37551b8/attachment-0001.html>

From marfig at gmx.com  Mon Jul 31 17:51:11 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Mon, 31 Jul 2017 16:51:11 +0100
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <20170731154452.37ce66c2@Archbox>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
Message-ID: <20170731165111.05296723@Archbox>

On Mon, 31 Jul 2017 15:44:52 +0100
Mario Figueiredo <marfig at gmx.com> wrote:

> On a separate tutorial (2), Alan Eliasen strongly advises against this
> practice.

I'm replying to my own post, because the above seem a little like I'm
trying to make an argument from authority. That was not my intention.
It's just poorly worded.

Read it as "The author of a separate tutorial advises against this
practice".

MF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170731/375f9e50/attachment.sig>

From peter at digitalbrains.com  Mon Jul 31 18:34:30 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 31 Jul 2017 18:34:30 +0200
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
 <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>
 <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>
Message-ID: <d7134eb3-84c2-9d84-85d1-4a46b505b163@digitalbrains.com>

On 31/07/17 17:49, Dirk-Willem van Gulik wrote:
> For what it is worth - the various best practices at `riseup.net
> <http://riseup.net>?[1] seem to strike a good middle ground.

IMO, the good middle ground is the defaults. A wide middle. Maybe more a
country than a ground ;-). And I wasn't very impressed last time I read
the riseup.net article.

I wholeheartedly agree with "Use the defaults until and unless you can
articulate a specific and compelling reason to deviate from them."

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: </pipermail/attachments/20170731/13a28456/attachment.sig>

From dgouttegattat at incenp.org  Mon Jul 31 18:38:09 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 31 Jul 2017 18:38:09 +0200
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
 <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>
 <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>
Message-ID: <f43f43d6-ce9f-dac5-dc42-845cb617e70e@incenp.org>

On 07/31/2017 05:49 PM, Dirk-Willem van Gulik wrote:
> For what it is worth - the various best practices at `riseup.net?[1] seem to strike a good middle ground.

For what it is worth, I disagree.

The main problem I have with that document is that it implies the user 
should care about a lot of details that he actually should not have to 
care about, especially with a decently recent GnuPG version.

Specifically:

* Starting from GnuPG 2.1.16, the user has nothing to do to use the SKS 
keyserver pool, that's already the default. There's no need to manually 
download the CA certificate for the pool, either, because it is now 
included directly in GnuPG.

* There is no need to "ensure that all keys are refreshed through the 
keyserver you have selected"--the honor-keyserver-url option is already 
disabled by default.

* There is no need to generate a revocation certificate. GnuPG already 
does that when you create a new keypair. You need to do it yourself only 
if you generated your key some years ago, before automatic generation of 
revocation certificates was implemented (i.e. before GnuPG 2.1).

* There is no nothing to do to "have a separate subkey for encryption". 
When creating a new keypair, GnuPG automatically creates a primary key 
for signing and certifying, *and* a subkey for encryption. (I do not 
remember when GnuPG started to do that, but I am pretty sure this is not 
new at all.)

* Unless you generated your key a long time ago, you absolutely do not 
have to "make sure your key is OpenPGPv4". No recent or even 
not-so-recent version of GnuPG will ever generate a v3 key.

* Likewise, there is no need to check that self-signatures do not use 
MD5, unless your keys are *very old*.

* Likewise for SHA-1. I think GnuPG stopped using SHA-1 as the default 
hash algorithm sometimes in 2009.

So all of those advices could be replaced by a single one: "Use a recent 
GnuPG version. Ideally, use the most recent version available. At the 
very least, do not use a decade-old version."

The problem with recommanding unnecessary steps is that they will 
confuse the beginner and make him think that GnuPG is more difficult to 
use than it already is.

Damien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170731/a1da8aad/attachment.sig>

From rjh at sixdemonbag.org  Mon Jul 31 18:52:58 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 31 Jul 2017 12:52:58 -0400
Subject: 3DES deprecated by NIST
Message-ID: <734016ad-bcf4-5a67-0b12-cc20c6f65012@sixdemonbag.org>

For many years I've been saying that 3DES is a much stronger algorithm
than its detractors think, subject to some massive concerns about its
64-bit block size and the near-certainty of a block repeating after
about 32Gb of traffic (2**32 blocks, 8 bytes per block).  This isn't to
say I've been advocating 3DES: we certainly should be moving to AES, but
the fearmongering over 3DES has been -- IMO -- counterproductive.

Well, NIST has recently lowered its estimate of 3DES's safety.  Their
guidance now says a single 3DES key shouldn't be used for more than 8Mb
of traffic.  If previously we were moving to AES and away from 3DES
because the fire alarm went off, this would be the smell of smoke in the
air.

If you're still using 3DES, please migrate to AES immediately.  Until
you do, make sure to follow NIST's guidance.

https://beta.csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA


From marfig at gmx.com  Mon Jul 31 20:01:38 2017
From: marfig at gmx.com (Mario Figueiredo)
Date: Mon, 31 Jul 2017 19:01:38 +0100
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <f43f43d6-ce9f-dac5-dc42-845cb617e70e@incenp.org>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
 <82e952ba-a115-800c-223f-895a11a8f6e8@sixdemonbag.org>
 <469A1104-353E-4988-9536-EE64B166A319@webweaving.org>
 <f43f43d6-ce9f-dac5-dc42-845cb617e70e@incenp.org>
Message-ID: <20170731190138.3a6b7116@Archbox>

On Mon, 31 Jul 2017 18:38:09 +0200
Damien Goutte-Gattat <dgouttegattat at incenp.org> wrote:

> The problem with recommanding unnecessary steps is that they will 
> confuse the beginner and make him think that GnuPG is more difficult
> to use than it already is.

Which essentially describes my whole first impressions of GnuPG until I
finally decided to read the official documentation. Particularly the
GNU Privacy Handbook and the Mini HowTo. 

MF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170731/af48f05d/attachment.sig>

From gabri.philippe at gmail.com  Mon Jul 31 23:11:16 2017
From: gabri.philippe at gmail.com (Gabriel Philippe)
Date: Mon, 31 Jul 2017 23:11:16 +0200
Subject: 'sign (and cert)' or just 'cert' on a master key with subkeus
In-Reply-To: <b91e7bac-59b3-684f-3f45-726794615cd1@andrewg.com>
References: <52DC46AB-5B35-44FC-A818-159BBFB513BB@webweaving.org>
 <20170731154452.37ce66c2@Archbox>
 <b91e7bac-59b3-684f-3f45-726794615cd1@andrewg.com>
Message-ID: <CAJ-6NAtde3Hhkzu0d-zGo0wPmyxpnNGX+fjyTBCkxwNvzMnGhA@mail.gmail.com>

On Mon, Jul 31, 2017 at 5:28 PM, Andrew Gallagher <andrewg at andrewg.com> wrote:
> There are two enormous holes in this argument:
>
> 1. If the people you communicate with regularly don't do "gpg
> --refresh-keys" regularly they won't find out whether *anything* has
> *ever* been revoked.

A good practice is to define close expiration dates for keys and
subkeys, and regularly postpone them (or renew subkeys), which is only
possible with the "master" offline key and not with the possibly
compromised subkeys. This forces those people who never refresh keys
to do it, or complain, or for most of them abandon PGP because they
get painful warnings and this stupid thing does not work.

Furthermore, if you start sending messages signed with a new subkey,
people who have not refreshed your key will get error messages,
hopefully refresh the key (or complain or abandon PGP), and get both
the revocation certificates and the new subkeys. Without even having
to understand what happens.

Definitely, having different keys for signing and certifying looks OK to me.


> But so long as your passphrase is good, it
> shouldn't matter whether an attacker has a copy of your encrypted
> privkey

I prefer having an easy to type (and weak) passphrase, and rely on
full disk encryption with a big, big passphrase I only type once in a
while. Am I wrong?

Strange tuto... Using a laptop, caring about security (which is
deduced from the use of PGP), and not considering having the storage
memory encrypted.

-- 
Gabriel