Re: SmartCard v2.1 : factory reset fails

[NIIBE Yutaka]

Hello,

Since I got 2.1 card last week, I will test with it.  For time being,
I say something what I know of.

Fib Moro  wrote:
> I can then successfully change the PIN as well as AdminPIN.
>
> However, when I try to write a key to the card (gpg --edit-key xxx; 
> keytocard) I
> get a message "Error setting the Reset Code: Bad PIN".

Umm... This error message can be only happened at setting the Reset
Code.  Strange.

> The same issue occurs when try set a Reset Code on the card (gpg --card-edit;
> admin; passwd => set the Reset Code).

The length of the Reset Code should be more than or equals to 8.  If it
is shorter, it fails.  What is your case?
-- 

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

Re: Questions about --throw-keyids

[Bjarni Runar Einarsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Kahn Gillmor  wrote:
> 
> You don't get the luxury to decide on this transition yourself,
> i'm afraid. Mailpile has to deal with *other* MUAs doing
> throw-keyids, just like those other MUAs have to deal with it
> if/when Mailpile starts doing it :/

Of course! But I can't solve everything at once - today I feel I
can quite reasonably punt on this and say "it's too hard for now,
future versions will deal with it better."

I can't really say that anymore if Mailpile itself is generating
such content itself. :-)

 - B

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJYolIZAAoJEI4ANxYAz5SRLiUH/A6ReWbEvSHdx1+1eAWiYJy8
lPMeOsedzaDxXEAVonQMpeV5H2YmFekx297gVEtbEIyHgbxy/gY7KV8rU3ejDGYZ
KCe7lsUcsqoNzeyF1EyGYQazGwzFBbRd4R7x8AUk9LoV7Bqqi1ONwbzc2+l+mHLR
jcloOscHQ8mLTxk7pTITlmmrBMpatJa+Zsi9Cn43DH9uib0//tb3Wx0rXn5Wr5oA
IMbHAh8MX0yCmnO9L/epGEUMOpV37IYJbQGiZmGU7Q/Mn2Q8zlInv8PFW/VU5YWm
I4m/bHYXjqbsbNqnr4TlsolQoIqacEj8izwg/pL41lWnRpjbgpBOAGZyQGfvJCg=
=yyvO
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about --throw-keyids

[Daniel Kahn Gillmor]

On Mon 2017-02-13 18:35:17 -0500, Bjarni Runar Einarsson wrote:
> Sounds like a nice optimization... but option bloat is a thing too.

for an API, there's nothing wrong with explicitly specifying the thing
that people should *want* to be doing as a separate interface.

GnuPG has some level of difficulty because it's trying to offer both an
API and a user interface.  For this discussion, i think we're pretty
clearly talking about the API, though.

> ... of exactly what you just said. I'm not doing this now (and one of
> my original questions was whether GnuPG uses any such logic itself),
> but if I do start throwing away keyIDs, I'll be exploring strategies
> like this to ensure that at least Mailpile users have a pleasant
> experience.

You don't get the luxury to decide on this transition yourself, i'm
afraid.  Mailpile has to deal with *other* MUAs doing throw-keyids, just
like those other MUAs have to deal with it if/when Mailpile starts doing
it :/

 --dkg

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

Re: Questions about --throw-keyids

[Daniel Kahn Gillmor]

On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote:
>> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor :
>> 
>> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
>>> Step two: Encrypt using gpg --throw-keyids.
>>> 
>>> This is easy on the sender's end, but whether this feature can be
>>> used as a matter of course depends on how it impacts the
>>> experience of the recipient.
>> 
>> It's almost like decryption of messages with hidden keyids and
>> per-decryption passphrase prompting (or even confirmation) are mutually
>> incompatible workflows :/
>
> Just thinking out loud here, but wouldn’t it be sensible for gnupg to have a 
> „silent“ option,
> that only try keys for which a passphrase is cached in gpg-agent?

how about "--try-cached-secrets", by analogy with --try-all-secrets or
--try-secret-key?

I like this idea.

> While a fallback would have to be provided in case no matching key is found,
> it would make it easier for those users that cache their passphrases.
> As fallback gnupg could return the information that no cached passphrase was 
> found,
> allowing the MUA or plugin to then re-try without the option that enables 
> „silent“ checking.

Right, this makes sense.  It's also possible that the combination of the
tool invoking gpg and gpg itself can be cleverer about proposing
candidate keys.  For example, if the PKESK uses RSA, and the value is
4096-bits in size, and the thing being decrypted is an e-mail address
with a certain Date: header and specific addresses in the To: and Cc:
fields, then you could filter secret key material by creation/expiration
dates and User IDs and usage flags and key sizes.  This might also turn
out to mean that of all secret keys held, only one is even remotely
likely, in which case it could just be tried anyway.  You could use the
inbound e-mail address (enclosed in <>s) with --try-secret-key, but i
don't know how you could pass it the hints from the Date headers.

I wonder whether anyone is trying to do anything like this currently.
If so, i'd be happy to hear details about what you've tried and what you
think might be necessary to make it even better.

--dkg


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

SmartCard v2.1 : factory reset fails

[Fib Moro]

Dear GnuPG-Users List.

I'm having trouble with resetting my smartcard version 2.1.

After posting a bug report for GnuPG Werner Koch asked me to re-post my 
question on this mailing list [0].

To answer his quick hint: factory-reset did unfortunately not work as I already 
mentioned in my original request.

Please read more for further details below. Thank you kindly for your support!



I have accidentally blocked my smartcard version 2.1 after entering AdminPIN 3
times with wrong value.

According to the link on my card provider's homepage I tried to follow the
instructions by Werner to reset the card [1].

I then get the state (gpg --card-edit; verify):

===
Reader ...: Gemalto USB Shell Token V2 (78111413) 00 00
Application ID ...: D27600012401020100054684
Version ..: 2.1
Manufacturer .: ZeitControl
Serial number : 
Name of cardholder: [not set]
Language prefs ...: de
Sex ..: unspecified
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key : [none]
Encryption key: [none]
Authentication key: [none]
General key info..: [none]
===

I can then successfully change the PIN as well as AdminPIN.

However, when I try to write a key to the card (gpg --edit-key xxx; keytocard) I
get a message "Error setting the Reset Code: Bad PIN".

The same issue occurs when try set a Reset Code on the card (gpg --card-edit;
admin; passwd => set the Reset Code).

In both cases I am very certain that I'm entering the correct PIN/AdminPIN as I
have also tried to execute the reset process setting different PINs or even
leaving the default PIN values multiple times.

Trying to factory reset from "gpg --card-edit" menu didn't help either.


Is my card bricked? 

Am I doing something wrong?


One thing I noticed is the second 0 in the "PIN retry counter" value after
reset. From [2]:

"This field saves how many tries still are left to enter the right PIN. They are
decremented whenever a wrong PIN is entered. They are reset whenever a correct
AdminPIN is entered. The first and second PIN are for the standard PIN. gpg
makes sure that the two numbers are synchronized. The second PIN is only
required due to peculiarities of the ISO-7816 standard; gpg tries to keep this
PIN in sync with the first PIN. The third PIN represents the retry counter for
the AdminPIN."


My current setup is:


gpg 2.1.15 
ccid 1.4.24 
pcsc-lite 1.8.20 (with udev)



Thank you kindly for your help and feedback.

fibmoro



[0] https://bugs.gnupg.org/gnupg/issue2952
[1] https://lists.gnupg.org/pipermail/gnupg-users/2009-September/037414.html
[2] https://www.gnupg.org/howtos/card-howto/en/ch03.html#id2521300

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

Re: Questions about --throw-keyids

[Lukas Pitschl | GPGTools]

> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor :
> 
> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
>> Step two: Encrypt using gpg --throw-keyids.
>> 
>> This is easy on the sender's end, but whether this feature can be
>> used as a matter of course depends on how it impacts the
>> experience of the recipient.
> 
> It's almost like decryption of messages with hidden keyids and
> per-decryption passphrase prompting (or even confirmation) are mutually
> incompatible workflows :/

Just thinking out loud here, but wouldn’t it be sensible for gnupg to have a 
„silent“ option,
that only try keys for which a passphrase is cached in gpg-agent?
While a fallback would have to be provided in case no matching key is found,
it would make it easier for those users that cache their passphrases.
As fallback gnupg could return the information that no cached passphrase was 
found,
allowing the MUA or plugin to then re-try without the option that enables 
„silent“ checking.

Best,

Lukas


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Questions about --throw-keyids

[Daniel Kahn Gillmor]

On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
> Step two: Encrypt using gpg --throw-keyids.
>
> This is easy on the sender's end, but whether this feature can be
> used as a matter of course depends on how it impacts the
> experience of the recipient.

Agreed that the recipient's side is the tough part of the problem to
crack.

You don't mention gpg's --try-all-secrets, --try-secret-keys, and
--skip-hidden-recipients options, which are all attempts to provide some
guidance to gpg about how to handle these things during decryption.
Maybe you want to read up on those too?

Unfortunately, I have yet to see a functional, non-aggravating workflow
for users who have multiple secret keys who receive encrypted messages
with hidden keyIDs.

It's almost like decryption of messages with hidden keyids and
per-decryption passphrase prompting (or even confirmation) are mutually
incompatible workflows :/

I'd love to be convinced otherwise.

   --dkg


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

Questions about --throw-keyids

[Bjarni Runar Einarsson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

Context: I am trying to figure out how much visible metadata I
can remove from an encrypted e-mail before it becomes completely
unusable.

Step one: stripping stuff from the message headers is relatively
easy; minimal messages with all recipients in BCC are easy to
create (yes, I know the SMTP envelope and SMTP logs still have
the data - this is minimization of metadata, not eliminiation).

Step two: Encrypt using gpg --throw-keyids.

This is easy on the sender's end, but whether this feature can be
used as a matter of course depends on how it impacts the
experience of the recipient. This is where I have some questions
and could use some guidance. Please feel free to correct me if
I've gotten things wrong!

(For those unfamiliar with --throw-keyids: it creates an
encrypted message without any indicators as to which keys it is
encrypted to - so the recipient has to "guess" - in practice
GnuPG will try multiple secret keys until one works or it runs
out of options.)

Using GnuPG 1.4.20 to decrypt, there appears to be a problem
where it only asks for one passphrase even if it is checking many
keys. So the user has to guess which passphrase to provide and
won't be asked again.

Using GnuPG 2.1.11 to decrypt, I do get multiple passphrase
prompts (one per key/subkey), but it doesn't seem to ask me about
expired keys. I am guessing this was a usability trade-off, so
long-time users of GnuPG don't have to answer dozens of
passphrase prompts when decrypting.

My questions:

   * Am I understanding the GnuPG 1.4 behaviour correctly? Is there a 
recommended workaround?
   * Will GnuPG 2.1.11 attempt to decrypt using an expired key if the message 
is old, or will old messages just become (effectively) inaccessible over time 
as keys expire?
   * Are the above behaviours different when using GnuPG non-interactively?
   * Can the caller influence these behaviours in any way? For example, can I 
force GnuPG to only try one specific key so my application can manage the 
experience and experiment with other "guessing" strategies?
   * How does GnuPG 2.0 behave?
   * Roughly when did the behaviour change between 1.4 and 2.1.11?

Thanks in advance for any and all answers. :-)

Cheers,
 - Bjarni

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJYoZuHAAoJEI4ANxYAz5SRFHUH/A/TuJEusZMZ9an3ZFMT61Mi
qLInlvqKkx4JXQ4A7gtwMhgjj4t3YMSq6n/VKzeSjUkGdnXdyJJ5JwxHtymV7ob8
3S+WGvxzipLNe94C/2Vz2OfCjaIjIQ/qjNtY96pSIodEv9/GUug3epzTSvFXQ4A3
4XM471FaI+oVbnJPsetu7Ngwn3TTSWBnO872DL0gHOmvZt9R0QyZ3YTRC3kiKYib
9F2taZ0iRpj4svvNyomiA/itayUJzjq60F5EwsNwzGU3gS3Ue0MZc8GrkVHFgTVo
ZWkygfByM0S31aI6qQkXeJbRsZTLzpgPmqFqtqwieHQLETcaYawuvLUGW7GYh3U=
=wVH1
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: send-keys does not update my key

[Peter Lebbing]

On 12/02/17 13:32, Marko Bauhardt wrote:
> Hi,
> The amor definition of my public key i uploaded
> to hkps://hkps.pool.sks-keyservers.net differs to the public key
> definition i uploaded to another web service.

An OpenPGP public key is composed of many parts which can be reordered
without changing the meaning. Keyservers do reorder stuff, so you can't
just compare two keys byte by byte and say anything useful about their
equivalence.

A command like

$ gpg2 --list-options show-unusable-subkeys,show-unusable-uids
--list-sigs [KEYID]

gives a pretty good overview of a public key. Here is what is on the
keyserver for you:

> pub   rsa4096 2015-08-16 [C]
>   DC0FE85182A372E37FE1ACDB970CFD4753192101
> uid   [  full  ] Marko Bauhardt - marko.bauhardt at mailbox.org -
> sig 3970CFD4753192101 2015-08-16  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sig 3970CFD4753192101 2017-02-06  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sig 3970CFD4753192101 2015-08-16  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> uid   [  full  ] Marko Bauhardt (Datameer GmbH) - mb at datameer.com -
> sig 3970CFD4753192101 2017-02-06  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2015-08-16 [S] [expired: 2016-08-15]
> sig  970CFD4753192101 2015-08-16  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2015-08-16 [E] [expired: 2016-08-15]
> sig  970CFD4753192101 2015-08-16  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2015-08-16 [A] [expired: 2016-08-15]
> sig  970CFD4753192101 2015-08-16  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2017-01-28 [S] [expires: 2018-01-28]
> sig  970CFD4753192101 2017-01-28  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2017-01-28 [E] [expires: 2018-01-28]
> sig  970CFD4753192101 2017-01-28  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> sub   rsa4096 2017-01-28 [A] [expires: 2018-01-28]
> sig  970CFD4753192101 2017-01-28  Marko Bauhardt - marko.bauhardt at 
> mailbox.org -
> 

I've changed your e-mail address so web spam scrapers can't take it
easily. If you see all the components there really are on your key
reflected in this output, then the keyserver is already fully up to date
and any further sending of your key will not change it any further.

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 

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

Re: Problems with GPGME1.8 and Python 3.5 bindings

[Justus Winter]

Hi :)

Jean-François Schaff  writes:

> I'm new to gpg, and trying to use the Python bindings included in
> PGPME. I'm using Ubuntu 16.04 LTS.
>
> I have done the following things:
...
> - compiled and installed gpgme-1.8.0
>
> Everything seems to build and install as expected, but when I finally
> try to use the python package (import gpg) I get the following error:
>
> (venv) jfs@Danube-linux:~/webdev/mms$ python
> Python 3.5.2 (default, Nov 17 2016, 17:05:23)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import gpg
> Traceback (most recent call last):
...
> ImportError: 
> /home/jfs/webdev/mms/venv/local/lib/python3.5/site-packages/gpg/_gpgme.cpython-35m-x86_64-linux-gnu.so:
> symbol gpgme_pubkey_algo_string, version GPGME_1.1 not defined in file
> libgpgme.so.11 with link time reference

gpgme_pubkey_algo_string is new in GPGME 1.7.  This suggests that the
version 1.8 that you built is not picked up.  How you resolve that is
really up to you and your needs.  You could for example add the
$your_install_prefix/lib to LD_LIBRARY_PATH in your bin/activate script.


Cheers,
Justus


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

Re: Keyring operations _very_ slow

[René Pfeiffer]

On Feb 10, 2017 at 1610 +, Andrew Gallagher appeared and said:
> On 10/02/17 12:57, René Pfeiffer wrote:
> > Hello!
> > 
> > I am using gpg and gpg2 with mutt and Icedove/Thunderbird (with Enigmail
> > plugin). My public keyring has grown to be very big since the email clients
> > auto-import unknown keys. Plus I did some signing and imported keys signing
> > keys from others.
> > 
> > The problem is that most GPG operations Enigmail does take a lot of time,
> > because key ring operations are very slow.
> 
> What version of gpg are you using, and how many keys do you have? I've
> been suffering from similar problems for years.

I am using Debian 8 on all platforms and sadly have gpg (1.4.18-7+deb8u3)
and gpg2 (2.0.26-6+deb8u1). I am using both (gpg for mutt and gpg2 for
Icedove/Thunderbird), because gpg2 relies on pinentry which completely
breaks one of my workflows. I use gpg2 for key management though.

> One thing I found that did help somewhat was to export my public
> keyring, delete it, and then reimport the dump. I found some keys were
> un-importable and (subjectively) keyring operations seem to run a
> little faster now. YMMV

I tried that already, will try it again. I also suspect
old/"broken"/unusable keys.

Best,
René.

-- 
  )\._.,--,'``.  fL  Let GNU/Linux work for you while you take a nap.
 /,   _.. \   _\  (`._ ,. R. Pfeiffer  + http://web.luchs.at/
`._.-(,_..'--(,_..'`-.;.'  - System administration + Consulting + Teaching -
Got mail delivery problems?  https://web.luchs.at/information/blockedmail.php
Warning: Do _NOT_ send emails with HTML content to my address! No guarantees!


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