Re: Questions about --throw-keyids

[Daniel Kahn Gillmor]

On Tue 2017-02-14 15:08:25 -0500, Werner Koch wrote:
> I don't think that --throw-keyid is a useful thing for use of gpg
> in mails - it does not really help in this use case because that meta
> data is easier available by other means.

I absolutely agree with this assessment, and i also agree with Bjarni's
approach to defending bcc addresses by sending distinct e-mails.
Bjarni's suggestion could theoretically be done in two ways:

 0) do the symmetric encryption once, and then pick and choose which
PKESK OpenPGP packets to prepend to it depending on which message is
being generated.

 1) simply re-encrypt the same cleartext multiple times (using different
symmetric session keys)

afaict, GnuPG only supports (1) at the moment (this is probably OK).

Presumably each message would use the same Message-Id, so that replies
thread properly, etc.
 
However, gpg is a tool that's used not only in e-mail contexts, so it
does still need to support the --throw-keyids option, since non-email
contexts are not guaranteed to be wrapped in equivalent metadata the
same way as an rfc822 message would be. :/

 --dkg



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

RE: Questions about --throw-keyids

[Robert J. Hansen]

> ... while adding another option may fix every small problem at hand, it
> creates a huge one that is even harder to fix: We have way too many
options
> already.

Some years ago I had the wild urge to set up Prolog code that would
determine the necessary command-line flags to sustain certain operations,
and which ones could be mixed-and-matched without affecting each other.
After a few days of work I gave up on it: even after reading the source
code, the multitude of operations seemed to be a hall of mirrors.

If I could wave a magic wand, I'd make a huge number of those options just
simply go away.



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

Aw: Re: SmartCard v2.1 : factory reset fails

[Fib Moro]

Hello Yutaka,

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

It doesn't even get to the point where it prompts me for the Reset Code:

Here is what I do:

When try to set the reset code via "passwd => 4" it prompts me for the AdminPIN.
I enter the default AdminPIN value of "123456789" and get the message "Error 
setting the Reset Code: Bad PIN"
I'm 100% sure I entered AdminPIN correctly.
The same issue occurs if I set the AdminPIN manually beforehand.

_

gpg/card> passwd
gpg: OpenPGP card no. DXXX detected

1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit

Your selection? 4
Error setting the Reset Code: Bad PIN
_

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

I am sorry, I was a bit imprecise here. Please let me explain again:

I start gpg in "--edit-key" mode.
Then I select a subkey I want to move to the card by issuing command "key 1".
After the "keytocard" command it asks me where to store the key for which I 
choose option 1 signature key.
It then prompts me for the privat key passphrase which I enter successfully.
Now it asks me for AdminPIN. Again with default value "123456789" I get the 
message "gpg: KEYTOCARD failed: Bad secret key"
Also the same issue occurs if I set the AdminPIN manually beforehand.
_

gpg> key 1
...
gpg> keytocard
Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1
gpg: KEYTOCARD failed: Bad secret key
__

Please let me know if you need more information.

Thank you kindly,

fibmoro

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

Re: Questions about --throw-keyids

[Werner Koch]

On Tue, 14 Feb 2017 15:27, d...@fifthhorseman.net said:

> I'm open to other suggestions about how to achieve this behavior.

There is an old FIXME in the code which needs to be removed:

  /* FIXME: Store this all in a list and process it later so that
 we can prioritize what key to use.  This gives a better user
 experience if wildcard keyids are used.  */

I like your suggestion of also looking at the creation date and key size
as further sort parameters.


Salam-Shalom,

   Werner


ps.
I don't think that --throw-keyid is a useful thing for use of gpg
in mails - it does not really help in this use case because that meta
data is easier available by other means.  But if people start using this
more we need a solution.

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


pgpXf6sJ2pvh5.pgp
Description: 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

[Kristian Fiskerstrand]

On 02/14/2017 07:51 PM, Marko Bauhardt wrote:
> The trust level of my two IDs was `unknown` in the one public key and 
> `ultimate` in the other key.

Trust level is not a property of the public key, it is stored out of
band (in the local trustdb)

-- 

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

Qui audet vincit
Who dares wins



signature.asc
Description: OpenPGP digital 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

[Marko Bauhardt]

Hi Peter,

> On 13 Feb 2017, at 12:16, Peter Lebbing  wrote:
> 
> 
> 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.

I tried that out with my two public key representations. There was a diff 
between the two keys.
The trust level of my two IDs was `unknown` in the one public key and 
`ultimate` in the other key.

Maybe this is the reason why the armor output is different.
I mean it make sense when the key server will change the trust level of the 
given user-id to `unknown` while uploading.


> I've changed your e-mail address so web spam scrapers can't take it
> easily.

;) Thx!

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

This was the case except of the trust level.

> 
> HTH,
> 
> Peter.

Thank you. Very helpful.
Marko

---

Marko Bauhardt
https://keybase.io/mbauhardt

GPG Key ID: 53192101
GPG Fingerprint: DC0F E851 82A3 72E3 7FE1  ACDB 970C FD47 5319 2101



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

[Justus Winter]

Daniel Kahn Gillmor  writes:

> On Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote:
>> I don't.  I strongly believe that adding command line switches should be
>> the absolute last resort.
>
> I'm open to other suggestions about how to achieve this behavior.

I have none, and tbh I did not even thought this through.  However...

> GnuPG's general stance appears to be that the only way to interact with
> the suite is through the command line.  It also has historically tried
> to avoid making breaking changes to the behavior based on existing
> options.  This doesn't appear to leave much room for fixing problems or
> adding functionality *without* new command-line switches.

... while adding another option may fix every small problem at hand, it
creates a huge one that is even harder to fix: We have way too many
options already.


Justus


signature.asc
Description: 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 Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote:
> I don't.  I strongly believe that adding command line switches should be
> the absolute last resort.

I'm open to other suggestions about how to achieve this behavior.

GnuPG's general stance appears to be that the only way to interact with
the suite is through the command line.  It also has historically tried
to avoid making breaking changes to the behavior based on existing
options.  This doesn't appear to leave much room for fixing problems or
adding functionality *without* new command-line switches.

   --dkg

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

Re: Questions about --throw-keyids

[Peter Lebbing]

On 13/02/17 17:54, Lukas Pitschl | GPGTools wrote:
> 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.

Maybe GnuPG already does this, but instead of a two-step process first
trying cached keys non-interactively and then falling back to trying
keys with prompting for passphrases, GnuPG could also simply, in one
plain standard invocation, first try all the cached secrets and when
that fails start prompting for even more secret keys.

HTH,

Peter.

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



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

Re: Questions about --throw-keyids

[Justus Winter]

Daniel Kahn Gillmor  writes:

> [ Unknown signature status ]
> 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.

I don't.  I strongly believe that adding command line switches should be
the absolute last resort.

Justus


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