From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jun  1 03:24:17 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 1 Jun 2017 02:24:17 +0100
Subject: Don't send encrypted messages to random users
In-Reply-To: <tp1i29fufmf7xv.fsf@menglehorn-lt.lan.zayoms.net>
References: <766aba77-2c3b-c2e5-fdf6-5a495a4f8eb6@nofroth.com> 
 <a9cf3ce8-6f8a-b188-dc19-6b36d4fc5f58@ruhr-uni-bochum.de>
 <419259931.20170529154557@riseup.net>
 <4d639920-8c42-e255-e9fa-1344fb00d3b6@mail.ru>
 <CALvb29yfc7KrUYGuRybCM7hQGN7MgmOMQUfs+PxbD44U-gMOEQ@mail.gmail.com>
 <9610eaf5-4fe8-774e-b735-a81b0f674bd3@mail.ru>
 <20170530123716.4abf8528@braetac.lighthouse.yetnet>
 <tp1i29fufmf7xv.fsf@menglehorn-lt.lan.zayoms.net>
Message-ID: <5393981.20170601022417@riseup.net>

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



On Tuesday 30 May 2017 at 8:42:04 PM, in
<mid:tp1i29fufmf7xv.fsf at menglehorn-lt.lan.zayoms.net>, Michael
Englehorn wrote:-


> Also, it would be strange to only publish your key's
> "name only" UID to the
> keyserver, because then at a keysigning event I
> wouldn't know where to
> send your public key back to, and I couldn't certify
> any of your e-mail
> addresses.


A user can use hashed instead of human-readable forms of their name
and/or their email address in a key's user-ids. The email address (or
name) cannot be determined from simple inspection of the UID. Just a
defence against casual snooping on the information in user-ids, not a
security measure but the "incident" that gave rise to this thread is
prevented. The downside is that using the cleartext email address (or
name) as your search string doesn't find the key from a keyserver and
the email client fails to match the key by email address, rendering
those UIDs largely useless.

It has been discussed here before, and dismissed by people cleverer
than me, that the hashed version could be searched for as well as the
readable version to locate a key from the local keyring or from
keyservers. A member of PGPNET produced some Python scripts as an
exercise in seeing what might go into this, when we last discussed the
idea over there about three years ago.

- --
Best regards

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

No matter where you go, there you are.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWS9sw18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5OYaAP9n45Ojx5tHSw3KcGFbNmoq63sXckEqjQgiWsbQ1EG4SwD9Gw2P2/826VT4
+W5na/kbL1Dz+EveaMHG+z54V8Cn4w6JAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWS9syl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8JYvB/9WQFZRychf3xx9Xh3S+QRWIV4Y
dZ7Ph7rG2VOlwPVUi0/zqIycnjFQNcFRSGojnHfZE07+hDHXq3/e+epxUbYrpys9
aGf/Bj5N0sPKU8/kLAFbUsclFbGyz6/mrjALlLgyEQXYAYJ8JdgkAbifUW7Xkc4O
Nx3HyUQE2hbzmWo4BU2xl7ummTjPthvrZnaDvRkjlX/eG1x2Y87d/2GjLqsSbM9Q
tooQLkf5yyY42QFyPRg9TZehv8bfYq0SMiVmft4LPf8HtuI1lCVUb8YnExqwcSs2
BnjSaAE+aafdEIPXU3g938PIdctZocemMuxImT2ql9TN1/tWGtuKA6yRPkEY
=ndHi
-----END PGP SIGNATURE-----



From daniel at pocock.pro  Thu Jun  1 08:06:01 2017
From: daniel at pocock.pro (Daniel Pocock)
Date: Thu, 1 Jun 2017 08:06:01 +0200
Subject: PGP for official documents / eIDAS and ZertES
In-Reply-To: <CA+dhYEXCRER-QqE5hx_NKm-aJEUE_D_M892Fe9b10D9FfqGhaw@mail.gmail.com>
References: <065c726e-7922-0352-938a-bf2aa274d390@pocock.pro>
 <a985e769-a7b3-8bad-47bf-d4cf1161c4ef@posteo.de>
 <7a6ff952-835b-9a30-5176-1e06cebb4783@pocock.pro>
 <1db3339f-7b71-8279-3330-b45c99b7f65c@posteo.de>
 <98C1E414-7CE6-4EFC-BF70-B9106D0F182A@hoerbe.at>
 <cd858aa9-7dd7-30d6-f957-3088698929ad@pocock.pro>
 <CA+dhYEXCRER-QqE5hx_NKm-aJEUE_D_M892Fe9b10D9FfqGhaw@mail.gmail.com>
Message-ID: <20f639b0-9c18-4e56-f629-1ad8eda4fd55@pocock.pro>



On 31/05/17 19:34, ankostis wrote:
> On 31 May 2017 at 15:14, Daniel Pocock <daniel at pocock.pro> wrote:
>>
>> Are the CMS, PDF or XML standards flexible enough that a PGP signature
>> could be used within any of them and thereby satisfy the legislation?
> 
> IANAL, but I would agree with Reiner that the implementing acts are not
> technology-neutral.
> More detailed, from the three standards supported, only the last one,
> XML-sig, supports PGP: https://www.w3.org/TR/xmldsig-core/#sec-PGPData
> 

Are there any basic examples of using XML-sig with GnuPG for signing and
verifying?

Are there any specific attributes that need to be included in a key used
for eIDAS?  E.g. does the legislation expect the photo or even something
like home address or date of birth, or just the name and email address
is sufficient?


> 
> 
>>> There are quite heavy
>>> legal and organization layers on top of the technology that assure
>>> security levels, notification (mutual acceptance) and cooperation
>>> procedures.
> 
> Regarding organizational issues, there in nothing in eIDAS *in principal"
> that forbids a company to use XML-sig with PGP.
> But it would be interesting how the "national authorities" would react
> in practice,
> should they receive such a request from a company.
> If it would work, for certain, these 2 German companies would have a head-start.
> 

There are a couple of scenarios:

- for submitting documents to national authorities, some types of
submission (e.g. a tax return without any refund due) are a one-way
process.  The person submitting the document can assert they submitted
it in compliance with the law and it is then a problem for the national
authority to make sure their IT systems are reading valid PGP
signatures.  We will see some of them start advertising vacancies for
consultants with PGP expertise at the point people start submitting
PGP-signed documents.

- for business-to-business or consumer-to-business transactions, if a
business is willing to accept orders signed with PGP, they are making
life a lot easier for their customers.  The money the customer doesn't
have to waste on something like SuissID is money the customer can spend
with the business in question.

Another aspect of this topic: if at least one valid solution exists
(e.g. using XML-sig), then consultants specializing in PGP could tell
their customers that they offer a competitive solution compliant with
eIDAS and ZertES.

Regards,

Daniel


From guru at unixarea.de  Thu Jun  1 08:48:34 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 1 Jun 2017 08:48:34 +0200
Subject: about how the MUA mutt signs mails
Message-ID: <20170601064834.GA2916@c720-r314251>


Hello,

When I send signed mails to me with the MUA mutt (just for test) the
received mail is verified fine in mutt, i.e. it says in mutt:

    [-- Begin signature information --]
    Good signature from: Matthias Apitz (GnuPG CCID) <guru at unixarea.de>
            created: Wed May 31 21:40:19 2017
    [-- End signature information --]
    
    [-- The following data is signed --]
    
    hello
    
    
    [-- End of signed data --]

but when I save the signature part into a file 'signature.asc' and the
ASCII content of the mail as a file 'data' from the menu in mutt:

q:Exit  s:Save  |:Pipe  p:Print  ?:Help
  I     1 <no description>                                          [text/plain, 7bit, utf-8, 0.1K]
  I     2 signature.asc                                            [applica/pgp-signat, 7bit, 0.8K]

and run:

$ gpg2 --verify signature.asc data
gpg: Signature made Wed May 31 21:40:19 2017 CEST
gpg:                using RSA key 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
gpg: BAD signature from "Matthias Apitz (GnuPG CCID) <guru at unixarea.de>" [ultimate]

it says 'BAD signature'.

Why the file 'data' has BAD signature? The file 'data' after saving from
mutt from the above menu just contains:

$ cat data
hello

$ od -c data
0000000    h   e   l   l   o  \n  \n
0000007

I digged into this trussing the mutt-gpg2 process chain and it turned out that
the netto data which verifies mutt is:

$ od -c data.asc
0000000    C   o   n   t   e   n   t   -   T   y   p   e   :       t   e
0000020    x   t   /   p   l   a   i   n   ;       c   h   a   r   s   e
0000040    t   =   u   t   f   -   8  \r  \n   C   o   n   t   e   n   t
0000060    -   D   i   s   p   o   s   i   t   i   o   n   :       i   n
0000100    l   i   n   e  \r  \n  \r  \n   h   e   l   l   o  \r  \n  \r
0000120   \n
0000121

i.e. containes as well some mail header line about the content and charset and esp.
as well \r\n line terminators. If I modify the file to this it is fine:

$ gpg2 --verify signature.asc data.asc
gpg: Signature made Wed May 31 21:40:19 2017 CEST
gpg:                using RSA key 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
gpg: Good signature from "Matthias Apitz (GnuPG CCID) <guru at unixarea.de>" [ultimate]

Is this correct how mutt signs such mail bodies?

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170601/cafe18b9/attachment.sig>

From ben at adversary.org  Thu Jun  1 10:25:21 2017
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 1 Jun 2017 18:25:21 +1000
Subject: scdaemon coredumps
In-Reply-To: <87k24xke7x.fsf@fifthhorseman.net>
References: <592D60EE.7070909@gmail.com> <87vaoij717.fsf@fifthhorseman.net>
 <20170531000216.z6qc62alxzdfdzr7@adversary.org>
 <87k24xke7x.fsf@fifthhorseman.net>
Message-ID: <20170601082521.dyrlimeu27n5vdoj@adversary.org>

On Tue, May 30, 2017 at 09:27:30PM -0400, Daniel Kahn Gillmor wrote:
> On Wed 2017-05-31 10:02:16 +1000, Ben McGinnes wrote:
>> It is pretty standard (and IIRC part of the SMTP RFCs) that the
>> forward and reverse DNS records must match.  The PTR record does not
>> have to match the hostname, but it does have to resolve to a hostname
>> with an A record pointing back to the IP.
>>
>> That lack of a PTR record for 195.159.176.226 will definitely cause
>> problems with any number of SMTP servers.
> 
> i'm aware of this common convention (without commenting on how useful it
> is at actually defeating spammers),

It may or may not be quite so useful now, but in the past it was a
good way of catching out connections from dynamically assigned IP
addresses.  Usually an SMTP connection from such a host meant a
compromised Windows box, the chances of it being a Linux enthusiast
were very slim.

Regardless of whether it remains useful, I'm sure most mail
administrators will retain that check since there's no reason not to.

> but i'm surprised to see it happening with two mail servers that
> both have sent messages to GnuPG mailing lists in the
> not-too-distant past.  it's possible that both of those mailservers
> have changed at the same time, i guess.  there certainly was a
> recent change for my own mail relay.

This I'm less sure on given how much is attached, either intentionally
or not, to the Internet these days.  I'm somewhat less surprised by
demonstrations of technical ignorance now.  I chalk that up to having
spent too long working in the industry.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170601/29474b4a/attachment.sig>

From mailinglist at darac.org.uk  Thu Jun  1 11:00:12 2017
From: mailinglist at darac.org.uk (Darac Marjal)
Date: Thu, 1 Jun 2017 10:00:12 +0100
Subject: about how the MUA mutt signs mails
In-Reply-To: <20170601064834.GA2916@c720-r314251>
References: <20170601064834.GA2916@c720-r314251>
Message-ID: <20170601090012.cu63mn4dovi6fnju@darac.org.uk>

On Thu, Jun 01, 2017 at 08:48:34AM +0200, Matthias Apitz wrote:
>
>Hello,
>
>When I send signed mails to me with the MUA mutt (just for test) the
>received mail is verified fine in mutt, i.e. it says in mutt:
>
>    [-- Begin signature information --]
>    Good signature from: Matthias Apitz (GnuPG CCID) <guru at unixarea.de>
>            created: Wed May 31 21:40:19 2017
>    [-- End signature information --]
>
>    [-- The following data is signed --]
>
>    hello
>
>
>    [-- End of signed data --]
>
>but when I save the signature part into a file 'signature.asc' and the
>ASCII content of the mail as a file 'data' from the menu in mutt:
>
>q:Exit  s:Save  |:Pipe  p:Print  ?:Help
>  I     1 <no description>                                          [text/plain, 7bit, utf-8, 0.1K]
>  I     2 signature.asc                                            [applica/pgp-signat, 7bit, 0.8K]
>
>and run:
>
>$ gpg2 --verify signature.asc data
>gpg: Signature made Wed May 31 21:40:19 2017 CEST
>gpg:                using RSA key 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
>gpg: BAD signature from "Matthias Apitz (GnuPG CCID) <guru at unixarea.de>" [ultimate]
>
>it says 'BAD signature'.
>
>Why the file 'data' has BAD signature? The file 'data' after saving from
>mutt from the above menu just contains:
>
>$ cat data
>hello
>
>$ od -c data
>0000000    h   e   l   l   o  \n  \n
>0000007
>
>I digged into this trussing the mutt-gpg2 process chain and it turned out that
>the netto data which verifies mutt is:
>
>$ od -c data.asc
>0000000    C   o   n   t   e   n   t   -   T   y   p   e   :       t   e
>0000020    x   t   /   p   l   a   i   n   ;       c   h   a   r   s   e
>0000040    t   =   u   t   f   -   8  \r  \n   C   o   n   t   e   n   t
>0000060    -   D   i   s   p   o   s   i   t   i   o   n   :       i   n
>0000100    l   i   n   e  \r  \n  \r  \n   h   e   l   l   o  \r  \n  \r
>0000120   \n
>0000121
>
>i.e. containes as well some mail header line about the content and charset and esp.
>as well \r\n line terminators. If I modify the file to this it is fine:
>
>$ gpg2 --verify signature.asc data.asc
>gpg: Signature made Wed May 31 21:40:19 2017 CEST
>gpg:                using RSA key 5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
>gpg: Good signature from "Matthias Apitz (GnuPG CCID) <guru at unixarea.de>" [ultimate]
>
>Is this correct how mutt signs such mail bodies?

This is "PGP-MIME" format, as refined in
<https://tools.ietf.org/html/rfc3156>. Section 5 of that clearly states:

   The multipart/signed body MUST consist of exactly two parts.  The
   first part contains the signed data in MIME canonical format,
   including a set of appropriate content headers describing the data.

   The second body MUST contain the OpenPGP digital signature.  It MUST
   be labeled with a content type of "application/pgp-signature".

So, the MUA must convert the message body to MIME format (with the right
line endings, with any Base64 or Quoted Printable encoding applied) and
add the Content-Type header BEFORE signing the message. Similarly, the
MUA must verify the signature BEFORE parsing the body's header for how
to decode the message for display/saving.

To re-iterate, when you save the message body, mutt strips the header
and decodes the file (imagine if this was a binary attachment in Base64
encoding; you DO want mutt to reconstruct it back into binary form).



>
>	matthias
>
>-- 
>Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
>Public GnuPG key: http://www.unixarea.de/key.pub



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


-- 
For more information, please reread.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 906 bytes
Desc: not available
URL: </pipermail/attachments/20170601/92ce77ba/attachment.sig>

From guru at unixarea.de  Thu Jun  1 11:27:37 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 1 Jun 2017 11:27:37 +0200
Subject: about how the MUA mutt signs mails
In-Reply-To: <20170601090012.cu63mn4dovi6fnju@darac.org.uk>
References: <20170601064834.GA2916@c720-r314251>
 <20170601090012.cu63mn4dovi6fnju@darac.org.uk>
Message-ID: <20170601092737.GA4277@c720-r314251>

El d?a Thursday, June 01, 2017 a las 10:00:12AM +0100, Darac Marjal escribi?:

> >Is this correct how mutt signs such mail bodies?
> 
> This is "PGP-MIME" format, as refined in
> <https://tools.ietf.org/html/rfc3156>. Section 5 of that clearly states:
> 
> ...

Darac,

Thank you very much for your enlightened explanation and ...

> -- 
> For more information, please reread.

... and for your nice signature.

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170601/dbba5a07/attachment-0001.sig>

From stefan.claas at posteo.de  Thu Jun  1 12:05:07 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 1 Jun 2017 12:05:07 +0200
Subject: Message Padding
Message-ID: <6d32f8d3-a4bb-2212-c8ab-ac75cca68381@posteo.de>

Hi all,

i wonder why message padding was never considered in GnuPG, as 
additional parameter?

http://www.wiredyne.com/software/padding.html

Regards

Stefan




From wk at gnupg.org  Fri Jun  2 10:31:31 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jun 2017 10:31:31 +0200
Subject: [Announce] Libgcrypt 1.7.7 released
Message-ID: <87o9u67puk.fsf@wheatstone.g10code.de>

Hi!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.7.7.  This is a bug fixing.

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 in version 1.7.7 (2017-06-02)  [C21/A1/R7]
===================================

 * Bug fixes:

   - Fix possible timing attack on EdDSA session key.

   - Fix long standing bug in secure memory implementation which could
     lead to a segv on free. [bug#3027]


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.7.7.tar.bz2 (2794k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.gz (3290k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.bz2 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.7.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.7.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.7.7.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.7.7.tar.bz2.sig libgcrypt-1.7.7.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.7.7.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.7.7.tar.bz2

   and check that the output matches the first line from the
   this list:

ea4ae1a4dba51f15095319419d7b42a0bf160384  libgcrypt-1.7.7.tar.bz2
fc5b02758dc47fde70a155a05efe9d92a1778f8d  libgcrypt-1.7.7.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].


For the GnuPG hackers,

   Werner


[1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
[2] https://www.gnupg.org/service.html
[3] https://gnupg.org/donate/kudos.html


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/20170602/876a1006/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From lionel at mamane.lu  Fri Jun  2 14:42:56 2017
From: lionel at mamane.lu (Lionel Elie Mamane)
Date: Fri, 2 Jun 2017 14:42:56 +0200
Subject: Certification-only key
In-Reply-To: <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu>
 <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
Message-ID: <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>

On Wed, May 31, 2017 at 05:42:10PM +0200, Peter Lebbing wrote:
> On 31/05/17 14:52, Lionel Elie Mamane wrote:

>> Right to be forgotten. The signatures I made a long time ago were made
>> by a different person, although there is a continuity between the
>> two.

> Talking about not forgetting, you answered after seven years?! :-D

> I don't think expiring a signing subkey will make anyone forget
> anything. Keyservers are append-only, so the expired subkey stays
> there, (...)

Yes. However, if I publish the secret signing subkey after it expires,
the cryptographic certainty is gone. Don't need expiry for that, but
it is a self-reminder. Also to consider whether I maybe want to use a
longer key now.

-- 
Lionel


From peter at digitalbrains.com  Fri Jun  2 15:06:57 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 2 Jun 2017 15:06:57 +0200
Subject: Certification-only key
In-Reply-To: <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
Message-ID: <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>

On 02/06/17 14:42, Lionel Elie Mamane wrote:
> However, if I publish the secret signing subkey after it expires,
> the cryptographic certainty is gone.

Heh, that's an interesting take on it. Thanks for sharing it.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From andrewg at andrewg.com  Fri Jun  2 17:03:15 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 2 Jun 2017 16:03:15 +0100
Subject: Certification-only key
In-Reply-To: <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
 <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
Message-ID: <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>

On 2017/06/02 14:06, Peter Lebbing wrote:
> On 02/06/17 14:42, Lionel Elie Mamane wrote:
>> However, if I publish the secret signing subkey after it expires,
>> the cryptographic certainty is gone.
> 
> Heh, that's an interesting take on it. Thanks for sharing it.

The main motivation for publishing a signing secret after use is
repudiability. But for that to work properly, your correspondents need
to know that you've published the secret, and you also need to have
confidence that they know. Synchronous protocols like OTR do this
well. PGP is highly asynchronous, with typically very infrequent key
refresh cycles, and intentionally publishing secret material - even for
revoked keys - runs the risk of your correspondents getting scammed
during the refresh interval.

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/20170602/85c1b8a4/attachment.sig>

From peter at digitalbrains.com  Fri Jun  2 19:25:31 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 2 Jun 2017 19:25:31 +0200
Subject: Certification-only key
In-Reply-To: <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
 <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
 <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>
Message-ID: <3f15da52-fb41-d6df-bd82-24bdd272bbd6@digitalbrains.com>

On 02/06/17 17:03, Andrew Gallagher wrote:
> intentionally publishing secret material - even for
> revoked keys - runs the risk of your correspondents getting scammed
> during the refresh interval.

Note that this related to an *expired* subkey. If people wouldn't update
their keyrings (which they indeed would not, probably), it would still
correctly be expired.

I did later realize that if somebody used a timestamping service to
timestamp a document you signed, you would have to argue that you
already published your secret key before that time. You can't defend
yourself anymore with "that was backdated and signed only after the key
expired and was published". It changes the argument somewhat.

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/20170602/924e3b7c/attachment-0001.sig>

From wk at gnupg.org  Fri Jun  2 21:39:51 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jun 2017 21:39:51 +0200
Subject: PGP for official documents / eIDAS and ZertES
In-Reply-To: <CA+dhYEXCRER-QqE5hx_NKm-aJEUE_D_M892Fe9b10D9FfqGhaw@mail.gmail.com>
 (ankostis@gmail.com's message of "Wed, 31 May 2017 19:34:17 +0200")
References: <065c726e-7922-0352-938a-bf2aa274d390@pocock.pro>
 <a985e769-a7b3-8bad-47bf-d4cf1161c4ef@posteo.de>
 <7a6ff952-835b-9a30-5176-1e06cebb4783@pocock.pro>
 <1db3339f-7b71-8279-3330-b45c99b7f65c@posteo.de>
 <98C1E414-7CE6-4EFC-BF70-B9106D0F182A@hoerbe.at>
 <cd858aa9-7dd7-30d6-f957-3088698929ad@pocock.pro>
 <CA+dhYEXCRER-QqE5hx_NKm-aJEUE_D_M892Fe9b10D9FfqGhaw@mail.gmail.com>
Message-ID: <87r2z218mw.fsf@wheatstone.g10code.de>

On Wed, 31 May 2017 19:34, ankostis at gmail.com said:

> More detailed, from the three standards supported, only the last one,
> XML-sig, supports PGP: https://www.w3.org/TR/xmldsig-core/#sec-PGPData

That looks pretty much like a re-specification of PKCS#15 which also has
provisions for PGP and SPKI.  However, I have never seen an
implementation of that and the whole spec is heavily underspecified to
actually implement something based on this.  PKCS#15 at least tried to
unify existing protocols for tokens. 

|  >>I have some questions related to XML-Dsig:
|  >
|  >Argghh!! Run away!
|
|  A near-universal reaction.

XML crypto can be summarized as
we-repeat-all-bugs-the-other-two-protocols-meanwhile-fixed-and-add-extra-complexity-for-even-more-fun
See also <https://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt>

If someone really likes that stuff and want to give it a try, I would
suggest to write it along the lines of GnuPG's gpgsm tool so that it has
a similar external interface.  Adding this tool to GPGME would then be
the simple part.


SCNR,

   Werner



ps. I already have my share of grey hair from implementing X.509/CMS.
    There is not enough left for an XML crypto endeavor.

-- 
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/20170602/d146d209/attachment.sig>

From ben at adversary.org  Fri Jun  2 22:37:32 2017
From: ben at adversary.org (Ben McGinnes)
Date: Sat, 3 Jun 2017 06:37:32 +1000
Subject: PGP for official documents / eIDAS and ZertES
In-Reply-To: <87r2z218mw.fsf@wheatstone.g10code.de>
References: <065c726e-7922-0352-938a-bf2aa274d390@pocock.pro>
 <a985e769-a7b3-8bad-47bf-d4cf1161c4ef@posteo.de>
 <7a6ff952-835b-9a30-5176-1e06cebb4783@pocock.pro>
 <1db3339f-7b71-8279-3330-b45c99b7f65c@posteo.de>
 <98C1E414-7CE6-4EFC-BF70-B9106D0F182A@hoerbe.at>
 <cd858aa9-7dd7-30d6-f957-3088698929ad@pocock.pro>
 <CA+dhYEXCRER-QqE5hx_NKm-aJEUE_D_M892Fe9b10D9FfqGhaw@mail.gmail.com>
 <87r2z218mw.fsf@wheatstone.g10code.de>
Message-ID: <20170602203732.wao6rniog5zp6by7@adversary.org>

On Fri, Jun 02, 2017 at 09:39:51PM +0200, Werner Koch wrote:
> On Wed, 31 May 2017 19:34, ankostis at gmail.com said: 
> 
> |  >>I have some questions related to XML-Dsig:
> |  >
> |  >Argghh!! Run away!
> |
> |  A near-universal reaction.
> 
> XML crypto can be summarized as
> we-repeat-all-bugs-the-other-two-protocols-meanwhile-fixed-and-add-extra-complexity-for-even-more-fun
> See also <https://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt>

I like XML, it's very good at what it was originally intended for.  I
like crypto, and specifically OpenPGP, too and for much the same
reasons ...

I am *not*, however, crazy enough to to even consider attempting this.
That way lies only madness and ruin.  Or, to put it another way, I
listened to Peter the first time around.  ;)

> ps. I already have my share of grey hair from implementing X.509/CMS.
>     There is not enough left for an XML crypto endeavor.

Mine's not expendable either and I didn't need to go anywhere near
X.509 to know that.

The closest anyone should get to that sort of thing is "I have foo.xml
and I've signed it, I now also have foo.xml.sig" and that's it.


Regards,
Ben

P.S.  You heard me say "no" right?  Just checking ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170603/f4d9fc6f/attachment.sig>

From yumkam at gmail.com  Sat Jun  3 16:32:21 2017
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Sat, 3 Jun 2017 17:32:21 +0300
Subject: scdaemon coredumps
In-Reply-To: <87k24xkews.fsf@iwagami.gniibe.org>
References: <592D60EE.7070909@gmail.com> <87k24xkews.fsf@iwagami.gniibe.org>
Message-ID: <5932C875.80406@gmail.com>

On 31.05.2017 04:12, NIIBE Yutaka wrote:
> "Yuriy M. Kaminskiy" <yumkam at gmail.com> wrote:
>> When I tried to rebuild gnupg2 2.1.21-2 debian package from
>> experimental in pbuilder, I got a number of sigsegv's from scdaemon
>> while running tests:
> [...]
>> Annoyingly, test-suite does not catch this as error, it has not left any
>> core, and name of executable was masked, so after twiddling here and
>> there, I got core and discovered that scdaemon dies when it tries to use
>> libusb after libusb intiialization failed:
>
> There are two things here.  The selection of default key by gpg frontend
> was not good.  It was fixed in:
>
>      fbb2259d22e6c6eadc2af722bdc52922da348677
>      g10: Fix default-key selection for signing, possibly by card.

FTR, gnupg2 2.1.21-2 already contained backported patch
a8dd96826f8484c0ae93c954035b95c2a75c80f2.

I also cherry-picked fbb2259d22e6c6eadc2af722bdc52922da348677 on top of it.

> And by your report, scdaemon core dump is fixed in:
>
>     5c33649782bf255af5a55f16eac5e85f059b00bf
>     scd: Handle a failure of libusb_init.
>
>     8defb21d34410d000c8b776e0e3a1edd04762638
>     scd: Fix error code on failure at usb_init.

... and I added those 2 commits; but as a result, package build freezes
at executing test-suite.

Last lines at logs are:

=== cut ===
Checking signing with the default hash algorithm
     > plain-1 Executing: '/build/gnupg2-2.1.21/build/g10/gpg' 
'--no-permission-warning' '--always-trust' '--output' 
'/tmp/gpgscm-20170603T111800-sigs-Dzwfcp/a' '--yes' '--sign' 'plain-1'
Child 17700 returned: ((command ("/build/gnupg2-2.1.21/build/g10/gpg" 
--no-permission-warning --always-trust --output 
"/tmp/gpgscm-20170603T111800-sigs-Dzwfcp/a" --yes --sign "plain-1")) 
(status 0) (stdout ) (stderr ))
Executing: '/build/gnupg2-2.1.21/build/g10/gpg' 
'--no-permission-warning' '--always-trust' '--output' 
'/tmp/gpgscm-20170603T111801-sigs-OXvubo/a' '--yes' '--decrypt' 
'/tmp/gpgscm-20170603T111800-sigs-Dzwfcp/a'
Child 17704 returned: ((command ("/build/gnupg2-2.1.21/build/g10/gpg" 
--no-permission-warning --always-trust --output 
"/tmp/gpgscm-20170603T111801-sigs-OXvubo/a" --yes --decrypt 
"/tmp/gpgscm-20170603T111800-sigs-Dzwfcp/a")) (status 0) (stdout ) 
(stderr gpg: Signature made Sat Jun  3 11:18:01 2017 UTC
gpg:                using DSA key A0FF4590BB6122EDEF6E3C542D727CC768697734
gpg: Good signature from "Alfa Test (demo key) <alfa at example.net>" [unknown]
gpg:                 aka "Alpha Test (demo key) <alpha at example.net>" 
[unknown]
gpg:                 aka "Alice (demo key)" [unknown]
gpg: WARNING: Using untrusted key!
))
plain-2 Executing: '/build/gnupg2-2.1.21/build/g10/gpg' 
'--no-permission-warning' '--always-trust' '--output' 
'/tmp/gpgscm-20170603T111801-sigs-buAUIY/a' '--yes' '--sign' 'plain-2'
=== cut ===

gdb attach to gpg:
(gpg --no-permission-warning --always-trust --output 
/tmp/gpgscm-20170603T111801-sigs-buAUIY/a --yes --sign plain-2)

(gdb) bt
#0  0xf74b182e in __read_nocancel () at 
../sysdeps/unix/syscall-template.S:81
#1  0xf757ff00 in __assuan_read ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#2  0xf7577767 in ?? ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#3  0xf75806f7 in ?? ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#4  0xf7578c61 in ?? ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#5  0xf7578e1f in ?? ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#6  0xf7578399 in assuan_client_read_response ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#7  0xf757874d in ?? ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#8  0xf7578885 in assuan_transact ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libassuan.so.0
#9  0x5668fe2a in start_agent (flag_for_card=2, ctrl=<optimized out>)
     at ../../g10/call-agent.c:295
#10 0x56690c10 in agent_scd_serialno (r_serialno=0xffd6e584, demand=0x0)
     at ../../g10/call-agent.c:1029
#11 0x5666785b in build_sk_list (ctrl=0x56ea1458, locusr=0x0,
     ret_sk_list=0xffd6e708, use=1) at ../../g10/skclist.c:141
#12 0x5666eac7 in sign_file (ctrl=0x56ea1458, filenames=0x56ea1488,
     detached=0, locusr=0x0, encryptflag=0, remusr=0x0, outfile=0x0)
     at ../../g10/sign.c:814
#13 0x56621428 in main (argc=1, argv=0xffd6ec24) at ../../g10/gpg.c:4115

gdb attach to gpg-agent:
(gpg-agent --homedir /tmp/gpgscm-XXX-run-tests-YYY 
--use-standard-socket --debug-quick-random --daemon)

#0  __call_pselect6 () at ../sysdeps/unix/sysv/linux/i386/call_pselect6.S:49
#1  0xf75bbda3 in __pselect (nfds=8, readfds=0xff98bf5c, writefds=0x0,
     exceptfds=0x0, timeout=0xff98bd30, sigmask=0xf767e200)
     at ../sysdeps/unix/sysv/linux/i386/../pselect.c:77
#2  0xf767be15 in npth_pselect ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libnpth.so.0
#3  0x565babf7 in handle_connections (listen_fd=-6767128, 
listen_fd_extra=0,
     listen_fd_browser=5, listen_fd_ssh=6) at ../../agent/gpg-agent.c:2961
#4  0x565b7407 in main (argc=0, argv=0xff98c284)
     at ../../agent/gpg-agent.c:1730

gdb attach to scdaemon (which was launched by gpg-agent):
scdaemon --multi-server --homedir /tmp/gpgscm-XXX-run-tests-YYY
#0  __call_pselect6 () at ../sysdeps/unix/sysv/linux/i386/call_pselect6.S:49
#1  0xf7503da3 in __pselect (nfds=4, readfds=0xffa51b58, writefds=0x0,
     exceptfds=0x0, timeout=0x0, sigmask=0xf75e6200)
     at ../sysdeps/unix/sysv/linux/i386/../pselect.c:77
#2  0xf75e3e15 in npth_pselect ()
    from 
/var/cache/pbuilder/jessie-i386/build/16354/cow.5/usr/lib/i386-linux-gnu/libnpth.so.0
#3  0x566521e8 in handle_connections (listen_fd=-514)
     at ../../scd/scdaemon.c:1318
#4  0x5665143a in main (argc=0, argv=0xffa51e44) at ../../scd/scdaemon.c:787

Removing
fbb2259d22e6c6eadc2af722bdc52922da348677
and
a8dd96826f8484c0ae93c954035b95c2a75c80f2
changed nothing (test-suite freezes).

And, finally, (likely) culprit: after I backed out
skip-missing-signing-keys/0013-g10-Skip-signing-keys-where-no-secret-key-is-availab.patch

=== cut ===
From: Simon Arlott <simon at arlott.org>
Date: Sun, 5 Feb 2017 16:31:35 -0500
Subject: g10: Skip signing keys where no secret key is available.

* g10/getkey.c (finish_lookup): When requiring PUBKEY_USAGE_SIG, skip
over keys where no signing key is available.
[...]
GnuPG-bug-id: 1967
Debian-bug-id: 834922

Signed-off-by: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
=== cut ===

test-suite passed without problems. So, this debian-specific patch 
apparently conflicts with some changes in 2.1.21 (and it was not 
noticed, as it was masked by scdaemon silent crashes).

YMMV.

Environment: debian jessie/i386 
[linux-image-3.16.0-4-amd64_3.16.43-2:amd64], 
cowbuilder(->pbuilder(->chroot)), with also jessie/i386.

Libraries used for build:
1) libassuan-dev [2.4.3-2~bpo8+1 (jessie-backports)]
2) libassuan0 [2.4.3-2~bpo8+1 (jessie-backports)]
3) libgcrypt20-dev [1.7.6-1~bpo8+1 (jessie-backports)]
4) libgpg-error-dev [1.26-2~bpo8+1 (jessie-backports)]
5) libksba-dev [1.3.5-2~bpo8+1 (jessie-backports)]
6) libksba8 [1.3.5-2~bpo8+1 (jessie-backports)]
7) libnpth0 [1.3-1~bpo8+1.1~local1 (jessie-local)]
8) libnpth0-dev [1.3-1~bpo8+1.1~local1 (jessie-local)]

>> With patch below, it just freezes at
>> === cut ===
>> ...
>> PASS: tests/openpgp/decrypt-unwrap-verify.scm
>> Checking signing with the default hash algorithm
>>        > plain-1 plain-2 <<< [here]
>> === cut ===
>> Have no idea why.
>
> I don't know what's going here.  Let's see...



From yumkam at gmail.com  Sun Jun  4 02:36:16 2017
From: yumkam at gmail.com (Yuriy M. Kaminskiy)
Date: Sun, 4 Jun 2017 03:36:16 +0300
Subject: scdaemon coredumps
In-Reply-To: <5932C875.80406@gmail.com>
References: <592D60EE.7070909@gmail.com> <87k24xkews.fsf@iwagami.gniibe.org>
 <5932C875.80406@gmail.com>
Message-ID: <59335600.7040104@gmail.com>

On 03.06.2017 17:32, Yuriy M. Kaminskiy wrote:
> On 31.05.2017 04:12, NIIBE Yutaka wrote:
>> "Yuriy M. Kaminskiy" <yumkam at gmail.com> wrote:
>>> When I tried to rebuild gnupg2 2.1.21-2 debian package from
>>> experimental in pbuilder, I got a number of sigsegv's from scdaemon
>>> while running tests:

[...]

> And, finally, (likely) culprit: after I backed out
> skip-missing-signing-keys/0013-g10-Skip-signing-keys-where-no-secret-key-is-availab.patch

Oops, sorry *this* was false positive - I just ran wrong version of code 
(without scdaemon fixes). With scdaemon fixes applied and 
skip-missing-signing-keys patch removed test-suite still freezes.

So, this patch is NOT guilty, and culprit is NOT found :-|

I tried disabling *other* potentially related debian patches 
(dirmngr-idling/*, gpg-agent-idling/*), and still no result - once 
scdaemon fixes applied, testsuite freezes in "plain-2" test.

I re-verified that gnupg2_2.1.20-3 builds and passes test-suite without 
problem in same environment, with or without scdaemon fixes applied (but 
it apparently never invoked scdaemon during test-suite, as unfixed 
scdaemon would always sigsegv in this environment).

> test-suite passed without problems. So, this debian-specific patch
> apparently conflicts with some changes in 2.1.21 (and it was not
> noticed, as it was masked by scdaemon silent crashes).
>
> YMMV.
>
> Environment: debian jessie/i386
> [linux-image-3.16.0-4-amd64_3.16.43-2:amd64],
> cowbuilder(->pbuilder(->chroot)), with also jessie/i386.
>
> Libraries used for build:
> 1) libassuan-dev [2.4.3-2~bpo8+1 (jessie-backports)]
> 2) libassuan0 [2.4.3-2~bpo8+1 (jessie-backports)]
> 3) libgcrypt20-dev [1.7.6-1~bpo8+1 (jessie-backports)]
> 4) libgpg-error-dev [1.26-2~bpo8+1 (jessie-backports)]
> 5) libksba-dev [1.3.5-2~bpo8+1 (jessie-backports)]
> 6) libksba8 [1.3.5-2~bpo8+1 (jessie-backports)]
> 7) libnpth0 [1.3-1~bpo8+1.1~local1 (jessie-local)]
> 8) libnpth0-dev [1.3-1~bpo8+1.1~local1 (jessie-local)]
>
>>> With patch below, it just freezes at
>>> === cut ===
>>> ...
>>> PASS: tests/openpgp/decrypt-unwrap-verify.scm
>>> Checking signing with the default hash algorithm
>>>        > plain-1 plain-2 <<< [here]
>>> === cut ===
>>> Have no idea why.
>>
>> I don't know what's going here.  Let's see...
>


From stefan.claas at posteo.de  Sun Jun  4 11:21:33 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 11:21:33 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
Message-ID: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>

Hi,

i like to ask application developers if it's possible to implement,
in the future, identicons like for example Bitmessage has?

https://github.com/jakobvarmose/go-qidenticon

The reason why i ask, i started to use Thunderbird with Enigmail and
Enigmail shows me always Untrusted Good Signature with a 32bit key ID,
when i have not carefully verified the persons pub key and --lsign'ed
the pub-key. Showing only the long key id or the complete fingerprint
is imho more difficult to quickly memorize than an additionial shown
identicon (computed from the fingerprint).

P.S. With scallion it took me only seconds/or a minute to generate
a fake pub-key with the same 32bit key id, on my old notebook.

Regards
Stefan



From ben at adversary.org  Sun Jun  4 11:50:08 2017
From: ben at adversary.org (Ben McGinnes)
Date: Sun, 4 Jun 2017 19:50:08 +1000
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
Message-ID: <20170604095008.g2sdg36jigpuvuqx@adversary.org>

On Sun, Jun 04, 2017 at 11:21:33AM +0200, Stefan Claas wrote:
> Hi,
> 
> i like to ask application developers if it's possible to implement,
> in the future, identicons like for example Bitmessage has?
> 
> https://github.com/jakobvarmose/go-qidenticon

It's possible, but it's highly unlikely that anyone would bother
creating what is essentially Gravatar for GPG.

Especially since the protocol already supports key owners including a
pictrure with their key.  Most people don't do that either.

> The reason why i ask, i started to use Thunderbird with Enigmail and
> Enigmail shows me always Untrusted Good Signature with a 32bit key ID,
> when i have not carefully verified the persons pub key and --lsign'ed
> the pub-key. Showing only the long key id or the complete fingerprint
> is imho more difficult to quickly memorize than an additionial shown
> identicon (computed from the fingerprint).

You shouldn't need to memorise it.  In Enigmail you can create rules
for addresses to link to preferred keys, as well as set whether or not
to encrypt all messages or just sign and so on.  Most MUAs which
support GPG provide some method of doing this and GPG itself supports
that function with group lists in the gpg.conf file.

If the version of GPG you have installed supports it, you should
probably add this to your gpg.conf:

    trust-model tofu+pgp
    tofu-default-policy unknown

That will gradually build a more practical web-of-trust which keeps
track of seen keys for you.

> P.S. With scallion it took me only seconds/or a minute to generate
> a fake pub-key with the same 32bit key id, on my old notebook.

Yes, this has been possible for a long time now.  Most people use a
64-bit view for that reason.  This is now the default view in GPG 2.1,
along with displaying the full finterprint.  If you do not have GPG
2.1.x installed, such as if you're using GPGTools on OS X or GPG4Win,
then add "keyid-format 0xLONG" to your gpg.conf file.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170604/4d2144d7/attachment-0001.sig>

From stefan.claas at posteo.de  Sun Jun  4 12:39:03 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 12:39:03 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <d38f8e98-c964-1362-c43e-50a9086de180@posteo.de>
References: <d38f8e98-c964-1362-c43e-50a9086de180@posteo.de>
Message-ID: <41d72726-e10f-3bc6-a36a-c3e86d3eae66@posteo.de>

On 04.06.17 11:50, Ben McGinnes wrote:

> On Sun, Jun 04, 2017 at 11:21:33AM +0200, Stefan Claas wrote:
>> The reason why i ask, i started to use Thunderbird with Enigmail and
>> Enigmail shows me always Untrusted Good Signature with a 32bit key ID,
>> when i have not carefully verified the persons pub key and --lsign'ed
>> the pub-key. Showing only the long key id or the complete fingerprint
>> is imho more difficult to quickly memorize than an additionial shown
>> identicon (computed from the fingerprint).
> You shouldn't need to memorise it.  In Enigmail you can create rules
> for addresses to link to preferred keys, as well as set whether or not
> to encrypt all messages or just sign and so on.  Most MUAs which
> support GPG provide some method of doing this and GPG itself supports
> that function with group lists in the gpg.conf file.

 Thank you for the information, i will check it out.
>
> If the version of GPG you have installed supports it, you should
> probably add this to your gpg.conf:
>
>     trust-model tofu+pgp
>     tofu-default-policy unknown
>
> That will gradually build a more practical web-of-trust which keeps
> track of seen keys for you.

 I use GPGTools and therefore can't use it yet.
>
>> P.S. With scallion it took me only seconds/or a minute to generate
>> a fake pub-key with the same 32bit key id, on my old notebook.
> Yes, this has been possible for a long time now.  Most people use a
> 64-bit view for that reason.  This is now the default view in GPG 2.1,
> along with displaying the full finterprint.  If you do not have GPG
> 2.1.x installed, such as if you're using GPGTools on OS X or GPG4Win,
> then add "keyid-format 0xLONG" to your gpg.conf file.
>
I did that, but Enigmail still shows me the short key-id. :-(

Regards
Stefan




From rjh at sixdemonbag.org  Sun Jun  4 12:50:12 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 4 Jun 2017 06:50:12 -0400
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
Message-ID: <f16c8620-daee-166c-b0b5-3edb3dfe54eb@sixdemonbag.org>

> P.S. With scallion it took me only seconds/or a minute to generate
> a fake pub-key with the same 32bit key id, on my old notebook.

The question then becomes how hard it would be to forge a qidenticon.
There's not a whole lot of entropy there.


From fabian.hammerle at gmail.com  Sat Jun  3 00:48:50 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Sat, 3 Jun 2017 00:48:50 +0200
Subject: scute / firefox: cannot connect to GPG agent
Message-ID: <20170602224850.GA16711@arma-nova>

Hi,

I am trying to setup Scute (http://scute.org/) so I can use my
authentication subkey for client authentication in Firefox.

I followed the steps in Scute's manual to setup Firefox.
http://scute.org/scute.html/Application-Configuration.html

My problem is that I keep getting these warnings whenever I launch
Firefox:
> scute: agent_connect: cannot connect to GPG agent: IPC connect call failed
> scute: scute_gpg_err_to_ck: Error occurred: No agent running (Unspecified source)

As far as I understand gpg-agent is running.

After reading http://scute.org/scute.html/Troubleshooting.html
I noticed that $GPG_AGENT_INFO was not set.

However, setting the path manually did not solve the problem:
$ gpgconf --list-dir agent-socket
> /run/user/1000/gnupg/S.gpg-agent
$ GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent firefox
> scute: agent_connect: cannot connect to GPG agent: IPC connect call failed
> scute: scute_gpg_err_to_ck: Error occurred: No agent running (Unspecified source
> [...]

Any ideas?

$ apt-cache policy scute | grep -i installed
> Installed: 1.5.0+git20151221.dc22111-2
$ gpg-agent --version | head -n 2
> gpg-agent (GnuPG) 2.1.18
> libgcrypt 1.7.6

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170603/96a5af7a/attachment.sig>

From stefan.claas at posteo.de  Sun Jun  4 13:35:34 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 13:35:34 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <f16c8620-daee-166c-b0b5-3edb3dfe54eb@sixdemonbag.org>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
 <f16c8620-daee-166c-b0b5-3edb3dfe54eb@sixdemonbag.org>
Message-ID: <338873bc-4afe-19df-763e-191f3e213585@posteo.de>

On 04.06.17 12:50, Robert J. Hansen wrote:
>> P.S. With scallion it took me only seconds/or a minute to generate
>> a fake pub-key with the same 32bit key id, on my old notebook.
> The question then becomes how hard it would be to forge a qidenticon.
> There's not a whole lot of entropy there.
I'm no cryptographer nor a programmer, but i think a visiualisation
of a fingerprint could be helpful, if it's bullet-proof.

Here's an image i run with the example go code provided. I replaced
the word "text" in the sample code with "0x0000"etc. and in the second
image with "0x1000"etc.

http://img5.fotos-hochladen.net/uploads/visualfingerprp9ohtdmbkr.png

Regards
Stefan





From dgouttegattat at incenp.org  Sun Jun  4 14:04:55 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 4 Jun 2017 14:04:55 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170602224850.GA16711@arma-nova>
References: <20170602224850.GA16711@arma-nova>
Message-ID: <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>

Hi,

On 06/03/2017 12:48 AM, Fabian Peter Hammerle wrote:
> As far as I understand gpg-agent is running.

Can you please check whether it is really the case? E.g., check that the 
socket indicated by "gpgconf --list-dir agent-socket" does exist?

> After reading http://scute.org/scute.html/Troubleshooting.html
> I noticed that $GPG_AGENT_INFO was not set.

Yes, GnuPG 2.1 does not use (nor set) that variable anymore. But Scute 
still needs it in order to locate the socket, especially now that the 
socket is no longer always located in $GNUPGHOME.

If I remember correctly, the problem goes like this:

1) Scute looks for GPG_AGENT_INFO
2) The variable does not exist, so Scute looks for the socket in $GNUPGHOME
3) The socket is not there (because it is now somewhere under 
[/var]/run), so Scute assume there's no running agent
4) Scute spawns a new agent with the --use-standard-socket option (which 
used to instruct the agent to create its listening socket in $GNUPGHOME, 
but which has no effect with GnuPG 2.1)
5) Scute still does not find the socket in $GNUPGHOME, and thus fails 
with "Cannot connect to GPG Agent"

To avoid this, you need both to set the GPG_AGENT_INFO variable and make 
sure that the agent is running before you start Firefox (simply calling 
"gpg-connect-agent /bye" is enough).


> However, setting the path manually did not solve the problem:
> $ gpgconf --list-dir agent-socket
>> /run/user/1000/gnupg/S.gpg-agent
> $ GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent firefox

The GPG_AGENT_INFO variable must have the following form: 
"PATH_TO_SOCKET:PID:VERSION", where PID is the running agent's process 
ID and VERSION is the version of the agent protocol (which must be 1). 
Otherwise Scute will ignore the variable.

So try instead:

GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox

(The PID can be set to zero because as far as I know Scute does not 
actually use that information.)

Hope that helps,

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/20170604/fe40d168/attachment.sig>

From ludwig at enigmail.net  Sun Jun  4 13:19:46 2017
From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=)
Date: Sun, 4 Jun 2017 13:19:46 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <41d72726-e10f-3bc6-a36a-c3e86d3eae66@posteo.de>
References: <d38f8e98-c964-1362-c43e-50a9086de180@posteo.de>
 <41d72726-e10f-3bc6-a36a-c3e86d3eae66@posteo.de>
Message-ID: <64c0d520-0915-16f0-c2c7-a7de49e11f50@enigmail.net>

On 04.06.17 12:39, Stefan Claas wrote:
> On 04.06.17 11:50, Ben McGinnes wrote:

(...)

>> then add "keyid-format 0xLONG" to your gpg.conf file.
>> 
> I did that, but Enigmail still shows me the short key-id. :-(

The next major version of Enigmail will show long keyIds everywhere.

Ludwig

-------------- 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/20170604/b66205ec/attachment.sig>

From stefan.claas at posteo.de  Sun Jun  4 15:42:42 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 15:42:42 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <64c0d520-0915-16f0-c2c7-a7de49e11f50@enigmail.net>
References: <d38f8e98-c964-1362-c43e-50a9086de180@posteo.de>
 <41d72726-e10f-3bc6-a36a-c3e86d3eae66@posteo.de>
 <64c0d520-0915-16f0-c2c7-a7de49e11f50@enigmail.net>
Message-ID: <7909c068-f1d6-ec65-d79c-4b895b8c52d7@posteo.de>

On 04.06.17 13:19, Ludwig H?gelsch?fer wrote:
> On 04.06.17 12:39, Stefan Claas wrote:
>> On 04.06.17 11:50, Ben McGinnes wrote:
> (...)
>
>>> then add "keyid-format 0xLONG" to your gpg.conf file.
>>>
>> I did that, but Enigmail still shows me the short key-id. :-(
> The next major version of Enigmail will show long keyIds everywhere.
>
Oh, that's good news! :-) Much appreciated!

Regards
Stefan


From kristian.fiskerstrand at sumptuouscapital.com  Sun Jun  4 20:29:31 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 4 Jun 2017 20:29:31 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
Message-ID: <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>

On 06/04/2017 11:21 AM, Stefan Claas wrote:
> The reason why i ask, i started to use Thunderbird with Enigmail and
> Enigmail shows me always Untrusted Good Signature with a 32bit key ID,
> when i have not carefully verified the persons pub key and --lsign'ed
> the pub-key. Showing only the long key id or the complete fingerprint
> is imho more difficult to quickly memorize than an additionial shown
> identicon (computed from the fingerprint).

I'm likely missing something there, but if having a reasonable assurance
the public keyblock in question should likely be lsigned by a local
CAkey anyways? Doing a manual graphical verification doesn't seem to
provide anythin in terms of security here.

-- 
----------------------------
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
----------------------------
Bene diagnoscitur, bene curatur
Something that is well diagnosed can be cured well

-------------- 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/20170604/6d9aac11/attachment-0001.sig>

From fabian.hammerle at gmail.com  Sun Jun  4 14:35:12 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Sun, 4 Jun 2017 14:35:12 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
Message-ID: <20170604123512.GA6749@arma-nova>

Hi,

Thanks for your reply!

> The GPG_AGENT_INFO variable must have the following form:
> "PATH_TO_SOCKET:PID:VERSION", where PID is the running agent's process ID
> and VERSION is the version of the agent protocol (which must be 1).
> Otherwise Scute will ignore the variable.
>
> So try instead:
>
> GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox

Unfortunately I still get the 'IPC connect call failed' warning:

$ gpg-connect-agent /bye
$ ps -p $(pidof gpg-agent)
> PID TTY          TIME CMD
> 25379 ?        00:00:09 gpg-agent
$ ls -la $(gpgconf --list-dir agent-socket)
> srwx------ 1 fabianpeter fabianpeter 0 Jun  4 14:09 /run/user/1000/gnupg/S.gpg-agent
$ GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox
> scute: agent_connect: cannot connect to GPG agent: IPC connect call failed
> scute: scute_gpg_err_to_ck: Error occurred: No agent running (Unspecified source)
>
> scute: agent_connect: cannot connect to GPG agent: IPC connect call failed
> scute: scute_gpg_err_to_ck: Error occurred: No agent running (Unspecified source)
>
$ firefox --version
> Mozilla Firefox 53.0.3

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170604/32fbae0c/attachment.sig>

From stefan.claas at posteo.de  Sun Jun  4 22:25:35 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 22:25:35 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
 <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>
Message-ID: <23c9ac3d-8d86-b956-3dc5-11d96a741fad@posteo.de>

On 04.06.17 20:29, Kristian Fiskerstrand wrote:
> On 06/04/2017 11:21 AM, Stefan Claas wrote:
>> The reason why i ask, i started to use Thunderbird with Enigmail and
>> Enigmail shows me always Untrusted Good Signature with a 32bit key ID,
>> when i have not carefully verified the persons pub key and --lsign'ed
>> the pub-key. Showing only the long key id or the complete fingerprint
>> is imho more difficult to quickly memorize than an additionial shown
>> identicon (computed from the fingerprint).
> I'm likely missing something there, but if having a reasonable assurance
> the public keyblock in question should likely be lsigned by a local
> CAkey anyways? Doing a manual graphical verification doesn't seem to
> provide anythin in terms of security here.
>
Call me stupid, i use(d) GnuPG not to much and i'm not a pro user like
many here on the list. But when i receive(d) a signed message the first
time,
from a user completey unknown to me i did not lsign his/her key. Instead i
verified always the fingerprint and the email headers a couple of times.

With Thunderbird/Enigmail (i can't speak for other apps) a user new to GnuPG
and and not savvy with checking email headers and not carefully checking the
fingerprint (he must click addionally on the Details button) and who has
never
signed a public key before would in my opinion have it easier if he would be
presented with an additional visual fingerprint imho, because he would
imediately
spot after the second email if the pub-key, he not yet lsigned, that
there is
something wrong.

If the visual fingerprint would be bullet-proof it would not hurt to
implement
such a feature, imho.

Hope that my suggestion is not to naive or to stupid!

Regards
Stefan


 



From kristian.fiskerstrand at sumptuouscapital.com  Sun Jun  4 22:32:09 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 4 Jun 2017 22:32:09 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <23c9ac3d-8d86-b956-3dc5-11d96a741fad@posteo.de>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
 <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>
 <23c9ac3d-8d86-b956-3dc5-11d96a741fad@posteo.de>
Message-ID: <68d5dc28-d880-44ca-b881-05790a0e0439@sumptuouscapital.com>

On 06/04/2017 10:25 PM, Stefan Claas wrote:
> With Thunderbird/Enigmail (i can't speak for other apps) a user new to GnuPG
> and and not savvy with checking email headers and not carefully checking the
> fingerprint (he must click addionally on the Details button) and who has
> never
> signed a public key before would in my opinion have it easier if he would be
> presented with an additional visual fingerprint imho, because he would
> imediately
> spot after the second email if the pub-key, he not yet lsigned, that
> there is
> something wrong.
> 
> If the visual fingerprint would be bullet-proof it would not hurt to
> implement
> such a feature, imho.

Any talk about visual inspection of consistency in fingerprint seems
like an implementation of a TOFU model rather than an actual trust
model? So instead of doing a manual visual inspection, you'd want the
tofu model in gpg 2.1?

-- 
----------------------------
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
----------------------------
"Action is the foundational key to all success"
(Pablo Picasso)

-------------- 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/20170604/da10ef12/attachment.sig>

From stefan.claas at posteo.de  Sun Jun  4 22:47:56 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 4 Jun 2017 22:47:56 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a050207d-6946-7c6a-d082-ed098420d179@posteo.de>
References: <a050207d-6946-7c6a-d082-ed098420d179@posteo.de>
Message-ID: <a32f7139-9d92-e6a8-f716-1dde0af65328@posteo.de>

On 04.06.17 22:32, Kristian Fiskerstrand wrote:

> On 06/04/2017 10:25 PM, Stefan Claas wrote:
>> With Thunderbird/Enigmail (i can't speak for other apps) a user new to GnuPG
>> and and not savvy with checking email headers and not carefully checking the
>> fingerprint (he must click addionally on the Details button) and who has
>> never
>> signed a public key before would in my opinion have it easier if he would be
>> presented with an additional visual fingerprint imho, because he would
>> imediately
>> spot after the second email if the pub-key, he not yet lsigned, that
>> there is
>> something wrong.
>>
>> If the visual fingerprint would be bullet-proof it would not hurt to
>> implement
>> such a feature, imho.
> Any talk about visual inspection of consistency in fingerprint seems
> like an implementation of a TOFU model rather than an actual trust
> model? So instead of doing a manual visual inspection, you'd want the
> tofu model in gpg 2.1?
>
I'm not yet familar with the TOFU model, but if it helps to spot a fake
pub key imediately, in addition to the regular trust-model i see no
reason why not.

Regards
Stefan



From ben at adversary.org  Sun Jun  4 23:24:42 2017
From: ben at adversary.org (Ben McGinnes)
Date: Mon, 5 Jun 2017 07:24:42 +1000
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
 <f939b7ac-430d-8f04-80d1-d319362702a2@sumptuouscapital.com>
Message-ID: <20170604212442.c6roz227t6gmo5ft@adversary.org>

On Sun, Jun 04, 2017 at 08:29:31PM +0200, Kristian Fiskerstrand wrote:
> On 06/04/2017 11:21 AM, Stefan Claas wrote:
>
>> The reason why i ask, i started to use Thunderbird with Enigmail
>> and Enigmail shows me always Untrusted Good Signature with a 32bit
>> key ID, when i have not carefully verified the persons pub key and
>> --lsign'ed the pub-key. Showing only the long key id or the
>> complete fingerprint is imho more difficult to quickly memorize
>> than an additionial shown identicon (computed from the
>> fingerprint).
> 
> I'm likely missing something there, but if having a reasonable
> assurance the public keyblock in question should likely be lsigned
> by a local CAkey anyways? Doing a manual graphical verification
> doesn't seem to provide anythin in terms of security here.


It's got nothing to do with security and everything to do with
providing a unique generated icon for each key so an end user can
personally identify the correct key based on coloured shapes instead
of a hexadecimal string.  Which is why I called it Gravatar for GPG.

It's not the sort of thing that should be in GPG itself, but there's
nothing stopping anyone from incorporating that kind of feature into a
key management tool.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170605/16607801/attachment.sig>

From ben at adversary.org  Mon Jun  5 01:05:14 2017
From: ben at adversary.org (Ben McGinnes)
Date: Mon, 5 Jun 2017 09:05:14 +1000
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a32f7139-9d92-e6a8-f716-1dde0af65328@posteo.de>
References: <a050207d-6946-7c6a-d082-ed098420d179@posteo.de>
 <a32f7139-9d92-e6a8-f716-1dde0af65328@posteo.de>
Message-ID: <20170604230514.bphbtw4ap6segu5i@adversary.org>

On Sun, Jun 04, 2017 at 10:47:56PM +0200, Stefan Claas wrote:
>
> I'm not yet familar with the TOFU model, but if it helps to spot a
> fake pub key imediately, in addition to the regular trust-model i
> see no reason why not.

That's pretty much exactly what it does.

TOFU stands for Trust On First Use, so even if a key is not explicitly
trusted or signed, GPG will maintain a record of the number of times a
signed message has been seen from it, associated user IDs and email
addresses and so on.  It will also report discrepancies.  It's pretty
much how most people had been unofficially handling things anyway in
order to favour encryption even with unknown parties.

It is, of course, another reason why people tend not to look back
after switching to GPG 2.1.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170605/e6bb11b5/attachment.sig>

From stefan.claas at posteo.de  Mon Jun  5 01:17:12 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 5 Jun 2017 01:17:12 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <20170604230514.bphbtw4ap6segu5i@adversary.org>
References: <a050207d-6946-7c6a-d082-ed098420d179@posteo.de>
 <a32f7139-9d92-e6a8-f716-1dde0af65328@posteo.de>
 <20170604230514.bphbtw4ap6segu5i@adversary.org>
Message-ID: <c18bc7f0-85c1-7a8f-9f2d-47806c28d02d@posteo.de>

On 05.06.17 01:05, Ben McGinnes wrote:
> On Sun, Jun 04, 2017 at 10:47:56PM +0200, Stefan Claas wrote:
>> I'm not yet familar with the TOFU model, but if it helps to spot a
>> fake pub key imediately, in addition to the regular trust-model i
>> see no reason why not.
> That's pretty much exactly what it does.
>
> TOFU stands for Trust On First Use, so even if a key is not explicitly
> trusted or signed, GPG will maintain a record of the number of times a
> signed message has been seen from it, associated user IDs and email
> addresses and so on.  It will also report discrepancies.  It's pretty
> much how most people had been unofficially handling things anyway in
> order to favour encryption even with unknown parties.
>
> It is, of course, another reason why people tend not to look back
> after switching to GPG 2.1.
>

Thank you very much for your explanation! This sounds excellent!
Hope i can see this soon in GPGTools implemented too.

Regards
Stefan


From fabian.hammerle at gmail.com  Mon Jun  5 10:20:03 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Mon, 5 Jun 2017 10:20:03 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170604123512.GA6749@arma-nova>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova>
Message-ID: <20170605082003.GA25374@arma-nova>

I just cloned Scute from git://git.gnupg.org/scute.git
(commit 10a19467bc2a95b4aa91176924a91be427d3157a)

The error messages changed (compared to my initial mail):

$ GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 firefox
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x8010000b)
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: detected reader ''
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x8010000b)
> gpg-agent[2998]: card has S/N: D276000[...]
> scdaemon[2999]: detected reader 'Yubico Yubikey 4 OTP+U2F+CCID 00 00'
> scdaemon[2999]: detected reader ''
> scdaemon[2999]: pcsc_connect failed: sharing violation (0x8010000b)
[repeating rapidly]

pcscd reports:
> pcscd[3001]: 01000753 winscard.c:284:SCardConnect() Error Reader Exclusive

As far as I know, only gnupg accesses my smartcard.

Decryption, signing, and ssh authentication work as usual.

Restarting gpg-agent, scdaemon, pcscd and rebooting did not change anything.

Does anyone know what might cause the 'sharing violation' error?

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170605/c9d77652/attachment.sig>

From dgouttegattat at incenp.org  Mon Jun  5 11:49:48 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 5 Jun 2017 11:49:48 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170605082003.GA25374@arma-nova>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova> <20170605082003.GA25374@arma-nova>
Message-ID: <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>

On 06/05/2017 10:20 AM, Fabian Peter Hammerle wrote:
> Does anyone know what might cause the 'sharing violation' error?

I am not sure. Can you check that after starting Firefox, you still have 
only one GPG-Agent and one Scdaemon running?

If you run the following command:

   $ gpg-connect-agent "SCD GETINFO pid" /bye

(which returns the PID of the running Scdaemon), do you get the same PID 
than the one displayed in your error messages?


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/20170605/1052530e/attachment.sig>

From dkg at fifthhorseman.net  Sun Jun  4 22:20:50 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 04 Jun 2017 16:20:50 -0400
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
References: <a20435f4-14f1-6bdb-8a8c-de284fcf1f08@posteo.de>
Message-ID: <87poejec7x.fsf@fifthhorseman.net>

Hi Stefan--

I think you're asking about two sort of different things.

on the one hand, you're asserting that the 32-bit keyid isn't sufficient
for any sort of cryptographic verification.  that's absolutely correct,
and enigmail really shouldn't be exposing the 32-bit keyID to humans
where it can avoid doing so.  I've written more about this here:

  https://debian-administration.org/users/dkg/weblog/105

You're also asking about graphical representations of the cryptographic
identity -- a graphical representation of a fingerprint, basically.
The community has seen several different proposals of graphical
fingerprint representations in the past, and every one i've seen
gets stuck when faced with the hard questions.  In particular:

 * is the goal *recognition* of the fingerprint (i.e. "does this
   fingerprint look sufficiently similar to the one i've seen in the
   past for me to remember it?"), or is the goal *distinguishing* from a
   maliciously-crafted fingerprint (i.e. "am i certain that this
   fingerprint is an exact match of one that i expect to see from the
   peer who i think should have been signing this e-mail?")

 * In the "recognition" model, it's not clear that any
   cryptographically-strong guarantees are made to the user.  So why tie
   the visual identity to the cryptographic identity if we think it's
   spoofable?

 * in the "distinguishing" model, it's not clear that any of the schemes
   i've seen are actually better for most humans against a dedicated
   attacker who crafts fingerprints to make visual identities that look
   similar.  do you have any studies showing this capability against a
   motivated and technically capable attacker?

I'd generally think that if you're looking for a tool to help people
remember and recognize keys that they've seen before, then a mail user
agent is in a great position to do exactly that: just tell the user
explicitly what they've seen before, how often, etc.  why depend on the
human visual cortex or on human ability for numeric recall?

      --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/20170604/2a900399/attachment.sig>

From stefan.claas at posteo.de  Mon Jun  5 16:22:26 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 5 Jun 2017 16:22:26 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
Message-ID: <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>

On 04.06.17 22:20, Daniel Kahn Gillmor wrote:

> Hi Stefan--
>
> I think you're asking about two sort of different things.
>
> on the one hand, you're asserting that the 32-bit keyid isn't sufficient
> for any sort of cryptographic verification.  that's absolutely correct,
> and enigmail really shouldn't be exposing the 32-bit keyID to humans
> where it can avoid doing so.  I've written more about this here:
>
>   https://debian-administration.org/users/dkg/weblog/105

Very good article Daniel i will re-read and save it as reference
and let other people know about it.


> You're also asking about graphical representations of the cryptographic
> identity -- a graphical representation of a fingerprint, basically.
> The community has seen several different proposals of graphical
> fingerprint representations in the past, and every one i've seen
> gets stuck when faced with the hard questions.  In particular:
>
>  * is the goal *recognition* of the fingerprint (i.e. "does this
>    fingerprint look sufficiently similar to the one i've seen in the
>    past for me to remember it?"), or is the goal *distinguishing* from a
>    maliciously-crafted fingerprint (i.e. "am i certain that this
>    fingerprint is an exact match of one that i expect to see from the
>    peer who i think should have been signing this e-mail?")
>
>  * In the "recognition" model, it's not clear that any
>    cryptographically-strong guarantees are made to the user.  So why tie
>    the visual identity to the cryptographic identity if we think it's
>    spoofable?
>
>  * in the "distinguishing" model, it's not clear that any of the schemes
>    i've seen are actually better for most humans against a dedicated
>    attacker who crafts fingerprints to make visual identities that look
>    similar.  do you have any studies showing this capability against a
>    motivated and technically capable attacker?

No, of course i have not. My thoughts as a not so-skilled GnuPG user
would be that it helps users detecting (assuming it's bullet-proof) a
proper key from a fake key more easily if they have not yet signed
(locally) a public key while they already exchanged a couple of emails.
I can speak only of Thunderbird/Enigmail wich i use now. It gives a
user the usual "Untrusted Good Signatur" and i have to click also on
the Details button to carefully verify the fingerprint from an addional
list to see if the key belongs to the person the signature claims. An
additional visual fingerprint would make that proccess for me easier,
if it's bullet-proof.

> I'd generally think that if you're looking for a tool to help people
> remember and recognize keys that they've seen before, then a mail user
> agent is in a great position to do exactly that: just tell the user
> explicitly what they've seen before, how often, etc.  why depend on the
> human visual cortex or on human ability for numeric recall?

I could imagine that Joe user average may not always look at mail headers
very carefully for a little typo in the from: or reply-to: header in his
mail client or web-mailer.

Regards
Stefan




From stefan.claas at posteo.de  Mon Jun  5 17:40:18 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 5 Jun 2017 17:40:18 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
Message-ID: <89de7397-d863-79de-9daa-5416d1c2906d@posteo.de>

On 05.06.17 16:22, Stefan Claas wrote:
> On 04.06.17 22:20, Daniel Kahn Gillmor wrote:
>
>> I'd generally think that if you're looking for a tool to help people
>> remember and recognize keys that they've seen before, then a mail user
>> agent is in a great position to do exactly that: just tell the user
>> explicitly what they've seen before, how often, etc.  why depend on the
>> human visual cortex or on human ability for numeric recall?
> I could imagine that Joe user average may not always look at mail headers
> very carefully for a little typo in the from: or reply-to: header in his
> mail client or web-mailer.
And another thought, since this thread says "app developers". How would
services like StartMail, ProtonMail or gmx.de for example handle this...?

If i remember correctly users have not the possibillity to sign someone
elses pub-key when they both use the same service. If someone gains
unauthorized access to one account and use his own fake pub key...?!

Regards
Stefan




From fabian.hammerle at gmail.com  Mon Jun  5 19:04:55 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Mon, 5 Jun 2017 19:04:55 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova>
 <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
 <20170605113527.GA575@arma-nova>
 <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
Message-ID: <20170605170455.GA26371@arma-nova>

> Could you perform your tests again with Scute debugging turned on?

Scute log when launching Firefox with Yubikey unplugged:

> scute debug init: flags=0xff
> scute: scute_agent_initialize: Establishing connection to gpg-agent

After plugging in the Yubikey:

> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General error
> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General error
[repeating rapidly]

Due to scute 'rejecting certificate' I just removed my current
certificate for the auth subkey from gpgsm and created / imported a new
self-signed certificate:

$ gpgsm --gen-key
> [...]
> Please select what kind of key you want:
>    (1) RSA
>    (2) Existing key
>    (3) Existing key from card
> Your selection? 3
> Serial number of the card: D27600[...]
> Available keys:
>    (1) C2E04B00B3F087DB143B4BB6411813BA220ED4BA OPENPGP.1
>    (2) FDB0E6A955AA1194D369A942B8EF10E6C66E0BB4 OPENPGP.2
>    (3) 22BD35D43F4D748110C935CC6B8D13575306F89B OPENPGP.3
> Your selection? 3
> [...]
> Create self-signed certificate? (y/N) y
> These parameters are used:
>     Key-Type: card:OPENPGP.3
>     Key-Length: 1024
>     Key-Usage: sign
>     Serial: random
>     Name-DN: CN=scute test,C=AT
> 
> Proceed with creation? (y/N) y
> Now creating self-signed certificate.  This may take a while ...
> gpgsm: about to sign the certificate for key: &22BD35D43F4D748110C935CC6B8D13575306F89B
> gpgsm: certificate created
> Ready.
> -----BEGIN CERTIFICATE-----
> [...]

I am not sure why gpgsm wrote
>     Key-Length: 1024
although the actual key length is 4096:

$ gpg --list-secret-keys --with-keygrip | grep -B 1 22BD35D43F4D748110C935CC6B8D13575306F89B
> ssb>  rsa4096 2016-12-25 [A]
>       Keygrip = 22BD35D43F4D748110C935CC6B8D13575306F89B

However, the newly created certificate seams to be valid:

$ gpgsm --list-secret-keys --with-keygrip --with-validation 'scute test' 
> [...]
>        Issuer: /CN=scute test/C=AT
>       Subject: /CN=scute test/C=AT
>      validity: 2017-06-05 16:40:48 through 2063-04-05 17:00:00
>      key type: 4096 bit RSA
>     key usage: digitalSignature nonRepudiation
>  chain length: unlimited
>   fingerprint: 0E:1F:DC:B0:43:FD:1B:93:70:76:C0:2A:B1:22:8E:3A:B0:8B:D4:52
>       keygrip: 22BD35D43F4D748110C935CC6B8D13575306F89B
>      card s/n: D276000[...]
>   [certificate is good]

Anyway, Scute still logs the same error message:

> scute: scute_agent_get_cert: got certificate from card with length 259
> scute: asn1_get_element: wrong element in lookup path
> scute: scute_attr_prv: rejecting certificate: could not get subject: General error
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170605/4511a85f/attachment-0001.sig>

From dgouttegattat at incenp.org  Mon Jun  5 19:37:27 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 5 Jun 2017 19:37:27 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170605170455.GA26371@arma-nova>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova> <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
 <20170605113527.GA575@arma-nova>
 <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
 <20170605170455.GA26371@arma-nova>
Message-ID: <f4d8b312-25dd-55a2-a585-761fa90f2672@incenp.org>

On 06/05/2017 07:04 PM, Fabian Peter Hammerle wrote:
>> scute: scute_agent_get_cert: got certificate from card with length 259
OK, this is weird. 259 bytes seems too short for a X.509 certificate, 
especially one based on 4096-bit public key (for comparison, my own 
2048-bit certificate is 1587 bytes).

Maybe an error occured when the certificate was stored on the Yubikey, 
and the certificate there is actually truncated?

Could you extract the certificate from the smartcard and have a look at 
it? Run gpg in card-edit mode, and at the prompt, use the (undocumented) 
readcert command to save the certificate to a file

   $ gpg --card-edit

   gpg/card> readcert 3 > file.der
   gpg/card> quit

Then inspect the contents of file.der, using e.g. openssl:

   $ openssl x509 -inform DER -in file.der -text


> Due to scute 'rejecting certificate' I just removed my current
> certificate for the auth subkey from gpgsm and created / imported a new
> self-signed certificate:
 > [...]
> Anyway, Scute still logs the same error message:

Did you import your new certificate onto the Yubikey? Because 
independently of what your gpgsm store may contain, Scute will always 
try to fetch the certificate from the token itself.

-------------- 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/20170605/0e9ec9c8/attachment.sig>

From fabian.hammerle at gmail.com  Mon Jun  5 19:54:47 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Mon, 5 Jun 2017 19:54:47 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <f4d8b312-25dd-55a2-a585-761fa90f2672@incenp.org>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova>
 <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
 <20170605113527.GA575@arma-nova>
 <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
 <20170605170455.GA26371@arma-nova>
 <f4d8b312-25dd-55a2-a585-761fa90f2672@incenp.org>
Message-ID: <20170605175447.GA5039@arma-nova>

> Did you import your new certificate onto the Yubikey? Because independently
> of what your gpgsm store may contain, Scute will always try to fetch the
> certificate from the token itself.

Ah, I didn't know I had to write the certificate onto the Yubikey.
I only imported it into gpgsm following this guide: 
http://scute.org/scute.html/Certificate-Preparation.html

> Could you extract the certificate from the smartcard and have a look at it?
>   $ gpg --card-edit
>   gpg/card> readcert 3 > file.der
>   gpg/card> quit

$ od -x file.der
> 0000000 217f 0082 ffff ffff ffff ffff ffff ffff
> 0000020 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0000400 ffff 00ff
> 0000403

I just tried to write the certificate onto the Yubiykey:

$ gpg --edit-card
Reader ...........: Yubico Yubikey 4 OTP U2F CCID 00 00
[...]
ssb>  rsa4096/3AA08B6113EC625C  created: 2016-12-25  expires: never
[...]
gpg/card> admin
Admin commands are allowed
gpg/card> writecert 3 <new-cert.der
gpg: error writing certificate to card: Provided object is too large

Do I have to choose a smaller key size?

Thanks a lot

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170605/bbbf3fd4/attachment.sig>

From dgouttegattat at incenp.org  Mon Jun  5 20:29:30 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 5 Jun 2017 20:29:30 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170605175447.GA5039@arma-nova>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova> <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
 <20170605113527.GA575@arma-nova>
 <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
 <20170605170455.GA26371@arma-nova>
 <f4d8b312-25dd-55a2-a585-761fa90f2672@incenp.org>
 <20170605175447.GA5039@arma-nova>
Message-ID: <8d2a2f43-2345-fa59-8b11-7c560a243dad@incenp.org>

On 06/05/2017 07:54 PM, Fabian Peter Hammerle wrote:
> Ah, I didn't know I had to write the certificate onto the Yubikey.

You do not *have* to; Scute can fetch the certificate both from the 
token itself, or from the gpgsm store. But it will try first to fetch it 
from the token.

Storing the certificate on the token itself instead on relying on the 
gpgsm store allows you to use your token on a machine that is not your 
usual machine.


>> Could you extract the certificate from the smartcard and have a look at it?
>>    $ gpg --card-edit
>>    gpg/card> readcert 3 > file.der
>>    gpg/card> quit
> 
> $ od -x file.der
>> 0000000 217f 0082 ffff ffff ffff ffff ffff ffff
>> 0000020 ffff ffff ffff ffff ffff ffff ffff ffff
>> *
>> 0000400 ffff 00ff
>> 0000403

I don't pretend to be a X.509 or ASN1 expert (far from it!), but this 
does not look like a X.509 certificate at all.


> gpg: error writing certificate to card: Provided object is too large
> 
> Do I have to choose a smaller key size?

Check the maximal size supported by the Yubikey:

   $ gpg-connect-agent 'SCD GETATTR EXTCAP' /bye

The output should be a line like the following:

   S EXTCAP gc=1+ki=1+fc=1+pd=1+mcl3=2048+aac=1+sm=0+si=5+dec=0+bt=0

The maximal size for the certificate to be stored on the token is 
indicated by the "mcl3" value (so, 2048 bytes in this example). Your 
DER-encoded certificate should not be bigger than that.

But if it happens that your Yubikey does not support 4096-bit 
certificates, and you still want such a certificate, then you could 
simply erase the (corrupted) certificate on the Yubikey. As I said 
above, Scute will fetch the certificate from the gpgsm store if it 
cannot find it on the token.

As far as I know there is no command in the gpg card editor to erase the 
certificate, but I *think* using the writecert command with /dev/null as 
input should do the trick (I have not tested).

-------------- 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/20170605/ad5e96ef/attachment.sig>

From stefan.claas at posteo.de  Mon Jun  5 21:11:37 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 5 Jun 2017 21:11:37 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <89de7397-d863-79de-9daa-5416d1c2906d@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <89de7397-d863-79de-9daa-5416d1c2906d@posteo.de>
Message-ID: <745ed925-5723-343f-96e3-08436025f0cf@posteo.de>

On 05.06.17 17:40, Stefan Claas wrote:
> And another thought, since this thread says "app developers". How would
> services like StartMail, ProtonMail or gmx.de for example handle this...?
>
> If i remember correctly users have not the possibillity to sign someone
> elses pub-key when they both use the same service. If someone gains
> unauthorized access to one account and use his own fake pub key...?!
>
Appologies to all, i had a brain fart with this unauthorized access
sentence and
a fake pub key.

Regards
Stefan



From dkg at fifthhorseman.net  Mon Jun  5 22:26:56 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 05 Jun 2017 16:26:56 -0400
Subject: Fwd: Re: Question for app developers,
 like Enigmail etc. - Identicons
In-Reply-To: <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
Message-ID: <87vaoach9r.fsf@fifthhorseman.net>

On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>  * in the "distinguishing" model, it's not clear that any of the schemes
>>    i've seen are actually better for most humans against a dedicated
>>    attacker who crafts fingerprints to make visual identities that look
>>    similar.  do you have any studies showing this capability against a
>>    motivated and technically capable attacker?
>
> No, of course i have not. My thoughts as a not so-skilled GnuPG user
> would be that it helps users detecting (assuming it's bullet-proof)

what does "bullet-proof" mean, specifically?  I ask this not for
pedantry's sake, but because clearly stating the problem makes it
possible to know whether a specific solution is applicable.

> a proper key from a fake key more easily if they have not yet signed
> (locally) a public key while they already exchanged a couple of
> emails.  I can speak only of Thunderbird/Enigmail wich i use now. It
> gives a user the usual "Untrusted Good Signatur" and i have to click
> also on the Details button to carefully verify the fingerprint from an
> addional list to see if the key belongs to the person the signature
> claims. An additional visual fingerprint would make that proccess for
> me easier, if it's bullet-proof.

It sounds to me like you're saying that you find the key verification
and certification steps as implemented by enigmail to be
difficult-to-use.  You wouldn't be the only person who has that
impression.

But i don't see how a graphical icon solves that problem.  Isn't it a
workflow problem, and not a visual-comparison problem?  If there's a
standard thing (comparison, lookup, verification) you expect to be able
to do with the tool, the tool should make that thing easy and simple to
do.

What specifically is the thing that you're trying to do when you click
"Details" and verify the fingerprint (from what list?)?  Enigmail itself
can compare fingerprints far better than you or i can, even if there is
a graphical representation involved :) Maybe there's a different
question or different interface Enigmail ought to offer in the "Details"
view entirely?

>> I'd generally think that if you're looking for a tool to help people
>> remember and recognize keys that they've seen before, then a mail user
>> agent is in a great position to do exactly that: just tell the user
>> explicitly what they've seen before, how often, etc.  why depend on the
>> human visual cortex or on human ability for numeric recall?
>
> I could imagine that Joe user average may not always look at mail headers
> very carefully for a little typo in the from: or reply-to: header in his
> mail client or web-mailer.

i agree with you that users won't look at mail headers closely, which is
why the e-mail client (the "mail user agent", or MUA) should be the
thing to do the comparison, and to make it very clear to the user when
something is amiss.  But that still doesn't answer the question of what
the MUA should actually be trying to compare and what results it should
be highlighting.

   --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/20170605/cb0e5a49/attachment.sig>

From fabian.hammerle at gmail.com  Mon Jun  5 22:37:26 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Mon, 5 Jun 2017 22:37:26 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <8d2a2f43-2345-fa59-8b11-7c560a243dad@incenp.org>
References: <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova>
 <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
 <20170605113527.GA575@arma-nova>
 <ea485313-e189-82c8-79c7-6cf956e49da0@incenp.org>
 <20170605170455.GA26371@arma-nova>
 <f4d8b312-25dd-55a2-a585-761fa90f2672@incenp.org>
 <20170605175447.GA5039@arma-nova>
 <8d2a2f43-2345-fa59-8b11-7c560a243dad@incenp.org>
Message-ID: <20170605203726.GA20645@arma-nova>

> The maximal size for the certificate to be stored on the token is indicated
> by the "mcl3" value (so, 2048 bytes in this example). Your DER-encoded
> certificate should not be bigger than that.

$ gpg-connect-agent 'SCD GETATTR EXTCAP' /bye | grep -Po 'mcl3=\d+'  
mcl3=1216

My certificate is slightly larger:

$ gpgsm --export '&22BD35[...]6F89B' | wc --bytes
1432

> As far as I know there is no command in the gpg card editor to erase the
> certificate, but I *think* using the writecert command with /dev/null as
> input should do the trick (I have not tested).

Unfortunately I was not successful using /dev/null:

gpg/card> writecert 3 < /dev/null
gpg: error writing certificate to card: Invalid argument

> Scute can fetch the certificate both from the 
> token itself, or from the gpgsm store. But it will try first to fetch it 
> from the token.

To test my configuration I temporarily disabled the call to
scute_agent_get_cert():

diff --git a/src/gpgsm.c b/src/gpgsm.c
index 2a2906f..5c2674a 100644
--- a/src/gpgsm.c
+++ b/src/gpgsm.c
@@ -124,7 +124,7 @@ scute_gpgsm_get_cert (char *grip, int no, cert_get_cb_t cert_get_cb, void *hook)
 
   /* If the key is from the card, we might get the certificate from
      the card as well.  */
-  if (no >= 0)
+  if (false && no >= 0)
     {
       struct cert cert;

The Certificate Manager now shows an entry under 'Your Certificates'.

I was able to login via Client Auth using my Yubikey.
Amazing :-)

Thank you very much for your continuous help!

I'll try to find a way to erase the certificate from the Yubikey.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: certificate_manager.png
Type: image/png
Size: 10967 bytes
Desc: not available
URL: </pipermail/attachments/20170605/160c977b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170605/160c977b/attachment-0001.sig>

From fabian.hammerle at gmail.com  Mon Jun  5 13:35:27 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Mon, 5 Jun 2017 13:35:27 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
References: <20170602224850.GA16711@arma-nova>
 <98659d89-e39e-e0e1-c8cf-9a8272e89a7f@incenp.org>
 <20170604123512.GA6749@arma-nova>
 <20170605082003.GA25374@arma-nova>
 <f928e050-1942-0a7b-25f3-fc5fcc5b201e@incenp.org>
Message-ID: <20170605113527.GA575@arma-nova>

> Can you check that after starting Firefox, you still have
> only one GPG-Agent and one Scdaemon running?

Before launching Firefox:

$ ps aux | grep -P '(scdaemon|gpg-agent)'
> fabianp+  3242 [...] gpg-agent --homedir /home/fabianpeter/.gnupg --use-standard-socket --daemon
> fabianp+  3518 [...] grep -P (scdaemon|gpg-agent)
> fabianp+ 26815 [...] scdaemon --multi-server
$ gpg-connect-agent "SCD GETINFO pid" /bye
> D 26815
> OK

Strangely enough Firefox does no longer write anything to stdout or stderr.
Unfortunately, I don't know what changed since I received the error
message last time.

$ export GPG_AGENT_INFO=$(gpgconf --list-dir agent-socket):0:1 
$ echo $GPG_AGENT_INFO
> /run/user/1000/gnupg/S.gpg-agent:0:1
$ firefox &
> [1] 3616

While Firefox was running no other instances of gpg-agent or scdaemon
were launched:

$ ps aux | grep -P '(scdaemon|gpg-agent)'                     
> fabianp+  3242 [...] gpg-agent --homedir /home/fabianpeter/.gnupg --use-standard-socket --daemon
> fabianp+  3746 [...] grep -P (scdaemon|gpg-agent)
> fabianp+ 26815 [...] scdaemon --multi-server

With the Yubikey unplugged Firefox' Device Manager now shows a menu item
'GnuPG Smart Card Daemon':
Status: Not Present
Description: GnuPG Smart Card Daemon
Manufacturer: g10 Code GmbH
HW Version: 2.1
FW Version: 1.5

When I plug in my Yubikey and re-open the Device Manager most values are empty:
change to:
Status: Not Present
Description: [empty]
Manufacturer:  [empty]
HW Version: [empty]
FW Version: [empty]

(Screenshots attached)

While Firefox is running I am not able to access my smartcard with gpg:

$ date | gpg -e | gpg # gpg test         
> gpg: encrypted with 4096-bit RSA key, ID CD90DBE8B7C5FE43, created 2016-10-16
>       "Fabian Peter Hammerle <fabian at hammerle.me>"
> gpg: public key decryption failed: No SmartCard daemon
> gpg: decryption failed: No secret key
$ gpg-connect-agent "SCD GETINFO pid" /bye
> ERR 67108983 No SmartCard daemon <GPG Agent>

Before I loaded Scute in Firefox the very first time,
I used gpgsm the create a x509 cert for the auth subkey (pos. 3) on the Yubikey.
I signed the certificate with another key in gpgsm (also on smartcard).

$ gpgsm --list-secret-keys --with-validation 0x33C90BD1
> [...]
>        Issuer: /CN=Fabian Peter Hammerle/C=AT
>       Subject: /CN=Fabian Peter Hammerle/C=AT
>      validity: 2017-06-02 21:59:08 through 2017-07-02 21:59:08
>      key type: 4096 bit RSA
>     key usage: digitalSignature nonRepudiation
> ext key usage: clientAuth (suggested)
>   fingerprint: 94:F5:1F:46:07:5D:28:68:8A:F3:A6:39:DB:BD:E4:4E:33:C9:0B:D1
>      card s/n: D276000[...]
>   [certificate is good]

Thank you very much for your support!

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: device-manager_yubikey-unplugged.png
Type: image/png
Size: 39290 bytes
Desc: Device Manager with Yubikey unplugged
URL: </pipermail/attachments/20170605/02c8a0c5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: device-manager_yubikey-plugged-in.png
Type: image/png
Size: 33280 bytes
Desc: Device Manager with Yubikey plugged in
URL: </pipermail/attachments/20170605/02c8a0c5/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170605/02c8a0c5/attachment-0001.sig>

From wk at gnupg.org  Tue Jun  6 00:03:07 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Jun 2017 00:03:07 +0200
Subject: [Announce] GnuPG Funding Campaign Launched
Message-ID: <871sqyytwk.fsf@wheatstone.g10code.de>


Independent Encryption Software, GnuPG, Needs Financial Support

  D?sseldorf, Germany --- Tuesday, June 6, 2017.  The GnuPG Project
  today announced the launch of a funding campaign to further support
  and improve its leading mail and data encryption software, GnuPG.  The
  campaign aims to secure 15000 Euro per month in recurring donations
  from individual donors to finance the development of their free
  software.  Donations can be made at the newly reworked website:

    <https://gnupg.org/donate/>

  Activists, journalists, lawyers, and many others rely on GnuPG to
  protect their communication.  The software guards emails, files, and
  programs from government and criminal snooping and spying on Windows,
  Mac, and Linux.  And, more than two-thirds of the servers running the
  Internet rely on GnuPG to verify the integrity of system updates.

  Ongoing government spying revelations have shown how little of our
  information is really safe.  GnuPG is one of the few tools that can
  offer real protection, free of commercial interests.  Edward Snowden
  used it to encrypt his communications with journalists.  Many
  institutions use GnuPG because by using an open standard they can be
  sure that they will always be able to access their data.

  The 6 person development team is currently financed from a successful
  campaign in early 2015, regular donations from the Linux Foundation,
  Stripe, Facebook, and a few paid development projects.  To ensure
  long-term stability the new campaign focuses on recurring donations
  and not one-time donations.  Says lead developer Werner Koch: ?We want
  to continue our work in the long term.  But, we want to do so in such
  a way that our first loyalty is unambiguously to the general public.
  This means making sure that a majority of our funding comes from
  individual donors, and not corporations.?

  To highlight GnuPG's role in protecting data, user stories from 26
  organizations including activist groups, news organizations, lawyers,
  and companies from all over the world have been collected.  Their
  testimonials are presented in daily changing videos on the campaign
  site.


About GNU Privacy Guard (GnuPG)

  Since 1997, GnuPG has allowed individuals and companies to encrypt and
  sign data and communication using the well-established and highly
  interoperable OpenPGP standard.  It comes with state of the art
  cryptography and features a versatile key management system.  GnuPG,
  also known as GPG or sometimes incorrectly as PGP, can be used
  standalone, but has all features needed for easy integration with
  other software.  It is used as the core cryptography engine of a
  wealth of other applications: For example Thunderbird with Enigmail,
  Gpg4win, and GPGTools.  Most operating systems use GnuPG's signing
  ability to protect system updates against malicious attempts to
  introduce backdoors.  GnuPG is available free of charge, and comes
  with all source code to allow anyone to audit the software.
  <https://gnupg.org>


About g10 Code GmbH

  g10 Code GmbH is the privately owned legal entity behind the GnuPG
  Project.  They employ all developers and keep all profits for the
  development of GnuPG and related free software.
  <https://gnupg.org/imprint.html>


### Media contacts:

  Neal H. Walfield, Werner Koch
  Email: media at gnupg.org
  Phone: +49-2104-4938797 (during European business hours)
  Twitter: @gnupg
  OpenPGP: 370C 0FC3 1293 B339 61C1 FC20 B367 1B93 6BA8 BCB2
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From stefan.claas at posteo.de  Tue Jun  6 01:24:43 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Jun 2017 01:24:43 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <87vaoach9r.fsf@fifthhorseman.net>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
Message-ID: <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>

On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
> On Mon 2017-06-05 16:22:26 +0200, Stefan Claas wrote:
>>>  * in the "distinguishing" model, it's not clear that any of the schemes
>>>    i've seen are actually better for most humans against a dedicated
>>>    attacker who crafts fingerprints to make visual identities that look
>>>    similar.  do you have any studies showing this capability against a
>>>    motivated and technically capable attacker?
>> No, of course i have not. My thoughts as a not so-skilled GnuPG user
>> would be that it helps users detecting (assuming it's bullet-proof)
> what does "bullet-proof" mean, specifically?  I ask this not for
> pedantry's sake, but because clearly stating the problem makes it
> possible to know whether a specific solution is applicable.
For me it means that the idendicons should be visually easy to read
and cryptographically secure. Sorry that i have no better explanation.
>
>> a proper key from a fake key more easily if they have not yet signed
>> (locally) a public key while they already exchanged a couple of
>> emails.  I can speak only of Thunderbird/Enigmail wich i use now. It
>> gives a user the usual "Untrusted Good Signatur" and i have to click
>> also on the Details button to carefully verify the fingerprint from an
>> addional list to see if the key belongs to the person the signature
>> claims. An additional visual fingerprint would make that proccess for
>> me easier, if it's bullet-proof.
> It sounds to me like you're saying that you find the key verification
> and certification steps as implemented by enigmail to be
> difficult-to-use.  You wouldn't be the only person who has that
> impression.
>
> But i don't see how a graphical icon solves that problem.  Isn't it a
> workflow problem, and not a visual-comparison problem?  If there's a
> standard thing (comparison, lookup, verification) you expect to be able
> to do with the tool, the tool should make that thing easy and simple to
> do.
>
> What specifically is the thing that you're trying to do when you click
> "Details" and verify the fingerprint (from what list?)?  Enigmail itself
> can compare fingerprints far better than you or i can, even if there is
> a graphical representation involved :) Maybe there's a different
> question or different interface Enigmail ought to offer in the "Details"
> view entirely?
Well, in the past, before i started using this email combination i
used web based email accounts copy and pasted the message into
a text editor and had no auto key retrival and looked up WWW
key servers to download the required key to verify the sig. I had
not often communications back then. So this was an acceptable
workflow for me.

With the current set-up it's all automatic and my understanding is
that in case i would receive a fake message my set-up would download
the fake key, display it as "Untrusted Good Signature" too, because i
have not yet locally signed the key. Therefore i click details to see the
fingerprint (which i can't memorizy) and look it up again. Maybe, as
casual user who never used this set-up before, i make a fundamentally
mistake in understanding of how the auto retrieve and verify function
works. I mean why is a Details button there to see a fingerprint which
i believe nobody can memorize in the first place? It must serve a purpose,
or not?

>>> I'd generally think that if you're looking for a tool to help people
>>> remember and recognize keys that they've seen before, then a mail user
>>> agent is in a great position to do exactly that: just tell the user
>>> explicitly what they've seen before, how often, etc.  why depend on the
>>> human visual cortex or on human ability for numeric recall?
>> I could imagine that Joe user average may not always look at mail headers
>> very carefully for a little typo in the from: or reply-to: header in his
>> mail client or web-mailer.
> i agree with you that users won't look at mail headers closely, which is
> why the e-mail client (the "mail user agent", or MUA) should be the
> thing to do the comparison, and to make it very clear to the user when
> something is amiss.  But that still doesn't answer the question of what
> the MUA should actually be trying to compare and what results it should
> be highlighting.
>
For me a MUA is passive and happily accepts what he receives, whether it's
correct content or not, so i can't answer that question, sorry.

Regards
Stefan
 





From dkg at fifthhorseman.net  Tue Jun  6 04:11:27 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 05 Jun 2017 22:11:27 -0400
Subject: Fwd: Re: Question for app developers,
 like Enigmail etc. - Identicons
In-Reply-To: <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
Message-ID: <87k24pdfw0.fsf@fifthhorseman.net>

On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>> what does "bullet-proof" mean, specifically? 
>
> For me it means that the idendicons should be visually easy to read
> and cryptographically secure. Sorry that i have no better explanation.

here's one way to try to frame the question: Imagine the situation as a
game, where you have two players on one team, "defense" named Alice and
Bob; Alice wants to send a message to Bob.  Another player on the
opposing team, "offense", is named Mallory, is trying to send a message
to Bob as well, but trying to trick Bob into thinking that the incoming
message comes from Alice.

The way the game is played, either Alice or Mallory gets to send a
message.  Bob has to decide whether the message actually came from
Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
the "offense" wins.  The game is played multiple times.

Is that the scenario you're thinking of?  If so, does the defense need
to win 100% of the time over thousands of games?  or is it acceptable
for offense to win occasionally?

In any case question is: how much work does Mallory need to do to get
Bob to make a mistake?  How frequently can Mallory trick Bob into
accepting mail from her as though it were from Alice?  Conversely, how
many messages that were actually from Alice can Bob accidentally reject
without making Alice upset enough to give up on the entire
communications scheme?

When you frame the problem this way, you can start thinking more
concretely about what "bulletproof" means, and you can actually design
user trials to test proposals.

There are probably other ways to concretize the problem, this is just
one that i've come up with.  But without a concrete way to understand
what we're looking for, words like "bullet proof" or "easy to read" or
"cryptographically secure" are tough to get people to agree on.

I suspect (as discussed upthread) that TOFU will have better metrics for
"defense" at the game described above than any attempt that involves
asking people to visually distinguish deterministically-generated
identicons.  But i don't know, because i haven't tested it.

                   --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/20170605/d238487f/attachment.sig>

From duane at nofroth.com  Tue Jun  6 05:30:30 2017
From: duane at nofroth.com (Duane Whitty)
Date: Tue, 6 Jun 2017 00:30:30 -0300
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <87k24pdfw0.fsf@fifthhorseman.net>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
 <87k24pdfw0.fsf@fifthhorseman.net>
Message-ID: <909a3f97-955d-d9c7-f9bf-97997c1e95ca@nofroth.com>



On 17-06-05 11:11 PM, Daniel Kahn Gillmor wrote:
> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>>> what does "bullet-proof" mean, specifically? 
>>
>> For me it means that the idendicons should be visually easy to read
>> and cryptographically secure. Sorry that i have no better explanation.
> 
> here's one way to try to frame the question: Imagine the situation as a
> game, where you have two players on one team, "defense" named Alice and
> Bob; Alice wants to send a message to Bob.  Another player on the
> opposing team, "offense", is named Mallory, is trying to send a message
> to Bob as well, but trying to trick Bob into thinking that the incoming
> message comes from Alice.
> 
> The way the game is played, either Alice or Mallory gets to send a
> message.  Bob has to decide whether the message actually came from
> Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
> the "offense" wins.  The game is played multiple times.
> 
> Is that the scenario you're thinking of?  If so, does the defense need
> to win 100% of the time over thousands of games?  or is it acceptable
> for offense to win occasionally?
> 
> In any case question is: how much work does Mallory need to do to get
> Bob to make a mistake?  How frequently can Mallory trick Bob into
> accepting mail from her as though it were from Alice?  Conversely, how
> many messages that were actually from Alice can Bob accidentally reject
> without making Alice upset enough to give up on the entire
> communications scheme?
> 
> When you frame the problem this way, you can start thinking more
> concretely about what "bulletproof" means, and you can actually design
> user trials to test proposals.
> 
> There are probably other ways to concretize the problem, this is just
> one that i've come up with.  But without a concrete way to understand
> what we're looking for, words like "bullet proof" or "easy to read" or
> "cryptographically secure" are tough to get people to agree on.
> 
> I suspect (as discussed upthread) that TOFU will have better metrics for
> "defense" at the game described above than any attempt that involves
> asking people to visually distinguish deterministically-generated
> identicons.  But i don't know, because i haven't tested it.
> 
>                    --dkg
> 

Excellent scenario and explanation Daniel, thank you!  I firmly believe
your suspicions regarding identicons will be fully shown accurate.

However, I am having difficulty following how TOFU would/could provide
better metrics for the "defense" side of the game.  As I understand the
concept of TOFU (Trust On First Use), when you receive a signed email
gpg tests that signature against the key retrieved from the public key
servers associated with the email.

To me this says nothing about whether you are actually communicating
with who you think you are communicating with.  It justs says "Yes, the
signature on the email you received was generated by the same key
associated with that email address on the public key servers."

This is not enough to convince me I am communicating with someone I
know.  For instance, I have not imported even one of the many keys I
receive from emails to this mailing list into my keyring because there
is no trust there.  And when I move to gpg 2.1 I will make certain that
TOFU is not enabled.

I think TOFU could potentially be a win for Mallory.  TOFU may make
people more likely to take for granted that they are communicating with
a trusted party because the email they received says it's someone they
trust and GPG says it's a good signature from alice at example.com.

The problem with this is that they never communicated with Alice to
learn her email address is actually alice at trustme.com.

My personal opinion, for whatever that is worth, is that TOFU is going
to have people sending signed/encrypted email back and forth to each
other without them having done the work to ensure they are actually
communicating with their intended parties.  Trust takes work.

Once the work on establishing identities has been done and trust has
been established there is no need to remember keys because the key will
be locally associated with the email address belonging to the trusted
party you wish to communicate with.

Best Regards,
Duane

-- 
Duane Whitty
duane at nofroth.com

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

From peter at digitalbrains.com  Tue Jun  6 12:46:34 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 6 Jun 2017 12:46:34 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <909a3f97-955d-d9c7-f9bf-97997c1e95ca@nofroth.com>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
 <87k24pdfw0.fsf@fifthhorseman.net>
 <909a3f97-955d-d9c7-f9bf-97997c1e95ca@nofroth.com>
Message-ID: <c025b5f7-28c9-0bef-35e2-311f0a4b5b2f@digitalbrains.com>

On 06/06/17 05:30, Duane Whitty wrote:
> As I understand the concept of TOFU (Trust On First Use), when you
> receive a signed email gpg tests that signature against the key
> retrieved from the public key servers associated with the email.

TOFU is about *consistency*. It says: this e-mail is signed by the same
key you've seen on all the earlier messages you received from this
e-mail address. It keeps count, and alerts you when all of a sudden you
start receiving signatures made by a different key.

Note that it can also be combined with the Web of Trust. You could use
TOFU just to track consistency and not award validity to keys, or you
could use TOFU to award marginal validity and obtain the remaining
validity from, e.g., marginally trusted Web of Trust signatures.

But TOFU isn't for everyone, and neither is the Web of Trust. It's your
call.

By the way, it is my feeling Stefan Claas is looking for TOFU. The
Identicon scheme feels like TOFU with the database on external storage,
to wit, the user's brain :). Better to store that database on disk,
IMHO. The (only) net loss is that there is no synchronization between
different devices.

My Enigmail works with TOFU, although I can't see any statistics. But it
correctly awards a green bar with "Good signature" to my TOFU-verified keys.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From dgouttegattat at incenp.org  Tue Jun  6 14:08:54 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue,  6 Jun 2017 14:08:54 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170605203726.GA20645@arma-nova>
References: <20170605203726.GA20645@arma-nova>
Message-ID: <20170606120854.6744-1-dgouttegattat@incenp.org>

> I'll try to find a way to erase the certificate from the Yubikey.

You may also try the patch below. It should allow Scute to ignore the
data read from the token if it does not look like a proper DER-encoded
certificate. It's not a fool-proof check, but it should already catch
a lot of cases (including yours).

-- >8 --
Subject: Add safety check against bad card certificate.

* src/agent.c (scute_agent_get_cert): Reject card certificate if
it does not start with an ASN.1 sequence tag.

Signed-off-by: Damien Goutte-Gattat <dgouttegattat at incenp.org>
---
 src/agent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/agent.c b/src/agent.c
index 75d4933..d6615af 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -1284,7 +1284,7 @@ scute_agent_get_cert (int no, struct cert *cert)
   err = assuan_transact (agent_ctx, cmd, get_cert_data_cb, &cert_s,
 			 NULL, NULL, NULL, NULL);
   /* Just to be safe... */
-  if (!err && cert_s.cert_der_len <= 16)
+  if (!err && (cert_s.cert_der_len <= 16 || cert_s.cert_der[0] != 0x30))
     {
       DEBUG (DBG_INFO, "bad card certificate rejected");
       err = gpg_error (GPG_ERR_BAD_CERT);
-- 
2.9.0



From andrewg at andrewg.com  Tue Jun  6 15:14:49 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 6 Jun 2017 14:14:49 +0100
Subject: Certification-only key
In-Reply-To: <3f15da52-fb41-d6df-bd82-24bdd272bbd6@digitalbrains.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
 <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
 <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>
 <3f15da52-fb41-d6df-bd82-24bdd272bbd6@digitalbrains.com>
Message-ID: <c7df476e-878e-0e25-be3a-da9c381cee05@andrewg.com>

On 2017/06/02 18:25, Peter Lebbing wrote:
> I did later realize that if somebody used a timestamping service to
> timestamp a document you signed, you would have to argue that you
> already published your secret key before that time.

To protect against this, one would use a timestamping service to sign
the secret key publication, thereby proving the publication was earlier
than the forgery.

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/20170606/17d5f7ab/attachment.sig>

From fabian.hammerle at gmail.com  Tue Jun  6 15:20:36 2017
From: fabian.hammerle at gmail.com (Fabian Peter Hammerle)
Date: Tue, 6 Jun 2017 15:20:36 +0200
Subject: scute / firefox: cannot connect to GPG agent
In-Reply-To: <20170606120854.6744-1-dgouttegattat@incenp.org>
References: <20170605203726.GA20645@arma-nova>
 <20170606120854.6744-1-dgouttegattat@incenp.org>
Message-ID: <20170606132036.GA30825@arma-nova>

> You may also try the patch below.
> [...]
> * src/agent.c (scute_agent_get_cert): Reject card certificate if
> it does not start with an ASN.1 sequence tag.

The batch works for me using Yubikey 4. 

Thanks,

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170606/09f4bfad/attachment.sig>

From ndk.clanbo at gmail.com  Tue Jun  6 14:39:56 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 6 Jun 2017 14:39:56 +0200
Subject: Key management for archives
Message-ID: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>

Hello all.

I'd need to handle an archive with many big files (~200GB each). The
system receives "plain" files in a "dropbox" folder, then encrypts 'em
to a (set of) public key(s) (no corresponding private keys on this
system) and deletes source files.
Up to this point it should be OK (a cronnable script with a lot of
checks is mostly ready).

But my big doubt is how to handle archive reading in an efficient way.
The naive way would be to let an authorized user decode the file and
reencode it for the requester, but that would mean that this authorized
user should have quite a lot of space available (twice the dataset size,
at least).
Is it possible to "extract" the used session key, so that the requester
just ignores the asymmetric crypto and just uses the symmetric key to
decode the file? Drawbacks? Other ideas?

Tks,
 Diego


From peter at digitalbrains.com  Tue Jun  6 15:38:58 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 6 Jun 2017 15:38:58 +0200
Subject: Certification-only key
In-Reply-To: <c7df476e-878e-0e25-be3a-da9c381cee05@andrewg.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
 <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
 <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>
 <3f15da52-fb41-d6df-bd82-24bdd272bbd6@digitalbrains.com>
 <c7df476e-878e-0e25-be3a-da9c381cee05@andrewg.com>
Message-ID: <326bd68f-5646-c4eb-4026-186aaae8f0d8@digitalbrains.com>

On 06/06/17 15:14, Andrew Gallagher wrote:
> To protect against this, one would use a timestamping service to sign
> the secret key publication, thereby proving the publication was earlier
> than the forgery.

I think you're going backwards about this.

This is how I understand it:

Until the key is expired, you want people to recognize your signatures
as valid and issued by you. Hence, you don't publicly disclose your
secret key. You only do this once your key is expired.

Henceforth, you want to plausibly deny you issued those signatures which
you in fact *did* issue. As long as there is no timestamping service,
you could claim the signature to be a recent forgery with a forged time
of signature.

However, if somebody has used a timestamping service to prove the
signature was in fact really issued before the key expired, you'll have
to claim that you had already disclosed the secret key back then. Even
though you didn't. So you can't prove it with a timestamping service
because it is not actually the case.

And then there is the issue that the timestamp in general proves the
data *existed* at the time of issuance. But this doesn't prove the data
was disclosed publicly. Obviously the secret key existed, nobody is
questioning that. To prove it was disclosed, you'll need to go through
some more steps.

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/20170606/f305236b/attachment.sig>

From andrewg at andrewg.com  Tue Jun  6 16:38:46 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 6 Jun 2017 15:38:46 +0100
Subject: Certification-only key
In-Reply-To: <326bd68f-5646-c4eb-4026-186aaae8f0d8@digitalbrains.com>
References: <20050905144140.GA27381@tofu.mamane.lu>
 <20050905174607.GB1750@jabberwocky.com>
 <20050905193550.GB2713@tofu.mamane.lu>
 <20050905204646.GC1750@jabberwocky.com>
 <20050905230300.GB7834@tofu.mamane.lu>
 <20101004152225.GA15991@capsaicin.mamane.lu> <4CAA129E.6080105@dougbarton.us>
 <20170531125209.ynfowhtxyfwujw2u@capsaicin.mamane.lu>
 <04ec37f5-99a2-8fe6-35bc-d89b6c22a872@digitalbrains.com>
 <20170602124256.kzcqnvvtxrqocvpf@capsaicin.mamane.lu>
 <49c22d30-4c94-a065-4e96-6a1caca6c746@digitalbrains.com>
 <21f0d013-9a45-c7f9-3e0e-e59119b28ea2@andrewg.com>
 <3f15da52-fb41-d6df-bd82-24bdd272bbd6@digitalbrains.com>
 <c7df476e-878e-0e25-be3a-da9c381cee05@andrewg.com>
 <326bd68f-5646-c4eb-4026-186aaae8f0d8@digitalbrains.com>
Message-ID: <48797431-724e-78d0-2952-a6066fea0dd9@andrewg.com>

On 2017/06/06 14:38, Peter Lebbing wrote:
> However, if somebody has used a timestamping service to prove the
> signature was in fact really issued before the key expired, you'll have
> to claim that you had already disclosed the secret key back then. Even
> though you didn't. So you can't prove it with a timestamping service
> because it is not actually the case.

Ah, yes. I was thinking of the case where the signature was forged, not
one where the signature was genuine.

Repudiable signatures, like ephemeral keys, only really work in a
synchronous environment such as chat or TLS. The signatures are checked
automatically and thrown away before being presented to the user, which
allows them to be valid for very short periods of time (on the order of
seconds). The secret keys are then published (within the secure channel)
immediately. In such an environment, any discrepancy found by referring
to a timestamping service can be explained away by clock drift.

This reminds me of the side discussion at openPGPconf re ephemeral keys
for email. At some point you have to admit that data-in-motion and
data-at-rest security are fundamentally different beasts.

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/20170606/8b551f92/attachment-0001.sig>

From stefan.claas at posteo.de  Tue Jun  6 18:07:18 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Jun 2017 18:07:18 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <87k24pdfw0.fsf@fifthhorseman.net>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
 <87k24pdfw0.fsf@fifthhorseman.net>
Message-ID: <4df4bdbf-bda1-9259-4e5b-621b650d4e39@posteo.de>

On 06.06.17 04:11, Daniel Kahn Gillmor wrote:
> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>>> what does "bullet-proof" mean, specifically? 
>> For me it means that the idendicons should be visually easy to read
>> and cryptographically secure. Sorry that i have no better explanation.
> here's one way to try to frame the question: Imagine the situation as a
> game, where you have two players on one team, "defense" named Alice and
> Bob; Alice wants to send a message to Bob.  Another player on the
> opposing team, "offense", is named Mallory, is trying to send a message
> to Bob as well, but trying to trick Bob into thinking that the incoming
> message comes from Alice.
>
> The way the game is played, either Alice or Mallory gets to send a
> message.  Bob has to decide whether the message actually came from
> Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
> the "offense" wins.  The game is played multiple times.
>
> Is that the scenario you're thinking of?  If so, does the defense need
> to win 100% of the time over thousands of games?  or is it acceptable
> for offense to win occasionally?
>
> In any case question is: how much work does Mallory need to do to get
> Bob to make a mistake?  How frequently can Mallory trick Bob into
> accepting mail from her as though it were from Alice?  Conversely, how
> many messages that were actually from Alice can Bob accidentally reject
> without making Alice upset enough to give up on the entire
> communications scheme?
>
>
In old times I would say if Bob and Alice don't know each other and they
have no clue how that particular security software works it should be that
the second message send to one person the security software already detects
forgeries and reports that to a person. However, with that thinking it does
not guarantee that Bob knows that Alice is not Eve. Therefore qualified CA's
in my opinion are mandatory where each user in each country has to register
with his/her id-card so that it's guaranteed that Alice is not Eve.

Regards
Stefan








From stefan.claas at posteo.de  Tue Jun  6 18:39:50 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Jun 2017 18:39:50 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <4df4bdbf-bda1-9259-4e5b-621b650d4e39@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de>
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
 <87k24pdfw0.fsf@fifthhorseman.net>
 <4df4bdbf-bda1-9259-4e5b-621b650d4e39@posteo.de>
Message-ID: <3ba784b3-c0ed-b8ba-3a28-32ba16497c5c@posteo.de>

On 06.06.17 18:07, Stefan Claas wrote:
> On 06.06.17 04:11, Daniel Kahn Gillmor wrote:
>> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
>>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>>>> what does "bullet-proof" mean, specifically? 
>>> For me it means that the idendicons should be visually easy to read
>>> and cryptographically secure. Sorry that i have no better explanation.
>> here's one way to try to frame the question: Imagine the situation as a
>> game, where you have two players on one team, "defense" named Alice and
>> Bob; Alice wants to send a message to Bob.  Another player on the
>> opposing team, "offense", is named Mallory, is trying to send a message
>> to Bob as well, but trying to trick Bob into thinking that the incoming
>> message comes from Alice.
>>
>> The way the game is played, either Alice or Mallory gets to send a
>> message.  Bob has to decide whether the message actually came from
>> Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
>> the "offense" wins.  The game is played multiple times.
>>
>> Is that the scenario you're thinking of?  If so, does the defense need
>> to win 100% of the time over thousands of games?  or is it acceptable
>> for offense to win occasionally?
>>
>> In any case question is: how much work does Mallory need to do to get
>> Bob to make a mistake?  How frequently can Mallory trick Bob into
>> accepting mail from her as though it were from Alice?  Conversely, how
>> many messages that were actually from Alice can Bob accidentally reject
>> without making Alice upset enough to give up on the entire
>> communications scheme?
>>
>>
> In old times I would say if Bob and Alice don't know each other and they
> have no clue how that particular security software works it should be that
> the second message send to one person the security software already detects
> forgeries and reports that to a person. However, with that thinking it does
> not guarantee that Bob knows that Alice is not Eve. Therefore qualified CA's
> in my opinion are mandatory where each user in each country has to register
> with his/her id-card so that it's guaranteed that Alice is not Eve.
>
> Regards
> Stefan
>
Correction... instead "has" to register "may register"...

Regards
Stefan




From stefan.claas at posteo.de  Tue Jun  6 20:12:27 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Jun 2017 20:12:27 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
Message-ID: <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>

On 06.06.17 12:46, Peter Lebbing wrote:

> On 06/06/17 05:30, Duane Whitty wrote:
>> As I understand the concept of TOFU (Trust On First Use), when you
>> receive a signed email gpg tests that signature against the key
>> retrieved from the public key servers associated with the email.

> TOFU is about *consistency*. It says: this e-mail is signed by the same
> key you've seen on all the earlier messages you received from this
> e-mail address. It keeps count, and alerts you when all of a sudden you
> start receiving signatures made by a different key.

Is TOFU verifying the email address from the from: header of the message
and then compares it with the email address in the UID? I ask, because
if i would use a free form UID with no email address, or i use an Anon
Remailer with a nym account where both email addresses are not identical.
>
> Note that it can also be combined with the Web of Trust. You could use
> TOFU just to track consistency and not award validity to keys, or you
> could use TOFU to award marginal validity and obtain the remaining
> validity from, e.g., marginally trusted Web of Trust signatures.
>
> But TOFU isn't for everyone, and neither is the Web of Trust. It's your
> call.
>
> By the way, it is my feeling Stefan Claas is looking for TOFU. The
> Identicon scheme feels like TOFU with the database on external storage,
> to wit, the user's brain :). Better to store that database on disk,
> IMHO. The (only) net loss is that there is no synchronization between
> different devices.

I just installed modern GnuPG and used it with two inline PGP messages from
Usenet and i like it. :-)
>
> My Enigmail works with TOFU, although I can't see any statistics. But it
> correctly awards a green bar with "Good signature" to my TOFU-verified keys.
>
I tried also with Enigmail under OS X but when checking the signatures here
from the list members i always get the blue "Untrusted Good Signature".

Regards
Stefan




From grossws at gmail.com  Tue Jun  6 20:13:44 2017
From: grossws at gmail.com (Konstantin Gribov)
Date: Tue, 06 Jun 2017 18:13:44 +0000
Subject: Key management for archives
In-Reply-To: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
Message-ID: <CALvb29ybmrtMFhEUuSd2R74nVhJF_W1FniHK301+b=wZjny3Sg@mail.gmail.com>

Diego,

I can think of more simpler approach:
- generate secure random for symmetrical data encryption key (DEK);
- encrypt that key for authorized users on their public keys;
- encrypt data itself with something like ChaCha20 or AES in appropriate
mode.

In such case you could give end user an archive, info about cipher and its
mode and a data encryption key.

Of course, such way doesn't allow you to revoke access to DEK since each
user could just decrypt his own copy.

A bit more complicated approach is to use two level system:
- generate data encryption key (DEK);
- generate key encryption key (KEK) for each authorized user;
- encrypt each user's KEK on each user's public key;
- create a table (tsv/csv or any other format) with some user id and DEK
encrypted with corresponding KEK and store it with data;
- encrypt data with DEK.

Then to decrypt archive authorized user decrypts his KEK, use it to decrypt
DEK and gives end user archive, DEK and cipher info.
To revoke a key you just remove entry from table with KEKs.

Both methods are naive and gives end user DEK, so it's better to reencrypt
archive after that to rotate DEK.

In both approaches authorized user can get encrypted archive, retrieve DEK
and reecrypt archive with stream or block cipher with very small overhead
(block size at minimum).

Also, a lot depends on your threat model. Since I don't know what risks are
you planning to avoid with original scheme I just assumed that primary risk
is 3rdparty archive storage compromise.


On Tue, Jun 6, 2017 at 4:39 PM NdK <ndk.clanbo at gmail.com> wrote:

> Hello all.
>
> I'd need to handle an archive with many big files (~200GB each). The
> system receives "plain" files in a "dropbox" folder, then encrypts 'em
> to a (set of) public key(s) (no corresponding private keys on this
> system) and deletes source files.
> Up to this point it should be OK (a cronnable script with a lot of
> checks is mostly ready).
>
> But my big doubt is how to handle archive reading in an efficient way.
> The naive way would be to let an authorized user decode the file and
> reencode it for the requester, but that would mean that this authorized
> user should have quite a lot of space available (twice the dataset size,
> at least).
> Is it possible to "extract" the used session key, so that the requester
> just ignores the asymmetric crypto and just uses the symmetric key to
> decode the file? Drawbacks? Other ideas?
>
> Tks,
>  Diego
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-- 

Best regards,
Konstantin Gribov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170606/6889f60e/attachment.html>

From ndk.clanbo at gmail.com  Tue Jun  6 22:03:09 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 6 Jun 2017 22:03:09 +0200
Subject: Key management for archives
In-Reply-To: <CALvb29ybmrtMFhEUuSd2R74nVhJF_W1FniHK301+b=wZjny3Sg@mail.gmail.com>
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
 <CALvb29ybmrtMFhEUuSd2R74nVhJF_W1FniHK301+b=wZjny3Sg@mail.gmail.com>
Message-ID: <418673a7-e0e0-714f-d26b-a75ce8c82010@gmail.com>

Il 06/06/2017 20:13, Konstantin Gribov ha scritto:

> I can think of more simpler approach:
> - generate secure random for symmetrical data encryption key (DEK);
> - encrypt that key for authorized users on their public keys;
> - encrypt data itself with something like ChaCha20 or AES in appropriate
> mode.
Problem: the symmetric key (DEK) must remain in plaintext on the server.
It's a relatively secure setup, but I prefer *not* to risk. Even if that
means a slightly more involved process. If the server gets compromised,
the attacker can only access new datasets, at most, not the historic
archive.
Moreover, with your proposal, once I give an user access to one file,
he'll be able to decrypt *any* other file too.
If I keep track of who can access every dataset and some day I find some
datasets are being used "illegally", I can restrict the suspects.

> Of course, such way doesn't allow you to revoke access to DEK since each
> user could just decrypt his own copy. 
Since encrypting to a public key generates a random session key, the
session key gives access only to that single file. Obviously that access
can not be easily revoked (the user could have saved a plaintext copy
anyway, so that's not a big issue).

> A bit more complicated approach is to use two level system:
> - generate data encryption key (DEK);
> - generate key encryption key (KEK) for each authorized user;
> - encrypt each user's KEK on each user's public key;
> - create a table (tsv/csv or any other format) with some user id and DEK
> encrypted with corresponding KEK and store it with data;
> - encrypt data with DEK.
That's the same of encrypting the DEK with multiple public keys.
The problem is that I don't know in advance the users that will need access.
IIRC there was some method to retrieve the session key and replace the
public key part with another recipient...

> Both methods are naive and gives end user DEK, so it's better to
> reencrypt archive after that to rotate DEK.
That would be a big problem: archives must remain static (to avoid
troubles with offsite replication).

> Also, a lot depends on your threat model. Since I don't know what risks
> are you planning to avoid with original scheme I just assumed that
> primary risk is 3rdparty archive storage compromise.
Well, I handle the storage (currently 100TB, going to grow to 150TB
soon). I want to avoid that an attacker could gain access to the whole
archive if he succeeds in compromising the server. Clients are out of my
perimeter (= not my problem).

BYtE,
 Diego


From chtj2 at srcf.net  Tue Jun  6 20:46:59 2017
From: chtj2 at srcf.net (Charlie Jonas)
Date: Tue, 6 Jun 2017 19:46:59 +0100
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
Message-ID: <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>

On 2017-06-06 19:12, Stefan Claas wrote:
> I tried also with Enigmail under OS X but when checking the signatures here
> from the list members i always get the blue "Untrusted Good Signature".

Yes I get this as well. Interestingly whatever trust level I give keys,
Enigmail on OSX seems to want to make the bar blue regardless.

-- 
Charlie Jonas                 chtj2 at srcf.net


From stefan.claas at posteo.de  Tue Jun  6 22:19:57 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 6 Jun 2017 22:19:57 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
Message-ID: <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>

On 06.06.17 20:46, Charlie Jonas wrote:
> On 2017-06-06 19:12, Stefan Claas wrote:
>> I tried also with Enigmail under OS X but when checking the signatures here
>> from the list members i always get the blue "Untrusted Good Signature".
> Yes I get this as well. Interestingly whatever trust level I give keys,
> Enigmail on OSX seems to want to make the bar blue regardless.
>
Thanks for confirming. Hopefully Ludwig still follows this thread and
can tell us why it's not working, as expected.

Regards
Stefan



From grossws at gmail.com  Tue Jun  6 22:40:05 2017
From: grossws at gmail.com (Konstantin Gribov)
Date: Tue, 06 Jun 2017 20:40:05 +0000
Subject: Key management for archives
In-Reply-To: <418673a7-e0e0-714f-d26b-a75ce8c82010@gmail.com>
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
 <CALvb29ybmrtMFhEUuSd2R74nVhJF_W1FniHK301+b=wZjny3Sg@mail.gmail.com>
 <418673a7-e0e0-714f-d26b-a75ce8c82010@gmail.com>
Message-ID: <CALvb29wvXsVzaUq61Nae0tK+uC+A8kObr5TW7FPYE6fA9HwxfQ@mail.gmail.com>

On Tue, Jun 6, 2017 at 11:03 PM NdK <ndk.clanbo at gmail.com> wrote:

> Il 06/06/2017 20:13, Konstantin Gribov ha scritto:
>
> > I can think of more simpler approach:
> > - generate secure random for symmetrical data encryption key (DEK);
> > - encrypt that key for authorized users on their public keys;
> > - encrypt data itself with something like ChaCha20 or AES in appropriate
> > mode.
> Problem: the symmetric key (DEK) must remain in plaintext on the server.
> It's a relatively secure setup, but I prefer *not* to risk. Even if that
> means a slightly more involved process. If the server gets compromised,
> the attacker can only access new datasets, at most, not the historic
> archive.
> Moreover, with your proposal, once I give an user access to one file,
> he'll be able to decrypt *any* other file too.
> If I keep track of who can access every dataset and some day I find some
> datasets are being used "illegally", I can restrict the suspects.

Sorry, I was misunderstood. I'll try to rephrase.

In first scheme DEK is never stored in plain text. It used while encrypting
archive and encrypted with gpg (or any other cryptographic means) and plain
text version is removed right after that.

Also, in this setup unique DEK is generated for each archive, so DEK for
one archive doesn't give user an access to any other archives.

> Both methods are naive and gives end user DEK, so it's better to
> > reencrypt archive after that to rotate DEK.
> That would be a big problem: archives must remain static (to avoid
> troubles with offsite replication).
>
Then you can reecrypt archive on one of the servers with new DEK dedicated
for that user. Or just let it be so. If user gained an access to archive he
could always decrypt same archive again.

Anyway with unique DEK for each archive giving user this key doesn't seems
to be an issue to me. Just reread my original answer with this assumption,
it could put a new face on it.

-- 

Best regards,
Konstantin Gribov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170606/7d6b1fc8/attachment.html>

From ndk.clanbo at gmail.com  Tue Jun  6 22:54:14 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 6 Jun 2017 22:54:14 +0200
Subject: Key management for archives
In-Reply-To: <CALvb29wvXsVzaUq61Nae0tK+uC+A8kObr5TW7FPYE6fA9HwxfQ@mail.gmail.com>
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
 <CALvb29ybmrtMFhEUuSd2R74nVhJF_W1FniHK301+b=wZjny3Sg@mail.gmail.com>
 <418673a7-e0e0-714f-d26b-a75ce8c82010@gmail.com>
 <CALvb29wvXsVzaUq61Nae0tK+uC+A8kObr5TW7FPYE6fA9HwxfQ@mail.gmail.com>
Message-ID: <36942c2c-cc4d-6067-08d5-6e29e2f730ad@gmail.com>

Il 06/06/2017 22:40, Konstantin Gribov ha scritto:

> In first scheme DEK is never stored in plain text. It used while
> encrypting archive and encrypted with gpg (or any other cryptographic
> means) and plain text version is removed right after that.
There's a big misunderstanding here: the encryption must be automatic,
not done by an user. So, IIUC, the scheme you're suggesting given this
limitation is what GPG already does when encrypting to a recipient's pk:
generate a symmetric key, use it to encrypt the file, encrypt that key
with recipient's pk. And it (hopefully) does every step in the safest
possible way -- surely much safer than anything I could do from a script.
What I'd need is some way to "extract" that temporary key (using the
recipient's secret key, obv) and then immediately reencrypt it with
another recipient's pk. Or (that's equivalent) add another recipient to
the already encrypted file, w/o reencrypting the whole file.

> Then you can reecrypt archive on one of the servers with new DEK
> dedicated for that user. Or just let it be so. If user gained an access
> to archive he could always decrypt same archive again. 
As I said, that's not a problem: once he's had access to a file, that's
"forever" (I cannot avoid he saves the file in plaintext). But he must
not be able to decrypt other files from the archive.

BYtE,
 Diego


From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jun  7 00:04:01 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 6 Jun 2017 23:04:01 +0100
Subject: Fwd: Re: Question for app developers,
 like Enigmail etc. - Identicons
In-Reply-To: <4df4bdbf-bda1-9259-4e5b-621b650d4e39@posteo.de>
References: <3a1ad789-508d-7404-7f7c-9f01e3bb46c9@posteo.de> 
 <4dc77503-83c2-346c-0470-f769bd7592af@posteo.de>
 <87vaoach9r.fsf@fifthhorseman.net>
 <10d59611-18cb-77bb-5fa7-1c263033ced6@posteo.de>
 <87k24pdfw0.fsf@fifthhorseman.net>
 <4df4bdbf-bda1-9259-4e5b-621b650d4e39@posteo.de>
Message-ID: <214094812.20170606230401@riseup.net>

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



On Tuesday 6 June 2017 at 5:07:18 PM, in
<mid:4df4bdbf-bda1-9259-4e5b-621b650d4e39 at posteo.de>, Stefan Claas
wrote:-


> Therefore qualified CA's
> in my opinion are mandatory where each user in each
> country [may] register
> with his/her id-card so that it's guaranteed that
> Alice is not Eve.

Assuming the users trust both the CA and the entity that issued the
id-card.

- --
Best regards

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

Two rights do not make a wrong. They make an airplane.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWTcm2l8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5M0bAQCxPC1qcxn5/hKvd2Acm5bCxO9czxoa6JJos3mKgooLfQD9Hn/AoaC/CJwS
61kzBoo4xFtC0caacvg0qevQelC0ywGJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWTcm8F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8B9LB/9SVOXj12DpY6urk83Skh1MgXPq
WKE44LwOUQKRuSldrWlwnf4Ox4X6chKU3qH4PjVhMFGZNC5wrAkavIesPzqLzKAy
md4tzOaFTWHRXoymG4aVGEOE/l3T9JOQLh8pYRlNDUknNbSATE6FpMF6bDXAPe/N
Jy/Hfq1Gt2QMBQWgff/tXOCUSB5rSvyCcecBqbtLB5Civ4TIQkXHJ7rHkLGzN5eL
/TsqxvcKKo54ngDJbQEu6yPH6BPiMJztaMZIBmF7c6wkHxRngtFQhVu2rJt3rlez
9BTnEIJi0jn64ZMX2XnhdRImU7BfzEKjB86hbrhirInXKwlHQ7oQqZz0dTmJ
=CPjn
-----END PGP SIGNATURE-----



From stefan.claas at posteo.de  Wed Jun  7 07:55:24 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 07:55:24 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. -
 Identicons
In-Reply-To: <6a8ade07-ae18-88c8-d8df-68223899b813@posteo.de>
References: <6a8ade07-ae18-88c8-d8df-68223899b813@posteo.de>
Message-ID: <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>

On 07.06.17 00:04, MFPA wrote:

>
>
> On Tuesday 6 June 2017 at 5:07:18 PM, in
> <mid:4df4bdbf-bda1-9259-4e5b-621b650d4e39 at posteo.de>, Stefan Claas
> wrote:-
>
>
> > Therefore qualified CA's
> > in my opinion are mandatory where each user in each
> > country [may] register
> > with his/her id-card so that it's guaranteed that
> > Alice is not Eve.
>
> Assuming the users trust both the CA and the entity that issued the
> id-card.
>
Well, that's debatable. As an example:

My old pub-key had a sig3 from a well known german computer
magazine, which i believe a lot of people here in Germany would trust.
Their procedure was that you attend their booth at electronic fairs
show up with your id-card and a fillet out form, containing your data and
the pub key data. They carefully checked then the filled out form with
your id-card. So it's imo compareable with key signing parties you
attend. But who guarantees that an id-card is not fake with this
classical procedure?

My new pub-key bears a sig3 from a german CA which is run on
behalf of  our interior ministry. People may not trust our government
but the procedure how the pub-key was verified* tells me that the
sig3 issued to that person is correct.

*our new german id-card contains a chip and when you look at it
i would say this sort of modern id-card can not be faked.

The procedure went like this: I inserted my id-card in a certified
card reader, which i purchased, startet the german certified id-card
software "AusweisApp2" to connect to the CA Server and the server
checked my id-card online and after verification send the signed
pub-key to my email address. Can this procedure be faked by
criminals etc.? I doubt it.

Regards
Stefan
 





From andrewg at andrewg.com  Wed Jun  7 08:50:28 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 7 Jun 2017 07:50:28 +0100
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>
References: <6a8ade07-ae18-88c8-d8df-68223899b813@posteo.de>
 <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>
Message-ID: <F989AA59-1693-4543-8736-86EB8D45F189@andrewg.com>


> On 7 Jun 2017, at 06:55, Stefan Claas <stefan.claas at posteo.de> wrote:
> 
> The procedure went like this: I inserted my id-card in a certified
> card reader, which i purchased, startet the german certified id-card
> software "AusweisApp2" to connect to the CA Server and the server
> checked my id-card online and after verification send the signed
> pub-key to my email address. Can this procedure be faked by
> criminals etc.? I doubt it.

Everything *can* be faked, given enough time, effort and/or money. The correct question is *would* criminals etc go to the necessary lengths to fake this procedure, and the answer (as always) is: it depends on what it's worth to them. :-)

A


From stefan.claas at posteo.de  Wed Jun  7 10:43:16 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 10:43:16 +0200
Subject: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <d197c946-84f7-acf9-3552-b3572af45845@posteo.de>
References: <d197c946-84f7-acf9-3552-b3572af45845@posteo.de>
Message-ID: <5b425c46-20c5-3b3b-0ff3-71f8ea5516e8@posteo.de>

Am 07.06.2017 um 08:50 schrieb Andrew Gallagher:

>> On 7 Jun 2017, at 06:55, Stefan Claas <stefan.claas at posteo.de> wrote:
>>
>> The procedure went like this: I inserted my id-card in a certified
>> card reader, which i purchased, startet the german certified id-card
>> software "AusweisApp2" to connect to the CA Server and the server
>> checked my id-card online and after verification send the signed
>> pub-key to my email address. Can this procedure be faked by
>> criminals etc.? I doubt it.
> Everything *can* be faked, given enough time, effort and/or money. The correct question is *would* criminals etc go to the necessary lengths to fake this procedure, and the answer (as always) is: it depends on what it's worth to them. :-)
>

I have no idea how much money is made worldwide by shady companies or
bad people and what techniques for that are used on the Internet. A
public-key certified by the the way i described, assuming GnuPG would
become an accepted world wide standard in the future for digital
signatures, with frontends for Joe user average, would be a way to dry
out bad businesses. The classic WoT or TOFU does not help in this case, imo.

Regards
Stefan




From peter at digitalbrains.com  Wed Jun  7 10:57:37 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 7 Jun 2017 10:57:37 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>
References: <6a8ade07-ae18-88c8-d8df-68223899b813@posteo.de>
 <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>
Message-ID: <b56893f7-c862-62a3-8deb-de87ddeeec6f@digitalbrains.com>

On 07/06/17 07:55, Stefan Claas wrote:
> The procedure went like this: I inserted my id-card in a certified
> card reader, which i purchased, startet the german certified id-card
> software "AusweisApp2" to connect to the CA Server and the server
> checked my id-card online and after verification send the signed
> pub-key to my email address.

What prevents someone else from doing this with your ID-card? For
instance, someone with whom you live?

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/20170607/472305d1/attachment.sig>

From peter at digitalbrains.com  Wed Jun  7 11:04:46 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 7 Jun 2017 11:04:46 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
Message-ID: <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>

On 06/06/17 20:12, Stefan Claas wrote:
> Is TOFU verifying the email address from the from: header of the message
> and then compares it with the email address in the UID?

Yes.

> I ask, because
> if i would use a free form UID with no email address

That would make it difficult.

>, or i use an Anon
> Remailer with a nym account where both email addresses are not identical.

This doesn't seem like a problem, depending on some assumptions. In the
usual case where you wouldn't want the two accounts linked to the same
person, you would use two completely separate certificates, each with
their own pseudonym with nym address.

If you don't care that peole realize they belong to the same person, you
would create two UIDs on the same key, one for each nym account.

> I just installed modern GnuPG and used it with two inline PGP messages from
> Usenet and i like it. :-)

Good to hear :-).

> I tried also with Enigmail under OS X but when checking the signatures here
> from the list members i always get the blue "Untrusted Good Signature".

Did you already enable TOFU? It needs a line in your gpg.conf. Either:

trust-model tofu

or

trust-model tofu+pgp

The latter combines it with the Web of Trust. See the manpage for more
info. gpg.conf is in your GnuPG homedir. I think this is ~/.gnupg by
default on OS X as well.

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/20170607/e67e4056/attachment.sig>

From peter at digitalbrains.com  Wed Jun  7 11:10:55 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 7 Jun 2017 11:10:55 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
Message-ID: <0e233b0b-3709-2871-f630-4397772728d9@digitalbrains.com>

On 06/06/17 20:46, Charlie Jonas wrote:
> On 2017-06-06 19:12, Stefan Claas wrote:
>> I tried also with Enigmail under OS X but when checking the signatures here
>> from the list members i always get the blue "Untrusted Good Signature".
> 
> Yes I get this as well. Interestingly whatever trust level I give keys,
> Enigmail on OSX seems to want to make the bar blue regardless.

You mean with "Set Owner's Trust of Sender's Key" in Enigmail? That's
the wrong one. There's key validity and owner's trust. Key validity is
about whether you believe the key belongs to the person indicated.
Owner's trust is to what extent you trust that person to correctly
verify other people's identities.

You should sign the key to make it valid, not set its owner's trust.
It's a common misconception.

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/20170607/512ad23d/attachment.sig>

From stefan.claas at posteo.de  Wed Jun  7 11:33:06 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 11:33:06 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <b56893f7-c862-62a3-8deb-de87ddeeec6f@digitalbrains.com>
References: <6a8ade07-ae18-88c8-d8df-68223899b813@posteo.de>
 <07b85f27-b84c-9008-f1cb-8d61dc7908e4@posteo.de>
 <b56893f7-c862-62a3-8deb-de87ddeeec6f@digitalbrains.com>
Message-ID: <882d8376-e954-aab8-d49c-6dde9b4bf8ab@posteo.de>

Am 07.06.2017 um 10:57 schrieb Peter Lebbing:

> On 07/06/17 07:55, Stefan Claas wrote:
>> The procedure went like this: I inserted my id-card in a certified
>> card reader, which i purchased, startet the german certified id-card
>> software "AusweisApp2" to connect to the CA Server and the server
>> checked my id-card online and after verification send the signed
>> pub-key to my email address.
> What prevents someone else from doing this with your ID-card? For
> instance, someone with whom you live?
>
>
The ID-card is protected with a pin which i have memorized.
But good that you bring this point up! Should my ID-card get's
stolen the thief can only try thee times to guess the pin.

Regards
Stefan



From stefan.claas at posteo.de  Wed Jun  7 11:45:45 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 11:45:45 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
Message-ID: <6fc6b16a-9066-68b7-917e-608e599d68a9@posteo.de>

Am 07.06.2017 um 11:04 schrieb Peter Lebbing:

> On 06/06/17 20:12, Stefan Claas wrote:
>> Is TOFU verifying the email address from the from: header of the message
>> and then compares it with the email address in the UID?
> Yes.
>
>> I ask, because
>> if i would use a free form UID with no email address
> That would make it difficult.
>
>> , or i use an Anon
>> Remailer with a nym account where both email addresses are not identical.
> This doesn't seem like a problem, depending on some assumptions. In the
> usual case where you wouldn't want the two accounts linked to the same
> person, you would use two completely separate certificates, each with
> their own pseudonym with nym address.
>
> If you don't care that peole realize they belong to the same person, you
> would create two UIDs on the same key, one for each nym account.

Thank you very much for your detailed explanation!
>> I just installed modern GnuPG and used it with two inline PGP messages from
>> Usenet and i like it. :-)
> Good to hear :-).
I love the idea of TOFU and it's great that it is implemented in modern 
GnuPG. :-)
Kudos and respect to the person who had this idea!
>
>> I tried also with Enigmail under OS X but when checking the signatures here
>> from the list members i always get the blue "Untrusted Good Signature".
> Did you already enable TOFU? It needs a line in your gpg.conf. Either:
>
> trust-model tofu
>
> or
>
> trust-model tofu+pgp
Yes, i did that and it works fine in command-line mode which also shows 
me the statistics.

Regards
Stefan



From peter at digitalbrains.com  Wed Jun  7 13:21:44 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 7 Jun 2017 13:21:44 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
Message-ID: <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>

On 07/06/17 11:04, Peter Lebbing wrote:
> On 06/06/17 20:12, Stefan Claas wrote:
>> Is TOFU verifying the email address from the from: header of the message
>> and then compares it with the email address in the UID?
> 
> Yes.

Actually, that's not really correct. It also works without a From:. I
don't know the details by heart, and I spoke too easily. TOFU verifies
the consistency of the binding between a key and the e-mail address in a
UID. So if so far you've seen a particular key being used for signatures
from <jim at example.org> and suddenly it's signed by a different key that
also has an e-mail address <jim at example.org>, TOFU will alert you that
this is not what it expected to see.

Your e-mail client can also verify the consistency between the UID and
the From:, but GnuPG primarily checks the consistency of the mapping
between key and UID on the key. And it also works on the command line,
where no From: is available. It will not alert you of similar-looking
e-mail addresses, since this is really hard to solve, but the statistics
printed will hopefully make you notice that even though you should see
"10 signatures verified in the past month", it suddenly says "0
signatures verified so far" and this tells you it is not the same key as
before.

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/20170607/74090226/attachment.sig>

From stefan.claas at posteo.de  Wed Jun  7 13:49:15 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 13:49:15 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
Message-ID: <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>

Am 07.06.2017 um 13:21 schrieb Peter Lebbing:

> On 07/06/17 11:04, Peter Lebbing wrote:
>> On 06/06/17 20:12, Stefan Claas wrote:
>>> Is TOFU verifying the email address from the from: header of the message
>>> and then compares it with the email address in the UID?
>> Yes.
> Actually, that's not really correct. It also works without a From:. I
> don't know the details by heart, and I spoke too easily. TOFU verifies
> the consistency of the binding between a key and the e-mail address in a
> UID. So if so far you've seen a particular key being used for signatures
> from <jim at example.org> and suddenly it's signed by a different key that
> also has an e-mail address <jim at example.org>, TOFU will alert you that
> this is not what it expected to see.
Thanks, that's what i assumed.
>
> It will not alert you of similar-looking
> e-mail addresses, since this is really hard to solve, but the statistics
> printed will hopefully make you notice that even though you should see
> "10 signatures verified in the past month", it suddenly says "0
> signatures verified so far" and this tells you it is not the same key as
> before.
In Enigmail with the blue and green bar (without showing statistics) it 
would simply mean
that it switches from green to blue, right?

Regards
Stefan


From peter at digitalbrains.com  Wed Jun  7 14:24:45 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 7 Jun 2017 14:24:45 +0200
Subject: TOFU (was: Question for app developers, like Enigmail etc. -
 Identicons)
In-Reply-To: <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
Message-ID: <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>

On 07/06/17 13:49, Stefan Claas wrote:
> In Enigmail with the blue and green bar (without showing statistics) it
> would simply mean
> that it switches from green to blue, right?

Not necessarily!

I don't know if Enigmail checks whether the From: is equal to the key
UID, but we're talking about look-alike addresses here, not completely
equal addresses, so even that wouldn't help.

It would, depending on tofu-default-policy, potentially be marked as
Good with a green bar! It is from a new key from an e-mail address never
before seen. With the default tofu-default-policy, it would *not* be
green, because it would only get marginal validity. But with
tofu-default-policy good, it would get marked as valid because there
doesn't seem to be anything wrong with it. It's only a visual similarity
that fools the user, but a computer is an exact device and doesn't know
they look similar to you.

I hope Enigmail will add the TOFU statistics to the displayed
information. Or maybe they already did, I see that I'm using Debian
jessie's enigmail package for Enigmail, and Debian jessie/stable has
pretty old packages (well maintained, but old).

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/20170607/0a931b39/attachment-0001.sig>

From stefan.claas at posteo.de  Wed Jun  7 14:47:24 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 14:47:24 +0200
Subject: TOFU
In-Reply-To: <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
Message-ID: <75c11e97-ca34-32e8-dede-7712f8c74703@posteo.de>

Am 07.06.2017 um 14:24 schrieb Peter Lebbing:

> On 07/06/17 13:49, Stefan Claas wrote:
>> In Enigmail with the blue and green bar (without showing statistics) it
>> would simply mean
>> that it switches from green to blue, right?
> Not necessarily!
>
> I don't know if Enigmail checks whether the From: is equal to the key
> UID, but we're talking about look-alike addresses here, not completely
> equal addresses, so even that wouldn't help.
>
> It would, depending on tofu-default-policy, potentially be marked as
> Good with a green bar! It is from a new key from an e-mail address never
> before seen. With the default tofu-default-policy, it would *not* be
> green, because it would only get marginal validity. But with
> tofu-default-policy good, it would get marked as valid because there
> doesn't seem to be anything wrong with it. It's only a visual similarity
> that fools the user, but a computer is an exact device and doesn't know
> they look similar to you.
>
> I hope Enigmail will add the TOFU statistics to the displayed
> information. Or maybe they already did, I see that I'm using Debian
> jessie's enigmail package for Enigmail, and Debian jessie/stable has
> pretty old packages (well maintained, but old).
>
>
Thank you very much for the Information! Then i have to wait until an
Enigmail with TOFU version will be released to see how it works.

Since TOFU interests me very much i will check what command line based
email clients with GnuPG support for OS X are available and run then
some tests from different email accounts.

Regards
Stefan



From andrewg at andrewg.com  Wed Jun  7 15:17:12 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 7 Jun 2017 14:17:12 +0100
Subject: TOFU
In-Reply-To: <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
Message-ID: <f822f05c-715e-aaf2-d0aa-fafcad6f9228@andrewg.com>

On 2017/06/07 13:24, Peter Lebbing wrote:
> Not necessarily!
> 
> I don't know if Enigmail checks whether the From: is equal to the key
> UID, but we're talking about look-alike addresses here, not completely
> equal addresses, so even that wouldn't help.

If I send an email to myself from my new work email, but sign it with my
old personal key (which doesn't have my new work email as a UID), it
still shows up as green in Enigmail. Now, that may be because I'm using
an ultimately trusted key - but it's still not what one might naively
expect.

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/20170607/b00d9769/attachment.sig>

From marianne.hommer at sungardas.com  Wed Jun  7 14:45:12 2017
From: marianne.hommer at sungardas.com (Marianne Hommer)
Date: Wed, 7 Jun 2017 12:45:12 +0000
Subject: error while trying to run make
Message-ID: <SN1PR18MB0397FCA6575AF2CFD37AE2DFF2C80@SN1PR18MB0397.namprd18.prod.outlook.com>

Hello,
    I am trying to run make on GPG 2.1.21 and get the following errors. I do not see any errors from installing the pre req programs.

Thanks in advance

make  all-recursive
make[1]: Entering directory `/home/scsadmin/gnupg-2.1.21'
Making all in m4
make[2]: Entering directory `/home/scsadmin/gnupg-2.1.21/m4'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/scsadmin/gnupg-2.1.21/m4'
Making all in common
make[2]: Entering directory `/home/scsadmin/gnupg-2.1.21/common'
make  all-am
make[3]: Entering directory `/home/scsadmin/gnupg-2.1.21/common'
gcc -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/local/var\""        -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -DWITHOUT_NPTH=1 -Wall -Wno-pointer-sign -Wpointer-arith  -g -O2 -MT libcommon_a-sysutils.o -MD -MP -MF .deps/libcommon_a-sysutils.Tpo -c -o libcommon_a-sysutils.o `test -f 'sysutils.c' || echo './'`sysutils.c
sysutils.c: In function ???gnupg_inotify_watch_socket???:
sysutils.c:1163: error: ???IN_EXCL_UNLINK??? undeclared (first use in this function)
sysutils.c:1163: error: (Each undeclared identifier is reported only once
sysutils.c:1163: error: for each function it appears in.)
make[3]: *** [libcommon_a-sysutils.o] Error 1
make[3]: Leaving directory `/home/scsadmin/gnupg-2.1.21/common'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/scsadmin/gnupg-2.1.21/common'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/scsadmin/gnupg-2.1.21'
make: *** [all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170607/b7382ffb/attachment.html>

From ludwig at enigmail.net  Wed Jun  7 22:23:36 2017
From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=)
Date: Wed, 7 Jun 2017 22:23:36 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
Message-ID: <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>

Hi Stefan,

On 06.06.17 22:19, Stefan Claas wrote:
> On 06.06.17 20:46, Charlie Jonas wrote:
>> On 2017-06-06 19:12, Stefan Claas wrote:
>>> I tried also with Enigmail under OS X but when checking the
>>> signatures here from the list members i always get the blue
>>> "Untrusted Good Signature".
>> Yes I get this as well. Interestingly whatever trust level I give
>> keys, Enigmail on OSX seems to want to make the bar blue
>> regardless.
>> 
> Thanks for confirming. Hopefully Ludwig still follows this thread
> and can tell us why it's not working, as expected.

It's working as expected. To get a green bar in Enigmails header
display, the key signing the message has to be at least fully valid. A
key gets valid if you either:

- sign it (whether local or exportable is not relevant)

or

- it is signed by
  - at least one key you have signed and you have put "full" ownertrust
    on these
  - at least three other keys you have signed and you have put
    "marginal" ownertrust on these

This is the behaviour of the "classic" or "PGP" trust model which is
the default in GnuPG. Enigmail only displays the result.

You may read more about this here:
https://enigmail.wiki/Key_Management#The_Web_of_Trust

There's a lot more information about the web of trust out in the web.

Disclaimer: Configuring GnuPG to use the TOFU trust model may change
this behaviour.

Ludwig

BTW: Could you please stop forwarding your replies to the list? Now
there are 6 threads titled "Question for app developers, like Enigmail
etc. - Identicons" on the list. Just click on "Reply to list" when
replying. Thanks.

-------------- 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/20170607/3b416215/attachment-0001.sig>

From stefan.claas at posteo.de  Wed Jun  7 22:46:54 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 7 Jun 2017 22:46:54 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
Message-ID: <cfcd4c08-f335-caab-e8c2-a4e45050d44e@posteo.de>

On 07.06.17 22:23, Ludwig H?gelsch?fer wrote:
> Hi Stefan,
>
> On 06.06.17 22:19, Stefan Claas wrote:
>> On 06.06.17 20:46, Charlie Jonas wrote:
>>> On 2017-06-06 19:12, Stefan Claas wrote:
>>>> I tried also with Enigmail under OS X but when checking the
>>>> signatures here from the list members i always get the blue
>>>> "Untrusted Good Signature".
>>> Yes I get this as well. Interestingly whatever trust level I give
>>> keys, Enigmail on OSX seems to want to make the bar blue
>>> regardless.
>>>
>> Thanks for confirming. Hopefully Ludwig still follows this thread
>> and can tell us why it's not working, as expected.
> It's working as expected. To get a green bar in Enigmails header
> display, the key signing the message has to be at least fully valid. A
> key gets valid if you either:
>
> - sign it (whether local or exportable is not relevant)
>
> or
>
> - it is signed by
>   - at least one key you have signed and you have put "full" ownertrust
>     on these
>   - at least three other keys you have signed and you have put
>     "marginal" ownertrust on these
>
> This is the behaviour of the "classic" or "PGP" trust model which is
> the default in GnuPG. Enigmail only displays the result.

Thanks, i'm aware of the classic trust model.
>
> You may read more about this here:
> https://enigmail.wiki/Key_Management#The_Web_of_Trust
>
> There's a lot more information about the web of trust out in the web.
>
> Disclaimer: Configuring GnuPG to use the TOFU trust model may change
> this behaviour.

I configured GnuPG to use the TOFU model and expected that Enigmail
would switch from blue Untrusted to green when TOFU gives "full" trust
to a pub key. For example when i downloaded a signed Usenet message
as a test (where Enigmail showed me a blue bar) and let GnuPG verify
the saved file manually it gave me the statistics. After downloading a
second file, where Enigmail correctly showed the blue bar again, i ran
the file via GnuPG and it gave "full" trust to the message. After that
i klicked again in Enigmail in the Usenet thread and voila i had a green
bar. So that is the reason why i thought Enigmail would give me with
the new trust model also a green bar when checking here list members
messages.

Regards
Stefan

And appologies for the multiple thread chaos!




From socal2007 at gmail.com  Wed Jun  7 23:32:12 2017
From: socal2007 at gmail.com (Reynold DeMarco Jr)
Date: Wed, 7 Jun 2017 14:32:12 -0700
Subject: libgcrypt
Message-ID: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com>

Trying to install gnupg on fedora 25 - downloaded all necessary 
prerequisites and installed them.

I get an error message when running gpg2 from command line.

gpg: Fatal: libgcrypt is too old (need 1.7.0, have 1.6.6)

I installed libgcrypt 1.7.7 on this machine but it reverts to the distro 
installation of 1.6.6

How do I enable version 1.7.7 on this machine

Thank you for your time in this matter

Reynold



From antony at blazrsoft.com  Thu Jun  8 02:30:59 2017
From: antony at blazrsoft.com (Antony Prince)
Date: Wed, 07 Jun 2017 20:30:59 -0400
Subject: libgcrypt
In-Reply-To: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com>
References: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com>
Message-ID: <88d9f4a88b08add3559e9f4c53e0ecb5@blazrsoft.com>

On 2017-06-07 05:32 PM, Reynold DeMarco Jr wrote:
...
> I installed libgcrypt 1.7.7 on this machine but it reverts to the
> distro installation of 1.6.6
> 
> How do I enable version 1.7.7 on this machine
> 

I had a similar problem a while back on a different distro. IIRC, you 
have to specify the library directory to the compiler. Something like 
'-L/path/to/library/dir -{name of library}'. That's probably not the 
right syntax, but the issue you're having is that at compile time it is 
linking the system version so you need to explicitly tell the 
linker/compiler which one to use via compile time flags. If I'm wrong 
there, I'm sure someone else on the list can point you in the right 
direction.

-- 
--
HTH,
Antony Prince


From wk at gnupg.org  Thu Jun  8 08:14:49 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 Jun 2017 08:14:49 +0200
Subject: libgcrypt
In-Reply-To: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com> (Reynold
 DeMarco, Jr.'s message of "Wed, 7 Jun 2017 14:32:12 -0700")
References: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com>
Message-ID: <87vao7ovja.fsf@wheatstone.g10code.de>

On Wed,  7 Jun 2017 23:32, socal2007 at gmail.com said:

> I installed libgcrypt 1.7.7 on this machine but it reverts to the
> distro installation of 1.6.6

Did you install the correct libgcrypt*-dev package (assuming you are
using a pre-packaged version) and can configure find it?  Enter

   libgcrypt-config --version

This should show you a 1.7 version number.  If it does not, try

  which libgcrypt-config 

this should show you from where it was executed.  Non-distro installed
packages will find that script in /usr/local/bin and not in /usr/bin/.

If not there are two ways to fix that:

  - Put /usr/local/bin into your PATH right before /usr/bin.  You will
    also need to run "hash -r" to tell the shell to forget all cached
    program locations (or start a new shell).

and

  - Make sure /usr/local/lib is known to ldconfig.  That is put this
    directory name into /etc/ld.so.conf or a separate file under
    /etc/ld.so.conf.d/.  Then run ldconfig

the second option is to

  - Add 
      --with-libgcrypt-prefix=/usr/local
    (note: without the "/bin" part)
    or whereever you installed libgcrypt 1.7
    to the configure invocation

  - To actually run things you need to make /usr/local/lib also known to
    the runtime linke, as described above.  Alternatively you can set
    LD_LIBRARY_PATH to that directory.


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/20170608/ddffd068/attachment.sig>

From guru at unixarea.de  Thu Jun  8 12:29:56 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 8 Jun 2017 12:29:56 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
Message-ID: <20170608102956.GA10333@c720-r314251>


Hello,

I was tired of having always enter the PIN when sending mails to sign them
and switched the card to 'not forces':

Signature PIN ....: not forced

After this (without withdrawing the card, i.e. the PIN was already
entered around 10 times and the card unlocked), the signing says:

$ echo bla > test.doc
$ LANG=C
$ gpg2 --armor --output test.doc.signed --sign test.doc
gpg: signing failed: Bad PIN
gpg: signing failed: Bad PIN

The bad PIN counter in the card is not decremented. Switching the card
back to 'forced' makes signing with PIN working again.

What do I wrong?

	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/20170608/70c99239/attachment.sig>

From guru at unixarea.de  Thu Jun  8 12:48:55 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 8 Jun 2017 12:48:55 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
Message-ID: <20170608104855.GB10551@c720-r314251>


Every time I write to gnupg-users at gnupg.org I get this crap from a robot
or from Sarah about dating. Can someone do anything that he/she/it is not
triggered.

Sarah, I have no intention to click on the URL and much less to click on
you. Crap.

	matthias

----- Forwarded message from Sarah <rhona29432 at aol.com> -----

Date: Thu, 8 Jun 2017 06:41:21 -0400
From: Sarah <rhona29432 at aol.com>
To: guru at unixarea.de
Subject: RE: setting GnuPG card to 'not forces' does not let sign
X-Mailer: JAS STD

Have you finally got my pix?
Let's meet tomorrow!
Write me only here: http://free-new-dating.online/?&s=35&:uni:2g-17&Profile=Sarah212





On Jun 08, 2017, at 10:29 AM, Matthias Apitz <guru at unixarea.de> wrote:

>
>--k1lZvvs/B4yU6o8G
>Content-Type: text/plain; charset=utf-8
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>
>Hello,
>
>I was tired of having always enter the PIN when sending mails to sign them
>and switched the card to 'not forces':
>
>Signature PIN ....: not forced
>
>After this (without withdrawing the card, i.e. the PIN was already
>entered around 10 times and the card unlocked), the signing says:
>
>$ echo bla > test.doc
>$ LANG=3DC
>$ gpg2 --armor --output test.doc.signed --sign test.doc
>gpg: signing failed: Bad PIN
>gpg: signing failed: Bad PIN
>
>The bad PIN counter in the card is not decremented. Switching the card
>back to 'forced' makes signing with PIN working again.
>
>What do I wrong?
>
>	matthias
>
>
>--=20
>Matthias Apitz, =E2=9C=89 guru at unixarea.de, =E2=8C=82 http://www.unixarea.d=
>e/  =E2=98=8E +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=C3=B3 la Guerra.
>May 8, 1945: Who does not celebrate lost the War.
>
>--k1lZvvs/B4yU6o8G
>Content-Type: application/pgp-signature; name="signature.asc"
>
>-----BEGIN PGP SIGNATURE-----
>
>iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlk5JxMACgkQR8z35Hb+
>nRG0Pg//XxtBaoPPQN3uinfxxExnoNQcScfx/Eycxr1kDZjFQxp6LVIK1KZy+Dht
>V5Sx+ssn0lids22szU5uZlT60dqbaUAASzsBo74FPxsvJ03BishsCIvCCqArpj5S
>kZLe/iUExNj+hq4XRUh0Ia0MllI20rzjEF1sC0EC2r1YfYv2ePdFzgQtD8HvDMqo
>v0vPISHoPF7Xsswu9q3TFQGbiim6HEoOLgQlYGMB1egP4NS66RGWU/s3fVVXqEw5
>c8btka/S64hNVMiFEzNl573csiQDLdT/OHk9DvDpHDqzcSCZVuutCznj4sDmMIEx
>7GKZsfv4xLJT4CuKHDedm7AOctRw9fV2GqFCeIlc/sdELxg4MX+pYpmd6gN79Dno
>wDe5oCXXSmUvodvGS5iSfVYCmoJZ+Ww1oxWFG2YHl6kAGZP6h3Lam6GjOhoaoXLJ
>P4MD+4EG9GAs8cMpCtiCjbqW27eV6KeglGu2RCLhSp3pWGTXFxuXW2X4fMbhZrNC
>3pc2X3QTClcbmPaRActZ3Kt5KqxbHS7iAAWJr/Rna+SRsCxFpCQYnl+m6BOdJs9X
>rx86Ca/NAZBOtWbrnVlT5yCgUAZ2gNaQPVDXhKRNUmosdwC8RKG1y+JyEav8CmKc
>UbJa6pIIYknZQ+UGTbIuuZX/VM2PR+86Tr3FihuDKt/VA9IBpq4=
>=EM3I
>-----END PGP SIGNATURE-----
>
>--k1lZvvs/B4yU6o8G--
>
>

----- End forwarded message -----

-- 
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/20170608/d2957b17/attachment.sig>

From szczepan at nitrokey.com  Thu Jun  8 11:35:38 2017
From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey)
Date: Thu, 8 Jun 2017 11:35:38 +0200
Subject: error while trying to run make
In-Reply-To: <SN1PR18MB0397FCA6575AF2CFD37AE2DFF2C80@SN1PR18MB0397.namprd18.prod.outlook.com>
References: <SN1PR18MB0397FCA6575AF2CFD37AE2DFF2C80@SN1PR18MB0397.namprd18.prod.outlook.com>
Message-ID: <357ca3bd-526a-573e-aca7-e5456a7db4c4@nitrokey.com>

On 06/07/2017 02:45 PM, Marianne Hommer wrote:
>     I am trying to run make on GPG 2.1.21 and get the following errors.
> I do not see any errors from installing the pre req programs.
> 

Hello,

Similar issue regarding `IN_EXCL_UNLINK` was solved earlier.
See thread from 05/09/2017 07:12 PM,
topic: `undeclared function identified during make - gnupg-2.1.20`.

-- 
Best regards,
Szczepan


From peter at digitalbrains.com  Thu Jun  8 13:18:35 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 8 Jun 2017 13:18:35 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170608104855.GB10551@c720-r314251>
References: <20170608104855.GB10551@c720-r314251>
Message-ID: <390f8b75-045b-e7cc-3331-6904520f3405@digitalbrains.com>

On 08/06/17 12:48, Matthias Apitz wrote:
> Every time I write to gnupg-users at gnupg.org I get this crap from a robot
> or from Sarah about dating. Can someone do anything that he/she/it is not
> triggered.

Yes, same here. I thought it was rather funny that she told me:

> Hello again! My boyfriend can read my email!
> It is not secure.

and later:

> Honey, I've told you, email is not secure enough!

How a spambot can be oddly on-topic for this mailing list...

But I doubt very much anyone can do anything about this. Somebody has
arranged their spambot to respond to messages on this list, but the list
is public, so anybody can see those messages to the list; it could be
anybody doing it. However, upon checking, all the 6 such messages I've
received over the last couple of days all originated from the IP
104.160.29.115. That's something.

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/20170608/db0791c1/attachment-0001.sig>

From guru at unixarea.de  Thu Jun  8 14:08:56 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 8 Jun 2017 14:08:56 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <390f8b75-045b-e7cc-3331-6904520f3405@digitalbrains.com>
References: <20170608104855.GB10551@c720-r314251>
 <390f8b75-045b-e7cc-3331-6904520f3405@digitalbrains.com>
Message-ID: <20170608120856.GA11460@c720-r314251>

El d?a jueves, junio 08, 2017 a las 01:18:35p. m. +0200, Peter Lebbing escribi?:

> On 08/06/17 12:48, Matthias Apitz wrote:
> > Every time I write to gnupg-users at gnupg.org I get this crap from a robot
> > or from Sarah about dating. Can someone do anything that he/she/it is not
> > triggered.
> 
> Yes, same here. I thought it was rather funny that she told me:
> 
> > Hello again! My boyfriend can read my email!
> > It is not secure.
> 
> and later:
> 
> > Honey, I've told you, email is not secure enough!
> 
> How a spambot can be oddly on-topic for this mailing list...

Perhaps, when the spambot sees part of his 1st message in the incoming
mail, it reacts on this.

I have it blacklisted now in my spamassassin config.

	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/20170608/ba123800/attachment.sig>

From ben at adversary.org  Thu Jun  8 14:20:37 2017
From: ben at adversary.org (Ben McGinnes)
Date: Thu, 8 Jun 2017 22:20:37 +1000
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <390f8b75-045b-e7cc-3331-6904520f3405@digitalbrains.com>
References: <20170608104855.GB10551@c720-r314251>
 <390f8b75-045b-e7cc-3331-6904520f3405@digitalbrains.com>
Message-ID: <20170608122037.cgbri27bywggbpvz@adversary.org>

On Thu, Jun 08, 2017 at 01:18:35PM +0200, Peter Lebbing wrote:
> On 08/06/17 12:48, Matthias Apitz wrote:
> > Every time I write to gnupg-users at gnupg.org I get this crap from a robot
> > or from Sarah about dating. Can someone do anything that he/she/it is not
> > triggered.
> 
> Yes, same here. I thought it was rather funny that she told me:
> 
> > Hello again! My boyfriend can read my email!
> > It is not secure.
> 
> and later:
> 
> > Honey, I've told you, email is not secure enough!
> 
> How a spambot can be oddly on-topic for this mailing list...

Yeah, I thought that was a little amusing too ... then I reactivated
my filtering of everything from AOL, sent them a spam report and
forgot about it.


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: </pipermail/attachments/20170608/a8630d78/attachment.sig>

From satoshi at linux.com  Thu Jun  8 15:05:40 2017
From: satoshi at linux.com (Satoshi Yoshida)
Date: Thu, 08 Jun 2017 22:05:40 +0900
Subject: How to show fingerprint in email header?
Message-ID: <87r2yuocij.fsf@linux.com>

How to show fingerprint in email header?
I found
https://datatracker.ietf.org/doc/draft-josefsson-openpgp-mailnews-header/
But it is expired.

-- 
Satoshi Yoshida
https://satoshi.blog


From wk at gnupg.org  Thu Jun  8 17:10:16 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 Jun 2017 17:10:16 +0200
Subject: How to show fingerprint in email header?
In-Reply-To: <87r2yuocij.fsf@linux.com> (Satoshi Yoshida's message of "Thu, 08
 Jun 2017 22:05:40 +0900")
References: <87r2yuocij.fsf@linux.com>
Message-ID: <87tw3qo6qv.fsf@wheatstone.g10code.de>

On Thu,  8 Jun 2017 15:05, satoshi at linux.com said:

> https://datatracker.ietf.org/doc/draft-josefsson-openpgp-mailnews-header/

Here is what I use:

  OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367

This is a complete URL of our dedicated keyserver with the finperint
appended.  How to configure this depends on your mailer.  I do this in
Gnus:

--8<---------------cut here---------------start------------->8---
(setq gnus-posting-styles
      '((".*"
	 (name "Werner Koch")
	 (address "wk at gnupg.org" )
         ("OpenPGP"  "url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367" )
         ("X-message-flag" "Mails containing HTML will not be read!\n\t Please send only plain text.")
	 (organisation "The GnuPG Project")
         (signature
          "Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.")
	 )))
--8<---------------cut here---------------end--------------->8---


(X-message-flag is a hack for Outlook users ;-)

However, I would much more like to see adoption of the Web Key Directory
which makes it much easier to find the right key.  If you are using
GnuPG 2.1 you can add 

--8<---------------cut here---------------start------------->8---
auto-key-locate local
auto-key-locate wkd
auto-key-locate dane
--8<---------------cut here---------------end--------------->8---

to your gpg.conf to enable it.  The fallback to DANE is optional; I
doubt that is much more deployed than WKD.  Note that WKD (and DANE)
contact the server of the mail provider, so they know that you will send
an encrypted mail - but that is something they will see
anyway.  Workaround is as usual Tor ("use-tor" in dirmngr.conf)


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/20170608/fd9066b9/attachment.sig>

From peter at digitalbrains.com  Thu Jun  8 17:19:40 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 8 Jun 2017 17:19:40 +0200
Subject: How to show fingerprint in email header?
In-Reply-To: <87r2yuocij.fsf@linux.com>
References: <87r2yuocij.fsf@linux.com>
Message-ID: <368465e9-8a81-c64c-fb98-3688115bde07@digitalbrains.com>

On 08/06/17 15:05, Satoshi Yoshida wrote:
> How to show fingerprint in email header?

Enigmail puts the following in my mails:

Openpgp: id=8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E;
 url=http://digitalbrains.com/2012/openpgp-key-peter

I think that is the generally accepted method to give both a fingerprint
and a URL. I'd wager the following is just the fingerprint:

Openpgp: id=8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E

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/20170608/dec6e250/attachment.sig>

From dkg at fifthhorseman.net  Thu Jun  8 17:12:17 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 08 Jun 2017 11:12:17 -0400
Subject: How to show fingerprint in email header?
In-Reply-To: <87r2yuocij.fsf@linux.com>
References: <87r2yuocij.fsf@linux.com>
Message-ID: <874lvqqzse.fsf@fifthhorseman.net>

On Thu 2017-06-08 22:05:40 +0900, Satoshi Yoshida wrote:
> How to show fingerprint in email header?
> I found
> https://datatracker.ietf.org/doc/draft-josefsson-openpgp-mailnews-header/
> But it is expired.

This is probably more of a question for your mail user agent than for
GnuPG, since GnuPG doesn't send mail.  What program do you use to send
mail?

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/20170608/5138fa29/attachment.sig>

From satoshi at linux.com  Thu Jun  8 20:01:59 2017
From: satoshi at linux.com (Satoshi Yoshida)
Date: Fri, 09 Jun 2017 03:01:59 +0900
Subject: How to show fingerprint in email header?
In-Reply-To: <87tw3qo6qv.fsf@wheatstone.g10code.de> (Werner Koch's message of
 "Thu, 08 Jun 2017 17:10:16 +0200")
References: <87r2yuocij.fsf@linux.com> <87tw3qo6qv.fsf@wheatstone.g10code.de>
Message-ID: <871squnyso.fsf@linux.com>

Werner Koch <wk at gnupg.org> writes:

> Here is what I use:
>
>   OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367
>
> This is a complete URL of our dedicated keyserver with the finperint
> appended.  How to configure this depends on your mailer.  I do this in
> Gnus:

Is this style still alive? Following URL shows it is expired.
https://datatracker.ietf.org/doc/draft-josefsson-openpgp-mailnews-header/

> (setq gnus-posting-styles
>       '((".*"
> 	 (name "Werner Koch")
> 	 (address "wk at gnupg.org" )
>          ("OpenPGP"  "url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367" )
>          ("X-message-flag" "Mails containing HTML will not be read!\n\t Please send only plain text.")
> 	 (organisation "The GnuPG Project")
>          (signature
>           "Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.")
> 	 )))

I'm using Gnus too.

> (X-message-flag is a hack for Outlook users ;-)

Hehehe.

-- 
Satoshi Yoshida
https://satoshi.blog


From satoshi at linux.com  Thu Jun  8 20:18:42 2017
From: satoshi at linux.com (Satoshi Yoshida)
Date: Fri, 09 Jun 2017 03:18:42 +0900
Subject: How to show fingerprint in email header?
In-Reply-To: <874lvqqzse.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Thu, 08 Jun 2017 11:12:17 -0400")
References: <87r2yuocij.fsf@linux.com> <874lvqqzse.fsf@fifthhorseman.net>
Message-ID: <87tw3qmjgd.fsf@linux.com>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> This is probably more of a question for your mail user agent than for
> GnuPG, since GnuPG doesn't send mail.  What program do you use to send
> mail?

I am using Gnus. I know how to edit email header.
I want to know Openpgp: style still alive or not.
Sorry my poor English. I'm a Japanese.

-- 
Satoshi Yoshida
https://satoshi.blog


From satoshi at linux.com  Thu Jun  8 20:28:39 2017
From: satoshi at linux.com (Satoshi Yoshida)
Date: Fri, 09 Jun 2017 03:28:39 +0900
Subject: How to show fingerprint in email header?
In-Reply-To: <368465e9-8a81-c64c-fb98-3688115bde07@digitalbrains.com> (Peter
 Lebbing's message of "Thu, 8 Jun 2017 17:19:40 +0200")
References: <87r2yuocij.fsf@linux.com>
 <368465e9-8a81-c64c-fb98-3688115bde07@digitalbrains.com>
Message-ID: <87poeemizs.fsf@linux.com>

Peter Lebbing <peter at digitalbrains.com> writes:

> Enigmail puts the following in my mails:
>
> Openpgp: id=8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E;
>  url=http://digitalbrains.com/2012/openpgp-key-peter
>
> I think that is the generally accepted method to give both a fingerprint
> and a URL. I'd wager the following is just the fingerprint:
>
> Openpgp: id=8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E

I see. Your answer is perfect for my question.
Thank you very much.

-- 
Satoshi Yoshida
https://satoshi.blog


From socal2007 at gmail.com  Thu Jun  8 21:57:56 2017
From: socal2007 at gmail.com (Reynold DeMarco Jr)
Date: Thu, 8 Jun 2017 12:57:56 -0700
Subject: libgcrypt
In-Reply-To: <87vao7ovja.fsf@wheatstone.g10code.de>
References: <2e372a50-10d3-c4a8-5b43-19cd80ed5235@gmail.com>
 <87vao7ovja.fsf@wheatstone.g10code.de>
Message-ID: <ad9b0f73-f4fe-25e6-d38c-40835273d4a9@gmail.com>

Thank you for this - I found libgcrypt version 1.7.7 at /usr/local/bin
which is not in my class path.

I will update my system to include the path or run with it on the
command line or both but at any

rate this solution will work for me.

Reynold


On 06/07/2017 11:14 PM, Werner Koch wrote:
> On Wed,  7 Jun 2017 23:32, socal2007 at gmail.com said:
>
>> I installed libgcrypt 1.7.7 on this machine but it reverts to the
>> distro installation of 1.6.6
> Did you install the correct libgcrypt*-dev package (assuming you are
> using a pre-packaged version) and can configure find it?  Enter
>
>    libgcrypt-config --version
>
> This should show you a 1.7 version number.  If it does not, try
>
>   which libgcrypt-config 
>
> this should show you from where it was executed.  Non-distro installed
> packages will find that script in /usr/local/bin and not in /usr/bin/.
>
> If not there are two ways to fix that:
>
>   - Put /usr/local/bin into your PATH right before /usr/bin.  You will
>     also need to run "hash -r" to tell the shell to forget all cached
>     program locations (or start a new shell).
>
> and
>
>   - Make sure /usr/local/lib is known to ldconfig.  That is put this
>     directory name into /etc/ld.so.conf or a separate file under
>     /etc/ld.so.conf.d/.  Then run ldconfig
>
> the second option is to
>
>   - Add 
>       --with-libgcrypt-prefix=/usr/local
>     (note: without the "/bin" part)
>     or whereever you installed libgcrypt 1.7
>     to the configure invocation
>
>   - To actually run things you need to make /usr/local/lib also known to
>     the runtime linke, as described above.  Alternatively you can set
>     LD_LIBRARY_PATH to that directory.
>
>
> Shalom-Salam,
>
>    Werner
>

-- 
Reynold DeMarco Jr.
socal2007 at gmail.com
sent from Thunderbird



From Ian.Morris2 at hantsfire.gov.uk  Thu Jun  8 16:39:29 2017
From: Ian.Morris2 at hantsfire.gov.uk (Ian A Morris)
Date: Thu, 8 Jun 2017 14:39:29 +0000
Subject: GPG4Win Advice
Message-ID: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>

Hi All,

I have been tasked with setting up a secure file transfer mechanism for our organisation.
We have created the private keys etc. using Kleopatra and are able to encrypt/sign (with asci armor) and decrypt and exchange files with our partners successfully.
I would like to automate the process as follows.
Users place files in a folder based on a Fileserver.
GPG4Win (based on our SFTP Server) is scheduled to check the folder, encrypt any files it finds placing the encrypted file on the SFTP server's Outbound folder and DELETING the original file on the Fileserver.
I am able to automate the encryption but the original file stays in place. When using the GUI there are options for the following, "Remove unencrypted original file when don"

Could you please help. I would like to

[cid:image002.png at 01D2E06C.9548ED40]


I am using the following syntax

Gpg2 -batch -recipient xxxxx  -encrypt-files -armor C:\Location\*.txt
Which creates the encrypted the files in the same location and the orginal files still remain.

I have tried a number of different options, none of which worked for me.
If I am able to to encrypt/decrypt and point the files to an alternative location and remove the orginals then I would be extremely grateful for the help.


Kind Regards

Ian A. Morris
IT Infrastructure Analyst
ICT Transformation Project
Int: 7592191
Tel: 02380 626897
Mob: +44 7958 216696
[cid:image001.png at 01D214E5.DE402DE0]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170608/1c7ff143/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4059 bytes
Desc: image001.png
URL: </pipermail/attachments/20170608/1c7ff143/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 25353 bytes
Desc: image002.png
URL: </pipermail/attachments/20170608/1c7ff143/attachment-0003.png>

From stefan.claas at posteo.de  Thu Jun  8 22:33:19 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 8 Jun 2017 22:33:19 +0200
Subject: TOFU
In-Reply-To: <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
Message-ID: <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>


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

On 07.06.17 14:24, Peter Lebbing wrote:
> I hope Enigmail will add the TOFU statistics to the displayed > information. Or maybe they already did, I see that I'm using Debian >
jessie's enigmail package for Enigmail, and Debian jessie/stable has >
pretty old packages (well maintained, but old). > I did a test today
with Enigmail and with TOFU in command line mode.
I posted 3 messages with a fantasy name to a Usenet test group where
the 3rd message was signed with a fake key and Enigmail showed me this:

UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:07

UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:08

UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:17

(It's the usual message under macOS with the blue bar. Note: with auto
key retrival on.)

Then i downloaded all messages run them through GnuPG and on the first
message TOFU already told me that there are 3 equal email addresses!

Regards
Stefan



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEK6+F+SgavVQ4I8fFmB63w4LsUrQFAlk5tIgACgkQmB63w4Ls
UrRENwgA5AdTLLyqXMweycHoQcxFjzi5wdZv/t9KxYCTlYDLAQDkmabD9Gzcdfbe
4x/wc/RbIB9alJ/GPBgtNvl4xrljGQhw20pA2ppbe/YS2hnIHlmWgyscNj1168cc
sGOBAU2ZlX2CGRpDe/9cbuF5pj9/l8jeCFQGaY1RKp5DkXFZr4svxC3CnCd3p94t
6ROhxjls8R0SkGvBHls8Cm6bRoACETkRITHd5y5WbMmzWQFLoAWfl3ekxYt2Q46c
XxLCRBQvxg0R6zngmuciZLBsCe94+xsNiqRZ+Q9GFAagobSaGZso+aSquqguU35G
mOpxm07iEgU1YeAGS67tLTTxWGv0HQ==
=mpGy
-----END PGP SIGNATURE-----




From stefan.claas at posteo.de  Thu Jun  8 22:39:13 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 8 Jun 2017 22:39:13 +0200
Subject: TOFU
In-Reply-To: <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
Message-ID: <448e7a5b-70ee-1195-76eb-9dad8c9fa597@posteo.de>

On 08.06.17 22:33, Stefan Claas wrote:

[snip]

bad signature and mangled text. I don't like
how the Editor in Thunderbird works! I look like
an idiot here on the list with my postings.

Regards
Stefan



From wk at gnupg.org  Fri Jun  9 08:09:12 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jun 2017 08:09:12 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170608102956.GA10333@c720-r314251> (Matthias Apitz's message
 of "Thu, 8 Jun 2017 12:29:56 +0200")
References: <20170608102956.GA10333@c720-r314251>
Message-ID: <877f0lofp3.fsf@wheatstone.g10code.de>


> The bad PIN counter in the card is not decremented. Switching the card
> back to 'forced' makes signing with PIN working again.

Interesting.  Did you also try to reset the card (i.e. re-insert) whit
non-forced set?


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/20170609/5daa3b02/attachment.sig>

From wk at gnupg.org  Fri Jun  9 08:06:50 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jun 2017 08:06:50 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170608104855.GB10551@c720-r314251> (Matthias Apitz's message
 of "Thu, 8 Jun 2017 12:48:55 +0200")
References: <20170608104855.GB10551@c720-r314251>
Message-ID: <87bmpxoft1.fsf@wheatstone.g10code.de>

On Thu,  8 Jun 2017 12:48, guru at unixarea.de said:
> Every time I write to gnupg-users at gnupg.org I get this crap from a robot
> or from Sarah about dating. Can someone do anything that he/she/it is not

That bot is subscribed.  I enabled the moderation flag and disabled
delivery.


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/20170609/18db5350/attachment.sig>

From guru at unixarea.de  Fri Jun  9 08:23:42 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 9 Jun 2017 08:23:42 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <87bmpxoft1.fsf@wheatstone.g10code.de>
References: <20170608104855.GB10551@c720-r314251>
 <87bmpxoft1.fsf@wheatstone.g10code.de>
Message-ID: <20170609062342.GA2857@c720-r314251>

El d?a viernes, junio 09, 2017 a las 08:06:50a. m. +0200, Werner Koch escribi?:

> On Thu,  8 Jun 2017 12:48, guru at unixarea.de said:
> > Every time I write to gnupg-users at gnupg.org I get this crap from a robot
> > or from Sarah about dating. Can someone do anything that he/she/it is not
> 
> That bot is subscribed.  I enabled the moderation flag and disabled
> delivery.
> 

Thanks for this.

Re/ the issue itself, it seems that a complete restart of the chain
gpg-agent -- scdaemon -- /usr/local/sbin/pcscd
fixed the issue. It asks now once for the PIN for signing and then not
again until reboot.

Thanks as well for the nice hint about X-message-flag: header line.
The warning looks really nice in the crappy MS OutLook.

	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/20170609/f23639a3/attachment.sig>

From wk at gnupg.org  Fri Jun  9 08:24:28 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 Jun 2017 08:24:28 +0200
Subject: Key management for archives
In-Reply-To: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com> (NdK's message
 of "Tue, 6 Jun 2017 14:39:56 +0200")
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
Message-ID: <87zidhn0f7.fsf@wheatstone.g10code.de>

On Tue,  6 Jun 2017 14:39, ndk.clanbo at gmail.com said:
> Is it possible to "extract" the used session key, so that the requester
> just ignores the asymmetric crypto and just uses the symmetric key to
> decode the file? Drawbacks? Other ideas?

Here is how I would do that:

 ( gpg --status-fd 1 --show-session-key --max-output 1 \
      -o /dev/null 2>/dev/null FILE || true ) \
   | awk '$1=="[GNUPG:]" && $2=="SESSION_KEY" {print $3}'

Note that gpg exists with a failure (due to the "exceeded --max-output
limit" error message) and for extra cleanness I shortcut that error.

The output can then be used with --override-session-key


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/20170609/1177818a/attachment.sig>

From guru at unixarea.de  Fri Jun  9 08:39:11 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 9 Jun 2017 08:39:11 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <877f0lofp3.fsf@wheatstone.g10code.de>
References: <20170608102956.GA10333@c720-r314251>
 <877f0lofp3.fsf@wheatstone.g10code.de>
Message-ID: <20170609063910.GB2857@c720-r314251>

El d?a viernes, junio 09, 2017 a las 08:09:12a. m. +0200, Werner Koch escribi?:

> 
> > The bad PIN counter in the card is not decremented. Switching the card
> > back to 'forced' makes signing with PIN working again.
> 
> Interesting.  Did you also try to reset the card (i.e. re-insert) whit
> non-forced set?

As I wrote in the last mail, it works now like it should and for signing
as for SSH I only have to enter the PIN once.

I have one last remaining issue with this GnuPG card and/or my USB
device HID Global OMNIKEY 6121 Smart Card Reader and/or FreeBSD, i.e.
its totally unclear at the moment what is causing it:

Sometimes (let's say in 50% of the cases) the USB device is not seen by
the FreeBSD kernel on power-on boot, even if the OMNIKEY is already inserted before
power-on. When it is not seen on boot, it is not seen on withdraw and
re-insert. When it is seen, it is always seen, i.e. one can re-insert as
much as you want, it always works. Sometimes not even a re-boot helps, it
takes 2-3 re-boots to get the OMNIKEY seen.

I know, this is not a GnuPG issue, but I wanted to mention it here to
ask if others has similar experiences, even on Linux or other OS, or if
it worth to get a new OMNIKEY device or even another device.

Comments?

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/20170609/c2b73028/attachment.sig>

From ndk.clanbo at gmail.com  Fri Jun  9 10:05:18 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Fri, 9 Jun 2017 10:05:18 +0200
Subject: Key management for archives
In-Reply-To: <87zidhn0f7.fsf@wheatstone.g10code.de>
References: <c723c2f0-826e-170d-869c-83b61e6ce60f@gmail.com>
 <87zidhn0f7.fsf@wheatstone.g10code.de>
Message-ID: <713d5593-6177-61db-8aeb-a5f2aa4fd37d@gmail.com>

Il 09/06/2017 08:24, Werner Koch ha scritto:

>  ( gpg --status-fd 1 --show-session-key --max-output 1 \
>       -o /dev/null 2>/dev/null FILE || true ) \
>    | awk '$1=="[GNUPG:]" && $2=="SESSION_KEY" {print $3}'
> The output can then be used with --override-session-key
Tks! That's exactly what I was looking for.

I'll probably put that in a script that immediately re-encrypts the
session key with the public key of the newly authorized user.
Then he'll decode the session key and use it to decrypt the archive.

BYtE,
 Diego


From stefan.claas at posteo.de  Fri Jun  9 15:50:31 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Fri, 9 Jun 2017 15:50:31 +0200
Subject: TOFU
In-Reply-To: <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
Message-ID: <50c6338d-bb9f-5988-b9de-01bb6333e4a7@posteo.de>

On 07.06.17 14:24, Peter Lebbing wrote:
> On 07/06/17 13:49, Stefan Claas wrote:
>> In Enigmail with the blue and green bar (without showing statistics) it
>> would simply mean
>> that it switches from green to blue, right?
> Not necessarily!
>
I have one more question if you don't mind. One of my tests showed
me the difference between the classic way Enigmail handles the
Untrusted blue signatures and how TOFU handles this.

Now my question as a Mac dummie and TOFU newbie. If Mallory would
gain tomorrow access to my Computer, but not to my passphrase and
he would replace one pub key in my pubring and modify the TOFU
database, how would TOFU handle this? Would TOFU alert me again
that there is a second key with the same email address?

Regards
Stefan




From thomas.orgis at uni-hamburg.de  Fri Jun  9 14:17:24 2017
From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis)
Date: Fri, 9 Jun 2017 14:17:24 +0200
Subject: Behaviour of gpgsm / gpgme with multiple S/MIME certificates/keys
 per address (old/expired/about to expire and new)
Message-ID: <20170609141725.0960338e@cortex.rrz.uni-hamburg.de>

Hi,

I recently got into trouble with S/MIME signing and encryption in
claws-mail, which uses gpgme. My old (first) S/MIME certificate is
about to expire, so I got a new one. I added the new one to gpgsm's
keystore. But after that, claws-mail as well as gpgsm complain about
the keys being ambiguous. Clearly, the call

	gpgsm -u user at example.com

aborts because it cannot decide which of the two certificates to use.
It works when I specify a definite key ID (fingerprint) for -u or just
fix the default one. But what if I have multiple mail addresses, each
with old and new keys lying around?

Is there a way to tell gnupg to prefer a certain key for a given
mail address? While I can fix a key ID in claws-mail, too, this
currently breaks altenating usage of S/MIME and PGP, as currently there
is only one configuration field for the key ID to use for both
(hopefully that will change soon).

With the GPG/PGP part, I revoke my old key and all seems fine. I
somehow fail to see the equivalent mechanism for S/MIME.

I even checked the expiration process, advancing my system clock past
the expiration date of the old certificate. Even then, gpgsm complained
about ambiguous keys. Wouldn't it be sensible to

a) always use the newest S/MIME key with non-expired certificate and
b) discard the ones that are expired by default?

This issue even extended to antoher installation of gnupg/claws-mail
suddenly refusing to use the old key, although I did not yet add the
new secret key to it. They just picked up on the new certificate being
published and hence also consider the keys ambiguous (even if there is
only one secret key).

Any pointers? I wonder if I am doing something basic wrong, as regular
expiration of S/MIME certificates is the norm, isn't it? Doesn't anyone
else have issues with the accumulating number of old certificates?

(I am using GnuPG 2.1.21, gpgme 1.9.0., btw.)


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
Universit?t Hamburg
RRZ / Basis-Infrastruktur / HPC
Schl?terstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4967 bytes
Desc: not available
URL: </pipermail/attachments/20170609/a6e88013/attachment.bin>

From erik at lotspeich.org  Sat Jun 10 06:44:02 2017
From: erik at lotspeich.org (Erik Lotspeich)
Date: Fri, 9 Jun 2017 23:44:02 -0500
Subject: GPG4Win Advice
In-Reply-To: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>
References: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>
Message-ID: <eed952a2-e338-5028-7761-2b289a3853e6@lotspeich.org>

Hi Ian,

Are you using a batch file script to automate the process? Can't the
script delete the files after running the gpg command?

Regards

Erik

On 6/8/2017 09:39, Ian A Morris wrote:
> Hi All,
> 
>  
> 
> I have been tasked with setting up a secure file transfer mechanism for
> our organisation.
> 
> We have created the private keys etc. using Kleopatra and are able to
> encrypt/sign (with asci armor) and decrypt and exchange files with our
> partners successfully.
> 
> I would like to automate the process as follows.
> 
> Users place files in a folder based on a Fileserver.
> 
> GPG4Win (based on our SFTP Server) is scheduled to check the folder,
> encrypt any files it finds placing the encrypted file on the SFTP
> server?s Outbound folder and DELETING the original file on the Fileserver.
> 
> I am able to automate the encryption but the original file stays in
> place. When using the GUI there are options for the following, ?Remove
> unencrypted original file when don?
> 
>  
> 
> Could you please help. I would like to
> 
>  
> 
>  
> 
>  
> 
> I am using the following syntax
> 
>  
> 
> Gpg2 ?batch ?recipient /xxxxx / ?encrypt-files ?armor C:\Location\*.txt
> 
> Which creates the encrypted the files in the same location and the
> orginal files still remain.
> 
>  
> 
> I have tried a number of different options, none of which worked for me.
> 
> If I am able to to encrypt/decrypt and point the files to an alternative
> location and remove the orginals then I would be extremely grateful for
> the help.
> 
>  
> 
>  
> 
> Kind Regards
> 
>  
> 
> Ian A. Morris
> 
> IT Infrastructure Analyst
> 
> ICT Transformation Project
> 
> Int: 7592191
> 
> Tel: 02380 626897
> 
> Mob: +44 7958 216696
> 
> cid:image001.png at 01D214E5.DE402DE0
> 
>  
> 
> 
> 
> _______________________________________________
> 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: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170609/aa2e8c61/attachment.sig>

From kirelagin at gmail.com  Sat Jun 10 15:48:31 2017
From: kirelagin at gmail.com (Kirill Elagin)
Date: Sat, 10 Jun 2017 16:48:31 +0300
Subject: Overwriting a fingerprint in card-status
Message-ID: <CABVT_gfxmA5a4jSxt0AHuKBcLANWrf4Ho56jTU5jOefnXzSjOQ@mail.gmail.com>

Hello,

I have a key on a smartcard and at some point I added it as a subkey
to a different primary key by giving its keygrip in `--expert` mode.

This works great but I recently realised that when this was done its
fingerprint changed and as a result a wrong fingerprint is now stored
in the card metadata, as shown by `--card-status`. (Now I am a little
confused by the fact that gnupg is still able to locate the key and
use it.)

Given that the key material on the card is correct, is there a way to
forcibly overwrite the fingerprint that is displayed by
`--card-status`?

Thanks.


From guru at unixarea.de  Sun Jun 11 20:07:12 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 11 Jun 2017 20:07:12 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
Message-ID: <20170611180712.GA2572@c720-r314251>


How could I change the passphrase I have entered while generating the
keys on the GnuPG card? I tried with no success:

$ LANG=C gpg2 --edit-key Matthias passwd
gpg (GnuPG) 2.1.19; Copyright (C) 2017 Free Software Foundation, Inc.
...

Secret key is available.

sec  rsa4096/47CCF7E476FE9D11
     created: 2017-05-14  expires: never       usage: SC  
     card-no: 0005 0000532B
     trust: ultimate      validity: ultimate
ssb  rsa4096/6AA5C5C451A1CD1C
     created: 2017-05-14  expires: never       usage: A   
     card-no: 0005 0000532B
ssb  rsa4096/61F1ECB625C9A6C3
     created: 2017-05-14  expires: never       usage: E   
     card-no: 0005 0000532B
[ultimate] (1). Matthias Apitz (GnuPG CCID) <guru at unixarea.de>

Key has only stub or on-card key items - no passphrase to change.

gpg> 

Thanks

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170611/d23113be/attachment.sig>

From wk at gnupg.org  Sun Jun 11 20:51:58 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 11 Jun 2017 20:51:58 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <20170611180712.GA2572@c720-r314251> (Matthias Apitz's message of
 "Sun, 11 Jun 2017 20:07:12 +0200")
References: <20170611180712.GA2572@c720-r314251>
Message-ID: <87a85ejr1t.fsf@wheatstone.g10code.de>

On Sun, 11 Jun 2017 20:07, guru at unixarea.de said:
> How could I change the passphrase I have entered while generating the
> keys on the GnuPG card? I tried with no success:

To change the PINs on the card you need to use 

  gpg --card-edit

At the prompt you can directly change the PIN using "passwd" (gpg tries
to keep all 2 or 3 of them in sync) or you  enter "admin" to get this
sub-menu

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



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/20170611/0ae0fff8/attachment-0001.sig>

From wk at gnupg.org  Sun Jun 11 20:54:04 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 11 Jun 2017 20:54:04 +0200
Subject: Fwd: RE: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170609062342.GA2857@c720-r314251> (Matthias Apitz's message of
 "Fri, 9 Jun 2017 08:23:42 +0200")
References: <20170608104855.GB10551@c720-r314251>
 <87bmpxoft1.fsf@wheatstone.g10code.de>
 <20170609062342.GA2857@c720-r314251>
Message-ID: <8760g2jqyb.fsf@wheatstone.g10code.de>

On Fri,  9 Jun 2017 08:23, guru at unixarea.de said:

> Thanks as well for the nice hint about X-message-flag: header line.
> The warning looks really nice in the crappy MS OutLook.

I learned that from Jens Link whom you may know.


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/20170611/a62654b0/attachment.sig>

From wk at gnupg.org  Sun Jun 11 20:59:37 2017
From: wk at gnupg.org (Werner Koch)
Date: Sun, 11 Jun 2017 20:59:37 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170609063910.GB2857@c720-r314251> (Matthias Apitz's message of
 "Fri, 9 Jun 2017 08:39:11 +0200")
References: <20170608102956.GA10333@c720-r314251>
 <877f0lofp3.fsf@wheatstone.g10code.de>
 <20170609063910.GB2857@c720-r314251>
Message-ID: <871sqqjqp2.fsf@wheatstone.g10code.de>

On Fri,  9 Jun 2017 08:39, guru at unixarea.de said:

> I know, this is not a GnuPG issue, but I wanted to mention it here to
> ask if others has similar experiences, even on Linux or other OS, or if
> it worth to get a new OMNIKEY device or even another device.

You better avoid everything with an Omnikey chip in it.  I had only
trouble with it and they never responded to questions.  Well, it works
on Windows because they fix their hardware with their Windows driver.


Shalom-Salam,

   Werner


p.s.
If someone from Omnikey reads this and likes to help getting Omnikey
devices working with current keys sizes under free software OSes, feel
free to contact me off-list.  I won't sign any NDAs, though.

-- 
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/20170611/3f9b228c/attachment.sig>

From guru at unixarea.de  Sun Jun 11 21:05:54 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 11 Jun 2017 21:05:54 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <87a85ejr1t.fsf@wheatstone.g10code.de>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
Message-ID: <20170611190554.GA3515@c720-r314251>

El d?a domingo, junio 11, 2017 a las 08:51:58p. m. +0200, Werner Koch escribi?:

> On Sun, 11 Jun 2017 20:07, guru at unixarea.de said:
> > How could I change the passphrase I have entered while generating the
> > keys on the GnuPG card? I tried with no success:
> 
> To change the PINs on the card you need to use 
> 
>   gpg --card-edit

I know, but I want to change the passphrase, not the PIN.

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170611/8bb43034/attachment.sig>

From peter at digitalbrains.com  Sun Jun 11 21:37:51 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 11 Jun 2017 21:37:51 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <20170611190554.GA3515@c720-r314251>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de> <20170611190554.GA3515@c720-r314251>
Message-ID: <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>

On 11/06/17 21:05, Matthias Apitz wrote:
> I know, but I want to change the passphrase, not the PIN.

They are the same thing, it's just a choice of terminology. Since user
authentication to a smartcard is traditionally done using numerics only
and card readers with PINpads also usually only use numerics, the term
PIN has become commonly used (Personal Identification Number[1]). But
under GnuPG, you can use alphanumerics and symbols, and it is more
correct to call it a passphrase.

Put differently: the secret key stub on disk is a mere unencrypted
reference to a specific smart card. And what then unlocks the smartcard
is the PIN or passphrase passed to the card, which is set as Werner
indicates. There is only one authentication involved, not two. (It's
still two-factor authentication, so that last sentence needs to be taken
in the proper context).

HTH,

Peter.

[1] I'd say "Identification" is a misnomer, it's authentication instead.
Identification is the mere act of naming something, authentication is
providing a means to prove something is authentic, is true, is not fake.
You could identify yourself as Peter Lebbing, but it almost surely would
not be authentic.

(I've always fancied bringing up this point when the police asks me to
"identify myself", but it would be a very bad idea in practice probably :-)

-- 
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/20170611/9a42b461/attachment.sig>

From guru at unixarea.de  Sun Jun 11 21:48:47 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 11 Jun 2017 21:48:47 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
Message-ID: <20170611194847.GA4155@c720-r314251>

El d?a domingo, junio 11, 2017 a las 09:37:51p. m. +0200, Peter Lebbing escribi?:

> On 11/06/17 21:05, Matthias Apitz wrote:
> > I know, but I want to change the passphrase, not the PIN.
> 
> They are the same thing, it's just a choice of terminology. Since user
> authentication to a smartcard is traditionally done using numerics only
> and card readers with PINpads also usually only use numerics, the term
> PIN has become commonly used (Personal Identification Number[1]). But
> under GnuPG, you can use alphanumerics and symbols, and it is more
> correct to call it a passphrase.

I have the feeling, we talk about different things. When I generated the
keys on the card, the following part of the dialog appeared in my
recording:

...
This key (or subkey) is not protected with a passphrase.  Please enter a new passphrase to export it.
Passphrase: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Repeat:
gpg: Note: backup of card key saved to '/home/guru/.gnupg/sk_61F1ECB625C9A6C3.gpg'
gpg: /home/guru/.gnupg/trustdb.gpg: trustdb created
gpg: key 47CCF7E476FE9D11 marked as ultimately trusted
gpg: directory '/home/guru/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/guru/.gnupg/openpgp-revocs.d/5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11.rev'
public and secret key created and signed.
...

My question remains: How can I change (or verify) the above Passphrase I
have used?

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170611/229e0bd7/attachment.sig>

From peter at digitalbrains.com  Sun Jun 11 21:53:20 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 11 Jun 2017 21:53:20 +0200
Subject: GPG4Win Advice
In-Reply-To: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>
References: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>
Message-ID: <744451d7-1cd0-91c2-2784-3af1398d6120@digitalbrains.com>

On 08/06/17 16:39, Ian A Morris wrote:
> When using the GUI there are options for the following, ?Remove
> unencrypted original file when don?

This is an extra convenience added by the GUI program. It is not in the
command line interface.

> Gpg2 ?batch ?recipient /xxxxx / ?encrypt-files ?armor C:\Location\*.txt

The simplest way is to follow this by
> del C:\Location\*.txt

but this introduces a race condition. So it's probably better to do
something like

for x in C:\Location\*.txt
gpg2 ... --encrypt $x
del $x
next

However, it's been many years since I last did anything with
MS-DOS/Windows batch files and I don't have the correct syntax ready. It
needs to bail out when gpg2 errors, but that is way beyond my limited
recollection of batch files.

Oh, and when building a gpg command line, you're supposed to put options
before the command. However, it does try to cope with people putting
options after the command. (And in the quote above, my e-mail client
ended up putting an en-dash where there should be two ascii dashes,
which kinda spoils the didactic value.) I'd suggest the following
command line:

> gpg2 --batch --recipient XX --armour --encrypt-files C:\Location\*.txt

I see you're mailing from a .UK address, so I thought I could point out
armour can be spelled with British spelling as well :-). --armor works
just as well.

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/20170611/0a6a1903/attachment.sig>

From peter at digitalbrains.com  Sun Jun 11 22:00:00 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 11 Jun 2017 22:00:00 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <20170611194847.GA4155@c720-r314251>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de> <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
Message-ID: <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>

On 11/06/17 21:48, Matthias Apitz wrote:
> My question remains: How can I change (or verify) the above Passphrase I
> have used?

Ah! That's the encryption of the backup key, not of the secret key
stored in the smart card. Well, it's ultimately the same key, but it's
not the copy of it stored in the smart card but rather the copy stored
in the backup file.

That's actually a difficult question, since AFAIK, the backups are not
complete OpenPGP messages but just the relevant parts of an OpenPGP
secret key message. I actually can't think of the answer to your
question. I'd know how to use packet surgery to reconstruct a normal
on-disk secret key from that partial message, and subsequently change
the passphrase on that key. I could also subsequently extract the
fragment again. But this is all not normal use of GnuPG, it's "Look, I
can make it do this as well!". Hopefully somebody else can answer if it
is possible, and how.

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/20170611/e9b988ff/attachment-0001.sig>

From tlikonen at iki.fi  Sun Jun 11 20:55:03 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Sun, 11 Jun 2017 21:55:03 +0300
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <20170611180712.GA2572@c720-r314251> (Matthias Apitz's message of
 "Sun, 11 Jun 2017 20:07:12 +0200")
References: <20170611180712.GA2572@c720-r314251>
Message-ID: <87mv9enym0.fsf@mithlond.arda>

Matthias Apitz [2017-06-11 20:07:12+02] wrote:

> How could I change the passphrase I have entered while generating the
> keys on the GnuPG card? I tried with no success:
>
> $ LANG=C gpg2 --edit-key Matthias passwd

"gpg2 --edit-key" is for normal keyrings. Your key is on the card so you
edit the card with "gpg2 --card-edit" and then change card's password(s)
with "admin" > "passwd".

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170611/a75303b4/attachment.sig>

From guru at unixarea.de  Mon Jun 12 07:31:58 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Jun 2017 07:31:58 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
Message-ID: <20170612053158.GA2502@c720-r314251>

El d?a domingo, junio 11, 2017 a las 10:00:00p. m. +0200, Peter Lebbing escribi?:

> On 11/06/17 21:48, Matthias Apitz wrote:
> > My question remains: How can I change (or verify) the above Passphrase I
> > have used?
> 
> Ah! That's the encryption of the backup key, not of the secret key
> stored in the smart card. Well, it's ultimately the same key, but it's
> not the copy of it stored in the smart card but rather the copy stored
> in the backup file.
> 
> That's actually a difficult question, since AFAIK, the backups are not
> complete OpenPGP messages but just the relevant parts of an OpenPGP
> secret key message. I actually can't think of the answer to your
> question. I'd know how to use packet surgery to reconstruct a normal
> on-disk secret key from that partial message, and subsequently change
> the passphrase on that key. I could also subsequently extract the
> fragment again. But this is all not normal use of GnuPG, it's "Look, I
> can make it do this as well!". Hopefully somebody else can answer if it
> is possible, and how.

Now we are on track with my question. The background is/was: what
exactly I have todo with this backup key, for example in case the GnuPG
card gets lost or stolen? How can I simulate this and check if the
passphrase works correctly.

Thx

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170612/19dc8ae3/attachment.sig>

From Ian.Morris at BimshireConsultancy.co.uk  Mon Jun 12 00:40:11 2017
From: Ian.Morris at BimshireConsultancy.co.uk (Ian A Morris)
Date: Sun, 11 Jun 2017 23:40:11 +0100
Subject: GPG4Win Advice
In-Reply-To: <744451d7-1cd0-91c2-2784-3af1398d6120@digitalbrains.com>
References: <HE1PR09MB0058F50E9D7940CDD9DDF88480C90@HE1PR09MB0058.eurprd09.prod.outlook.com>
 <744451d7-1cd0-91c2-2784-3af1398d6120@digitalbrains.com>
Message-ID: <011001d2e303$afd2cac0$0f786040$@BimshireConsultancy.co.uk>

Hi Peter,

Thank you very much for your email. It has answered a lot of the queries I had. Going forward, I think I may be able to wrap this all up in a PowerShell script to enable the removal of the original files and the required error checking. Most likely I will create a temp csv from the contents of the folder, process each file, check that there is an .txt and .asc of each file present and then move the .asc files to the required outbound folder and then move the unencrypted file to and archive on  separate fileserver. I can move forward with this because of your email. 

Many Thanks for your assistance!!!!

Kind Regards

Ian A Morris
IT Consultant
Bimshire Consultancy Ltd
Mobile   : +44 (0)7958 216696
Email       :  Ian.Morris at BimshireConsultancy.co.uk
Website : www.BimshireConsultancy.co.uk
 

-----Original Message-----
From: Peter Lebbing [mailto:peter at digitalbrains.com] 
Sent: 11 June 2017 20:53
To: Ian A Morris; gnupg-users at gnupg.org
Cc: Ian A Morris
Subject: Re: GPG4Win Advice

On 08/06/17 16:39, Ian A Morris wrote:
> When using the GUI there are options for the following, ?Remove 
> unencrypted original file when don?

This is an extra convenience added by the GUI program. It is not in the command line interface.

> Gpg2 ?batch ?recipient /xxxxx / ?encrypt-files ?armor 
> C:\Location\*.txt

The simplest way is to follow this by
> del C:\Location\*.txt

but this introduces a race condition. So it's probably better to do something like

for x in C:\Location\*.txt
gpg2 ... --encrypt $x
del $x
next

However, it's been many years since I last did anything with MS-DOS/Windows batch files and I don't have the correct syntax ready. It needs to bail out when gpg2 errors, but that is way beyond my limited recollection of batch files.

Oh, and when building a gpg command line, you're supposed to put options before the command. However, it does try to cope with people putting options after the command. (And in the quote above, my e-mail client ended up putting an en-dash where there should be two ascii dashes, which kinda spoils the didactic value.) I'd suggest the following command line:

> gpg2 --batch --recipient XX --armour --encrypt-files C:\Location\*.txt

I see you're mailing from a .UK address, so I thought I could point out armour can be spelled with British spelling as well :-). --armor works just as well.

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>




From guru at unixarea.de  Mon Jun 12 12:38:25 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Jun 2017 12:38:25 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <871sqqjqp2.fsf@wheatstone.g10code.de>
References: <20170608102956.GA10333@c720-r314251>
 <877f0lofp3.fsf@wheatstone.g10code.de>
 <20170609063910.GB2857@c720-r314251>
 <871sqqjqp2.fsf@wheatstone.g10code.de>
Message-ID: <20170612103825.GA4341@c720-r314251>

El d?a domingo, junio 11, 2017 a las 08:59:37p. m. +0200, Werner Koch escribi?:

> On Fri,  9 Jun 2017 08:39, guru at unixarea.de said:
> 
> > I know, this is not a GnuPG issue, but I wanted to mention it here to
> > ask if others has similar experiences, even on Linux or other OS, or if
> > it worth to get a new OMNIKEY device or even another device.
> 
> You better avoid everything with an Omnikey chip in it.  I had only
> trouble with it and they never responded to questions.  Well, it works
> on Windows because they fix their hardware with their Windows driver.

Do you know of any other CCID reader for ID-000 size cards?

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170612/80f81fa2/attachment.sig>

From wk at gnupg.org  Mon Jun 12 12:58:23 2017
From: wk at gnupg.org (Werner Koch)
Date: Mon, 12 Jun 2017 12:58:23 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <20170612103825.GA4341@c720-r314251> (Matthias Apitz's message of
 "Mon, 12 Jun 2017 12:38:25 +0200")
References: <20170608102956.GA10333@c720-r314251>
 <877f0lofp3.fsf@wheatstone.g10code.de>
 <20170609063910.GB2857@c720-r314251>
 <871sqqjqp2.fsf@wheatstone.g10code.de>
 <20170612103825.GA4341@c720-r314251>
Message-ID: <87wp8hh3qo.fsf@wheatstone.g10code.de>

On Mon, 12 Jun 2017 12:38, guru at unixarea.de said:

> Do you know of any other CCID reader for ID-000 size cards?

I have a sample of the Gemalto Shell Token here.  It has been around for
quite some time and the kernelconcept folks that it works nicely.  See

  https://www.floss-shop.de/en/security-privacy/

On that page you also find the a bit more expensive uTrust token which
would be my preferred choice. I used it for many years until it broke due
to my fault.  In fact I recycled the case for my gnuk token.


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/20170612/33811aeb/attachment.sig>

From dgouttegattat at incenp.org  Mon Jun 12 13:28:28 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 12 Jun 2017 13:28:28 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <20170612053158.GA2502@c720-r314251>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de> <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
Message-ID: <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>

On 06/12/2017 07:31 AM, Matthias Apitz wrote:
> Now we are on track with my question. The background is/was: what
> exactly I have todo with this backup key, for example in case the GnuPG
> card gets lost or stolen?

You would have to import your backup key into your private keyring using 
gpg's --import command.

First, remove the private key stubs:

   $ rm ~/.gnupg/private-keys-v1.d/*.key

Then, import your backup:

   $ gpg2 --import backup.gpg

You will then be prompted for the passphrase you choose when the backup 
was created.

At this point, it's as if you had never used a smartcard.

Once you have a new smartcard to replace your lost one, you may move the 
restored keys to the new smartcard using the keytocard command.

(Note that depending on what happened to your original card, you may 
prefer to *revoke* those keys and generate new keys.)


> How can I simulate this and check if the passphrase works correctly.

Copy your current .gnupg directory to a temporary GNUPGHOME:

   $ cp -r .gnupg ~/testbackup
   $ export GNUPGHOME=~/testbackup

Then you can test the above procedure:

- Remove the key stubs:

   $ rm ~/testbackup/private-keys-v1.d/*.key

- Import your backup:

   $ gpg2 --import backup.gpg

At this point, you will know if the passphrase works correctly.

And if you want to change the passphrase of your backup:

   $ gpg2 --edit-key Matthias passwd
   $ gpg2 -o backup-with-new-password.gpg --export-secret-keys

Once you are satisfied, you can wipe the testbackup directory out.

Hope that helps,

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/20170612/a515af2d/attachment.sig>

From dgouttegattat at incenp.org  Mon Jun 12 13:45:18 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 12 Jun 2017 13:45:18 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de> <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
Message-ID: <c85837fa-7ab0-cc6f-d54b-93fea1fce240@incenp.org>

I forgot an important detail:

On 06/12/2017 01:28 PM, Damien Goutte-Gattat wrote:
> First, remove the private key stubs:
> 
>    $ rm ~/.gnupg/private-keys-v1.d/*.key

This command will delete *all* your private keys. You should use it "as 
is" only if *all* your private keys are stored on a smartcard.

If you have other private keys in your keyring that are not stored on a 
smartcard, do *not* delete all files in ~/.gnupg/private-keys-v1.d! 
Instead, get the keygrip of each of your card keys

   $ gpg2 --with-keygrip --list-secret-keys

and delete only the corresponding files under ~/.gnupg/private-keys-v1.d.

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/20170612/240b8cf6/attachment-0001.sig>

From guru at unixarea.de  Mon Jun 12 14:15:01 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Jun 2017 14:15:01 +0200
Subject: changing the passphrase of the secret key stored in the GnuPG card
In-Reply-To: <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
Message-ID: <20170612121501.GB5010@c720-r314251>

El d?a lunes, junio 12, 2017 a las 01:28:28p. m. +0200, Damien Goutte-Gattat escribi?:

> On 06/12/2017 07:31 AM, Matthias Apitz wrote:
> > Now we are on track with my question. The background is/was: what
> > exactly I have todo with this backup key, for example in case the GnuPG
> > card gets lost or stolen?
> 
> You would have to import your backup key into your private keyring using 
> gpg's --import command.
> 
> First, remove the private key stubs:
> 
>    $ rm ~/.gnupg/private-keys-v1.d/*.key
> 
> Then, import your backup:
> 
>    $ gpg2 --import backup.gpg
> 
> You will then be prompted for the passphrase you choose when the backup 
> was created.

I did what you suggested, but:

$ pwd
/home/guru/.gnupg-test
$ rm -f private-keys-v1.d/*.key
$ GNUPGHOME=/home/guru/.gnupg-test export GNUPGHOME
gpg2 --import sk_61F1ECB625C9A6C3.gpg
gpg: key 61F1ECB625C9A6C3: no user ID
gpg: Total number processed: 1
gpg:       secret keys read: 1
$ ls -l sk_61F1ECB625C9A6C3.gpg
-r--------  1 guru  wheel  1865 May 14 20:29 sk_61F1ECB625C9A6C3.gpg

the file is what was swritte as backup on May 14.

Any idea what I do wrong?

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170612/cca3d66b/attachment.sig>

From stefan.claas at posteo.de  Mon Jun 12 14:52:29 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 14:52:29 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
Message-ID: <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>



On 07.06.17 22:23, Ludwig H?gelsch?fer wrote:
> Hi Stefan,
>
> On 06.06.17 22:19, Stefan Claas wrote:
>> On 06.06.17 20:46, Charlie Jonas wrote:
>>> On 2017-06-06 19:12, Stefan Claas wrote:
>>>> I tried also with Enigmail under OS X but when checking the
>>>> signatures here from the list members i always get the blue
>>>> "Untrusted Good Signature".
>>> Yes I get this as well. Interestingly whatever trust level I give
>>> keys, Enigmail on OSX seems to want to make the bar blue
>>> regardless.
>>>
>> Thanks for confirming. Hopefully Ludwig still follows this thread
>> and can tell us why it's not working, as expected.
> It's working as expected. To get a green bar in Enigmails header
> display, the key signing the message has to be at least fully valid. A
> key gets valid if you either:
>
> - sign it (whether local or exportable is not relevant)
>
> or
>
> - it is signed by
>   - at least one key you have signed and you have put "full" ownertrust
>     on these
>   - at least three other keys you have signed and you have put
>     "marginal" ownertrust on these
>
> This is the behaviour of the "classic" or "PGP" trust model which is
> the default in GnuPG. Enigmail only displays the result.
>
>
Hi Ludwig,

I just checked again. On my Mac and on my Windows Notebook
i get a green bar , from a blue "Untrusted" key when i go into
Enigmails Key Management and set the trust of that key to
Ultimate...

Regards
Stefan






From peter at digitalbrains.com  Mon Jun 12 16:06:55 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 12 Jun 2017 16:06:55 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
Message-ID: <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>

On 12/06/17 14:52, Stefan Claas wrote:
> I just checked again. On my Mac and on my Windows Notebook
> i get a green bar , from a blue "Untrusted" key when i go into
> Enigmails Key Management and set the trust of that key to
> Ultimate...

Don't do this! Or did you do it just for testing? "Ultimate" is for your
own keys. It makes the key itself valid and all keys signed by that key.
It's the odd one out, as the other trust levels only determine the
validity of other keys signed by that key but don't affect the key itself.

To make a key valid, sign it with a local signature. Or an exportable
signature, your choice.

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/20170612/c6d67f1f/attachment.sig>

From stefan.claas at posteo.de  Mon Jun 12 16:14:16 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 16:14:16 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
Message-ID: <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>

On 12.06.17 16:06, Peter Lebbing wrote:
> On 12/06/17 14:52, Stefan Claas wrote:
>> I just checked again. On my Mac and on my Windows Notebook
>> i get a green bar , from a blue "Untrusted" key when i go into
>> Enigmails Key Management and set the trust of that key to
>> Ultimate...
> Don't do this! Or did you do it just for testing? "Ultimate" is for your
> own keys. It makes the key itself valid and all keys signed by that key.
> It's the odd one out, as the other trust levels only determine the
> validity of other keys signed by that key but don't affect the key itself.
>
> To make a key valid, sign it with a local signature. Or an exportable
> signature, your choice.
>

I did that for testing! And a question for this... If Mallory would get
somehow access to my Computer and replace one pub key from my
communication partners with a fake one and sets the trust level to
Ultimate. How can i detect this, if i'm not always looking at the
complete Fingerprint and compare it with a separate list?

Regards
Stefan




From peter at digitalbrains.com  Mon Jun 12 16:31:25 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 12 Jun 2017 16:31:25 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
 <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
Message-ID: <c859aa29-6920-7445-9024-97d3dbabea64@digitalbrains.com>

I hadn't gotten round to answer your earlier questions yet, since I
noticed a point I should first spend some effort and thinking on.

On 12/06/17 16:14, Stefan Claas wrote:
> And a question for this... If Mallory would get
> somehow access to my Computer and replace one pub key from my
> communication partners with a fake one and sets the trust level to
> Ultimate. How can i detect this, if i'm not always looking at the
> complete Fingerprint and compare it with a separate list?

It is impossible to use any form of cryptography in a secure fashion
when somebody is in a position to mess with the computer you're using it
on. Worst is someone with administrator privileges, but somebody with
the same privileges as you is already more than enough to completely
subvert your security.

They could alter your search path and put their own binaries in them.
Any program you launch, be it GnuPG, your e-mail client, your shell, or
any other program you use, could be replaced by something else. Same for
your data files, as you point out.

Your user account needs to be secure from evildoers. It depends on your
threat model how you go about this.

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/20170612/44f0a6e8/attachment.sig>

From stefan.claas at posteo.de  Mon Jun 12 16:46:39 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 16:46:39 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <c859aa29-6920-7445-9024-97d3dbabea64@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
 <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
 <c859aa29-6920-7445-9024-97d3dbabea64@digitalbrains.com>
Message-ID: <a071aaf7-6c1d-8e8a-6b8f-9628a570b049@posteo.de>

On 12.06.17 16:31, Peter Lebbing wrote:
> I hadn't gotten round to answer your earlier questions yet, since I
> noticed a point I should first spend some effort and thinking on.
>
> On 12/06/17 16:14, Stefan Claas wrote:
>> And a question for this... If Mallory would get
>> somehow access to my Computer and replace one pub key from my
>> communication partners with a fake one and sets the trust level to
>> Ultimate. How can i detect this, if i'm not always looking at the
>> complete Fingerprint and compare it with a separate list?
> It is impossible to use any form of cryptography in a secure fashion
> when somebody is in a position to mess with the computer you're using it
> on. Worst is someone with administrator privileges, but somebody with
> the same privileges as you is already more than enough to completely
> subvert your security.
>
> They could alter your search path and put their own binaries in them.
> Any program you launch, be it GnuPG, your e-mail client, your shell, or
> any other program you use, could be replaced by something else. Same for
> your data files, as you point out.
>
> Your user account needs to be secure from evildoers. It depends on your
> threat model how you go about this.

I agree with you and it makes perfect sense, but then it would raise
another question. How should an average user of GnuPG, like me,
then handle this. I mean what you just said is not mentioned in
GnuPG tutorials and you can't expect that every GnuPG is trained
on that subject as well.

Would it then not be good if Enigmail, for the casual user, would
display a different color than green, for the explained scenario?

Regards
Stefan





From rjh at sixdemonbag.org  Mon Jun 12 17:19:03 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jun 2017 11:19:03 -0400
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
 <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
Message-ID: <d5c7f865-4980-a953-c9bd-a59eae737622@sixdemonbag.org>

> If Mallory would get somehow access to my Computer and replace one
> pub key from my communication partners with a fake one and sets the
> trust level to Ultimate. How can i detect this, if i'm not always
> looking at the complete Fingerprint and compare it with a separate
> list?

If Mallory can tamper with your keyrings, that's a total game-over
condition.  At that point there are dozens of attacks open to her.  Once
you lose control of your computer, it's all over.


From rjh at sixdemonbag.org  Mon Jun 12 17:28:47 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jun 2017 11:28:47 -0400
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a071aaf7-6c1d-8e8a-6b8f-9628a570b049@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
 <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
 <c859aa29-6920-7445-9024-97d3dbabea64@digitalbrains.com>
 <a071aaf7-6c1d-8e8a-6b8f-9628a570b049@posteo.de>
Message-ID: <5fff9b1b-971d-f1e7-3240-5da004467861@sixdemonbag.org>

> I agree with you and it makes perfect sense, but then it would raise
> another question. How should an average user of GnuPG, like me,
> then handle this.

It cannot be the job of the GnuPG team to teach people how to safely
administer their operating system.  There are too many operating
systems, too many different threat models, too many different use cases,
for anyone to go down that rabbit-hole.

Some generally good advice might include:

- Keep your operating system up to date
- Disable Flash in your browser
- Disable Java Web Start in your browser
- Install ad blocking and tracker blocking plugins into your browser
- Only run software from trusted sources
- Only use USB thumb drives with machines you trust
- Only use USB thumb drives that came from trusted sources


From stefan.claas at posteo.de  Mon Jun 12 17:39:11 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 17:39:11 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <5fff9b1b-971d-f1e7-3240-5da004467861@sixdemonbag.org>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <6ec57079-4e0c-6cc1-a5e0-5aa213e6fd24@digitalbrains.com>
 <b00389af-fbf4-e81d-aea8-b5cb762b6a60@posteo.de>
 <c859aa29-6920-7445-9024-97d3dbabea64@digitalbrains.com>
 <a071aaf7-6c1d-8e8a-6b8f-9628a570b049@posteo.de>
 <5fff9b1b-971d-f1e7-3240-5da004467861@sixdemonbag.org>
Message-ID: <8933f304-5b5f-21d6-a789-4474af4d72d1@posteo.de>



On 12.06.17 17:28, Robert J. Hansen wrote:
>> I agree with you and it makes perfect sense, but then it would raise
>> another question. How should an average user of GnuPG, like me,
>> then handle this.
> It cannot be the job of the GnuPG team to teach people how to safely
> administer their operating system.  There are too many operating
> systems, too many different threat models, too many different use cases,
> for anyone to go down that rabbit-hole.
>
> Some generally good advice might include:
>
> - Keep your operating system up to date
> - Disable Flash in your browser
> - Disable Java Web Start in your browser
> - Install ad blocking and tracker blocking plugins into your browser
> - Only run software from trusted sources
> - Only use USB thumb drives with machines you trust
> - Only use USB thumb drives that came from trusted sources
>
Thank you very much for the tip about USB thumb drives!

Regards
Stefan




From guru at unixarea.de  Mon Jun 12 20:12:57 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 12 Jun 2017 20:12:57 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170612121501.GB5010@c720-r314251>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
Message-ID: <20170612181257.GA2545@c720-r314251>


Please note: I have changed the Subject: of the thread to match better
the real problem. 

During generating the keys on the GnuPG card, one can (and should)
create some backup of the secret key into a file. It is totally unclear
to me how to make something usefull out of this file, for example import
it into a "normal" secret keyring to use it in case of the GnuPG acrd
gots lost.

I followed some hints of  Damien Goutte-Gattat (thanks) and did:

> > First, remove the private key stubs:
> > 
> >    $ rm ~/.gnupg/private-keys-v1.d/*.key
> > 
> > Then, import your backup:
> > 
> >    $ gpg2 --import backup.gpg
> > 
> > You will then be prompted for the passphrase you choose when the backup 
> > was created.
> 
> I did what you suggested, but:
> 
> $ pwd
> /home/guru/.gnupg-test
> $ rm -f private-keys-v1.d/*.key
> $ GNUPGHOME=/home/guru/.gnupg-test export GNUPGHOME
> $ gpg2 --import sk_61F1ECB625C9A6C3.gpg
> gpg: key 61F1ECB625C9A6C3: no user ID
> gpg: Total number processed: 1
> gpg:       secret keys read: 1
> $ ls -l sk_61F1ECB625C9A6C3.gpg
> -r--------  1 guru  wheel  1865 May 14 20:29 sk_61F1ECB625C9A6C3.gpg
> 
> the file is what was swritte as backup on May 14.
> 

With Don Google I found this older thread in this mailing list here:

https://lists.gt.net/gnupg/users/40851

where Werner said after some (today outdated) hints:

?... 
Put a "disable-scdaemon" into gpg-agent.conf, give gpg-agent a HUP and
check that no scdaemon is running anymore (you may just kill it). Then
use "gpg --no-use-agent --edit-key". The command "bkuptocard" may then
be used to store a backup key on a card.

Yes, we really need a howto on recovering smartcard keys. ...?

Was such a howto ever written?

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170612/8cc65c15/attachment.sig>

From ludwig at enigmail.net  Mon Jun 12 20:18:42 2017
From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=)
Date: Mon, 12 Jun 2017 20:18:42 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
Message-ID: <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>

Hi,

On 12.06.17 14:52, Stefan Claas wrote:

> Hi Ludwig,
> 
> I just checked again. On my Mac and on my Windows Notebook i get a
> green bar , from a blue "Untrusted" key when i go into Enigmails
> Key Management and set the trust of that key to Ultimate...

Well, ultimate ownertrust is the wrong way. This setting is reserved
for your own keys. No wonder you get a green header bar.

What are you trying to achieve? I'm getting tons of "UNTRUSTED Good
signature" when reading my mailing lists, e.g. from Peter Lebbing and
a lot of others. That's the way it is, I have to accept this, my
web-of-trust is not so good. I've got a couple of good signatures, though.

One way to improve this situation is to get out, meet people, view
their Ids and receive their fingerprints, verify them and if all is
good, sign their keys.

The other would be to enable TOFU. Can't tell anything about this, I
still have to test.

Best regards

Ludwig

-------------- 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/20170612/5fad858f/attachment.sig>

From stefan.claas at posteo.de  Mon Jun 12 20:51:05 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 20:51:05 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
Message-ID: <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>

On 12.06.17 20:18, Ludwig H?gelsch?fer wrote:
> Hi,
>
> On 12.06.17 14:52, Stefan Claas wrote:
>
>> Hi Ludwig,
>>
>> I just checked again. On my Mac and on my Windows Notebook i get a
>> green bar , from a blue "Untrusted" key when i go into Enigmails
>> Key Management and set the trust of that key to Ultimate...
> Well, ultimate ownertrust is the wrong way. This setting is reserved
> for your own keys. No wonder you get a green header bar.
>
> What are you trying to achieve? 
>

Well, i assume that the majority of people who are using GnuPG
are using it with Thunderbird/Enigmail. Let's also assume they are
not security experts like all you guys here on the list and let's
also assume they are following popular tutorials like the ones
from EFF: https://ssd.eff.org/en/module/how-use-pgp-windows
because they know EFF are good people (like you security experts).

Now here is my thought. Mallory knows this very well what i have
described above and after he gained access to my computer he
simply replaces on of my locally signed pub keys with a fake
one where he sets owner trust to ultimate. A user, described as
above would imho have a hard time to detect a fake pub key,
because Enigmail shows for both keys a green bar.

Maybe as an additional security feature Enigmail should give
a key with a set trust level of "Ultimate" a different color than
green.

Regards
Stefan





From peter at digitalbrains.com  Mon Jun 12 21:15:26 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 12 Jun 2017 21:15:26 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
Message-ID: <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>

On 12/06/17 20:51, Stefan Claas wrote:
> Maybe as an additional security feature Enigmail should give
> a key with a set trust level of "Ultimate" a different color than
> green.

No, that's beside the point. Once somebody gets your user privileges,
there is no "additional security". It's game over. They could replace
your Enigmail with their Evilmail, which seems like a good name for an
Enigmail edited to show any fingerprint the attacker desires and give it
any colour of the rainbow.

You need to make sure your computer doesn't get hacked by someone who
wants to subvert your use of GnuPG. Luckily, for most of us, we get
hacked to send spam... ;)

(Remember there are two types of companies. Those who know they got
hacked and those who don't know yet that they got hacked.)

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/20170612/76a98a94/attachment.sig>

From ludwig at enigmail.net  Mon Jun 12 21:21:36 2017
From: ludwig at enigmail.net (=?UTF-8?B?THVkd2lnIEjDvGdlbHNjaMOkZmVy?=)
Date: Mon, 12 Jun 2017 21:21:36 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
Message-ID: <36fe08cb-80b2-6d29-d8d5-c1555f187d06@enigmail.net>

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

On 12.06.17 20:51, Stefan Claas wrote:
> On 12.06.17 20:18, Ludwig H?gelsch?fer wrote:
>> Hi,
>> 
>> On 12.06.17 14:52, Stefan Claas wrote:
>> 
>>> Hi Ludwig,
>>> 
>>> I just checked again. On my Mac and on my Windows Notebook i
>>> get a green bar , from a blue "Untrusted" key when i go into
>>> Enigmails Key Management and set the trust of that key to
>>> Ultimate...
>> Well, ultimate ownertrust is the wrong way. This setting is
>> reserved for your own keys. No wonder you get a green header
>> bar.
>> 
>> What are you trying to achieve?
>> 
> 
> Well, i assume that the majority of people who are using GnuPG are
> using it with Thunderbird/Enigmail.

I'd not sign this statement. A lot of users caring for privacy and
safety won't go for Windows. Thunderbird is not the most popular mail
client on non-windows computers, there quite some other mail clients.

> Let's also assume they are not security experts like all you guys
> here on the list and let's also assume they are following popular
> tutorials like the ones from EFF:
> https://ssd.eff.org/en/module/how-use-pgp-windows because they know
> EFF are good people (like you security experts).
> 
> Now here is my thought. Mallory knows this very well what i have 
> described above and after he gained access to my computer he simply
> replaces on of my locally signed pub keys with a fake one where he
> sets owner trust to ultimate. A user, described as above would imho
> have a hard time to detect a fake pub key, because Enigmail shows
> for both keys a green bar.

As Robert said: If an attacker gains control over your computer,
you're busted, game over.

> Maybe as an additional security feature Enigmail should give a key
> with a set trust level of "Ultimate" a different color than green.

This would also be the case if the attacker gained access to your
computer.

What you can do: Learn, learn by playing, learn by trying to
understand what others write and by asking questions and become a
reasonable critical user. That's the hard way, but you learn best.
Second possibility would be to have a good experienced friend which
guides you along the way. Third way would be to engage an expert which
maintains your computer.

Ludwig
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE4WAgb7FA4aaVxJnYOtv6bQCh5v4FAlk+6b4ACgkQOtv6bQCh
5v7yeg/+NG1ZJOm/is1MyiDI8eGHB2343qmCYjzlrpj5+SYBECMa5FSKqh86z+LS
xMbynzfMIVTR2imt259mHFhCCcBgx067GCCxCFOMgJgafYg0M/kf1bOQF1Hov1lD
969zfYBcHNl2lnOSA5W16nJPY0gaJoa6t+25bf3YDD/+1aMQdZpBmOpxEPPuMUqt
5Qb7LPHh0hhSNoX7TrTqcMEBQtJopDlB94xUShUujMR56udC1Mfo3LDN1BpV00sd
R+La+a94Uu+i9FkEhjFHeTcVlaN9TSofLqGBVID51h2sGG7UK/moOAv55T2GBkuh
zdTp9OirN1OIZbBIMnUfa3oe3ZbCyY24qm/XWA7gn4gTIUX9/QdT6Wz/aBDA9Rq+
fr5RDxXU5S/4kX3HODnUiGqvt8HElQAKmCkiTD6gSLM8Tsw6Bp1DK9AAMHEbgvqS
zT67rKY4ISzW4RTxqHuK4W1bury0TdSlyCCgL33CdUp+xhQazjLRfUQXzSeOaNu2
7/6LRVtOHWWUkpELaNGYGS2CPDMiPvuZuMH/Ut9CYcwGHaf1Rq2F7FH0C2Hha5Uf
6hHWVww+PrNg1Tera/yLn+P8+RCU5tkf8c+injiEN0FjYScXd0YBds704ZjdD8l8
tld1uAcxxI3FYybY05TSjKqdRNpGrJRJ14nb4Djd896jzOZDWJQ=
=CZYK
-----END PGP SIGNATURE-----


From stefan.claas at posteo.de  Mon Jun 12 21:34:42 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 21:34:42 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
Message-ID: <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>

On 12.06.17 21:15, Peter Lebbing wrote:
> On 12/06/17 20:51, Stefan Claas wrote:
>> Maybe as an additional security feature Enigmail should give
>> a key with a set trust level of "Ultimate" a different color than
>> green.
> No, that's beside the point. Once somebody gets your user privileges,
> there is no "additional security". It's game over. They could replace
> your Enigmail with their Evilmail, which seems like a good name for an
> Enigmail edited to show any fingerprint the attacker desires and give it
> any colour of the rainbow.
>
> You need to make sure your computer doesn't get hacked by someone who
> wants to subvert your use of GnuPG. Luckily, for most of us, we get
> hacked to send spam... ;)
>
> (Remember there are two types of companies. Those who know they got
> hacked and those who don't know yet that they got hacked.)
>
>

Thanks for your thought! So what i have learned from this whole
thread, also about my proposal for identicons, i should buy me
an offline computer, send Thunderbird/Enigmail to /dev/null
and transfer signed/encrypted messages from my online usage
computer with a USB stick to my offline computer and verify
decrypt the messages there. :-)

Regards
Stefan




From stefan.claas at posteo.de  Mon Jun 12 21:37:03 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 21:37:03 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <36fe08cb-80b2-6d29-d8d5-c1555f187d06@enigmail.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <36fe08cb-80b2-6d29-d8d5-c1555f187d06@enigmail.net>
Message-ID: <36c84de4-7f1f-f1d2-07c9-ae518c370917@posteo.de>

On 12.06.17 21:21, Ludwig H?gelsch?fer wrote:
> What you can do: Learn, learn by playing, learn by trying to
> understand what others write and by asking questions and become a
> reasonable critical user. That's the hard way, but you learn best.
> Second possibility would be to have a good experienced friend which
> guides you along the way. Third way would be to engage an expert which
> maintains your computer.
>
Thanks also for your valuable reply!

Please see also my reply to Peter.

Regards
Stefan





From stefan.claas at posteo.de  Mon Jun 12 21:57:31 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 21:57:31 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
Message-ID: <51a584a5-1b28-38c5-9b88-11820c907eed@posteo.de>

On 12.06.17 21:15, Peter Lebbing wrote:

>> (Remember there are two types of companies. Those who know they got
>> hacked and those who don't know yet that they got hacked.)
>>
>>
I should put that as a signature in my email and Usenet client! :-)

Regards
Stefan




From rjh at sixdemonbag.org  Mon Jun 12 22:10:38 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jun 2017 16:10:38 -0400
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
Message-ID: <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>

> and transfer signed/encrypted messages from my online usage
> computer with a USB stick to my offline computer and verify
> decrypt the messages there. :-)

If you think your online computer may be compromised, then you have no
business sharing USB devices between it and your believed-safe computer.



From stefan.claas at posteo.de  Mon Jun 12 22:28:12 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 22:28:12 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
Message-ID: <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>

On 12.06.17 22:10, Robert J. Hansen wrote:
>> and transfer signed/encrypted messages from my online usage
>> computer with a USB stick to my offline computer and verify
>> decrypt the messages there. :-)
> If you think your online computer may be compromised, then you have no
> business sharing USB devices between it and your believed-safe computer.
>
O.k., i have for example no Tempest Attack, etc. shielded offline computer,
because i am only a little Mac user. Is there something like a Standard
Operating
Procedure for GnuPG available, which fulfills security experts demands,
and which
can easily be adapted by an average GnuPG user, regardless of platform
and client
he/she uses?

Regards
Stefan



From rjh at sixdemonbag.org  Mon Jun 12 22:35:06 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jun 2017 16:35:06 -0400
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
Message-ID: <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>

> Is there something like a Standard Operating Procedure for GnuPG
> available, which fulfills security experts demands, and which can
> easily be adapted by an average GnuPG user, regardless of platform 
> and client he/she uses?

No.  More to the point, there can't be.  Each user faces threats
specific to that user; each user is responsible for their own threat
modeling.

But follow the steps I outlined before and you'll significantly improve
your online security.  You won't be perfect -- there is no such thing as
perfection.  You won't be a hardened target -- that takes a lot of work.
 But follow those steps and you'll have taken care of the easy ways that
your machine can be compromised.


From stefan.claas at posteo.de  Mon Jun 12 22:45:26 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 12 Jun 2017 22:45:26 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
 <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
Message-ID: <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>

On 12.06.17 22:35, Robert J. Hansen wrote:
>> Is there something like a Standard Operating Procedure for GnuPG
>> available, which fulfills security experts demands, and which can
>> easily be adapted by an average GnuPG user, regardless of platform 
>> and client he/she uses?
> No.  More to the point, there can't be.  Each user faces threats
> specific to that user; each user is responsible for their own threat
> modeling.
>
> But follow the steps I outlined before and you'll significantly improve
> your online security.  You won't be perfect -- there is no such thing as
> perfection.  You won't be a hardened target -- that takes a lot of work.
>  But follow those steps and you'll have taken care of the easy ways that
> your machine can be compromised.
>

Thank you very much for your advise, much appreciated!

Regards
Stefan



From duane at nofroth.com  Mon Jun 12 23:50:20 2017
From: duane at nofroth.com (Duane Whitty)
Date: Mon, 12 Jun 2017 18:50:20 -0300
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
 <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
 <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>
Message-ID: <ccd59e47-ce7f-9f1b-5ac8-c1329a4d0ec5@nofroth.com>



On 17-06-12 05:45 PM, Stefan Claas wrote:
> On 12.06.17 22:35, Robert J. Hansen wrote:
>>> Is there something like a Standard Operating Procedure for GnuPG
>>> available, which fulfills security experts demands, and which can
>>> easily be adapted by an average GnuPG user, regardless of platform 
>>> and client he/she uses?
>> No.  More to the point, there can't be.  Each user faces threats
>> specific to that user; each user is responsible for their own threat
>> modeling.
>>
>> But follow the steps I outlined before and you'll significantly improve
>> your online security.  You won't be perfect -- there is no such thing as
>> perfection.  You won't be a hardened target -- that takes a lot of work.
>>  But follow those steps and you'll have taken care of the easy ways that
>> your machine can be compromised.
>>
> 
> Thank you very much for your advise, much appreciated!
> 
> Regards
> Stefan
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
I'm not one of the many experts on the list you refer to so you'll have
to judge for yourself the usefulness of my procedures.  Comments from
more experienced users welcome as well, of course, and some very
experienced users have given you very good advice already.

Some of things I do include setting a password on the BIOS and HD and
turning my computer off when I'm not using it.  My reason for those
steps is that I am hoping it would introduce enough of a roadblock that
should someone gain physical access to my computer (a laptop) they would
need to take it with them in order to compromise it.

I also don't click on any links in emails. As well, I don't open any PDF
files I don't trust.

I believe also that it's important to consider what operating system you
use.  Some people believe that with certain OSs you are compromised the
minute you install said OS and are actually fulfilling the role of
Mallory against yourself.  This is to say that I believe Open Source is
beneficial not that it is the complete solution.

I would also add one word about USB sticks:  It is very difficult to
know if they've been compromised and there are no tell-tale signs when
an attack is taking place.  I never put a USB in my computer that has
been used on a computer I don't own.
Best Regards,
Duane

-- 
Duane Whitty
duane at nofroth.com

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

From stefan.claas at posteo.de  Tue Jun 13 09:43:51 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 13 Jun 2017 09:43:51 +0200
Subject: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc.
 - Identicons
In-Reply-To: <ccd59e47-ce7f-9f1b-5ac8-c1329a4d0ec5@nofroth.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
 <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
 <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>
 <ccd59e47-ce7f-9f1b-5ac8-c1329a4d0ec5@nofroth.com>
Message-ID: <a753e14e-24cb-dd72-86aa-9c1031232e4a@posteo.de>

Am 12.06.2017 um 23:50 schrieb Duane Whitty:

Thanks for your input much appreciated!

> I would also add one word about USB sticks:  It is very difficult to
> know if they've been compromised and there are no tell-tale signs when
> an attack is taking place.  I never put a USB in my computer that has
> been used on a computer I don't own.
> Best Regards,
> Duane
>

Thanks for pointing this out!

I come to the conclusion after reading all the replies from this thread
that i will return to pure GnuPG usage, instead of using an email / Usenet
client with add-ons. I already found a script for PGP/MIME so that i can
decrypt/verify a message send to me when using GnuPG in command-line
mode.

Another thing i will do in the future, which i haven't read in popular 
tutorials,
is that once checking the hash/sig of the provided package i will also hash
the binaries after unpacking and print them out on a piece of paper, so 
that i
can frequently check the values.

Regards
Stefan








From chris at hor.rocks  Tue Jun 13 09:55:01 2017
From: chris at hor.rocks (Chris Horrocks)
Date: Tue, 13 Jun 2017 03:55:01 -0400
Subject: Key expiration question
Message-ID: <wJSA_AqTA9t74bMVquBBMPn88klEoaBQMnOrOct-8nnY0lbRu5Vr0URFNHrE_ne6AfPNR9AEJ2dQWPHddWXmQYWeGwNqmfA7D15YehezgFg=@hor.rocks>

Hi,

I have a question around key expiry that I can't seem to find any thorough documentation on; & the @Gnupg twitter account pointed me here.

What purpose does key expiration have?

At first I thought it may be a mechanism for revalidating private key ownership but key expiration doesnt appear to impact on trust or validity. So I thought it may be a mechanism for time constraining key use but there doesnt appear to be anything in the RFC to mandate the handling (or not as the case may/should be) of expired keys.

Have I completely misunderstood?

Regards

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170613/8ad013da/attachment.html>

From wk at gnupg.org  Tue Jun 13 11:58:51 2017
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jun 2017 11:58:51 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170612181257.GA2545@c720-r314251> (Matthias Apitz's message of
 "Mon, 12 Jun 2017 20:12:57 +0200")
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
 <20170612181257.GA2545@c720-r314251>
Message-ID: <87vao0fbtw.fsf@wheatstone.g10code.de>

On Mon, 12 Jun 2017 20:12, guru at unixarea.de said:

> create some backup of the secret key into a file. It is totally unclear
> to me how to make something usefull out of this file, for example import
> it into a "normal" secret keyring to use it in case of the GnuPG acrd

To try it you best insert a new or scratch card.  Make sure your
_public key_ exists.  Then run

  gpg --edit-key YOURKEY

and at the prompt enter

  bkuptocard FILENAME

the FILENAME is the sk_foo file.  You will then be asked where to store
the key on the card (Signing, encryption, or authentication key).


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/20170613/da90d7e5/attachment.sig>

From guru at unixarea.de  Tue Jun 13 12:20:25 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 13 Jun 2017 12:20:25 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <89039175-b871-edc8-4dbf-0d589f09e6dc@intra2net.com>
References: <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
 <20170612181257.GA2545@c720-r314251>
 <89039175-b871-edc8-4dbf-0d589f09e6dc@intra2net.com>
Message-ID: <20170613102025.GA4228@c720-r314251>

El d?a martes, junio 13, 2017 a las 11:52:46a. m. +0200, Thomas Jarosch escribi?:

> > Please note: I have changed the Subject: of the thread to match better
> > the real problem. 
> > 
> > During generating the keys on the GnuPG card, one can (and should)
> > create some backup of the secret key into a file. It is totally unclear
> > to me how to make something usefull out of this file, for example import
> > it into a "normal" secret keyring to use it in case of the GnuPG acrd
> > gots lost.
> 
> AFAIK the "backup process" during key creation for the OpenPGP smartcard
> is a bit different: There is no interface / function on the card to
> export a key. Therefore, if you decide to create a backup, a key is
> first created on the host and *then* transferred onto the card.
> At least that's my understanding of it.

Hi Thomas,

Thanks for your posting, but now I'm really confused. The howto about
the card in https://gnupg.org/howtos/card-howto/en/smartcard-howto-single.html
says:

...
3.3.2. Generating keys

To generate a key on the card enter generate. You will be asked if you would like to make an off-card copy of the encryption key. It is useful to say yes here.
Note

Without a backup you will not be able to access any data you encrypted
with the card if it gets lost or damaged.
...


and as well in the dialog of the key creation on the card it said:

...
Please enter a new passphrase to export it.
Frase contrase?a: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Repeat:
gpg: Note: backup of card key saved to '/home/guru/.gnupg/sk_61F1ECB625C9A6C3.gpg'
gpg: /home/guru/.gnupg/trustdb.gpg: trustdb created
gpg: key 47CCF7E476FE9D11 marked as ultimately trusted
gpg: directory '/home/guru/.gnupg/openpgp-revocs.d' created
gnupg-card.txtgpg: revocation certificate stored as '/home/guru/.gnupg/openpgp-revocs.d/5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11.rev'
public and secret key created and signed.

gpg/card> quit
...



> 
> When we developed the paper backup tool
> (https://github.com/intra2net/paperbackup/blob/master/README.md)
> we created several keys on the host machine, transferred the key
> to the card and created a backup on paper.
> 

I will have a look into the paper backup tool; sounds handy.

Thx

	matthias



-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170613/e4971d92/attachment.sig>

From guru at unixarea.de  Tue Jun 13 12:51:01 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 13 Jun 2017 12:51:01 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <87vao0fbtw.fsf@wheatstone.g10code.de>
References: <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
 <20170612181257.GA2545@c720-r314251>
 <87vao0fbtw.fsf@wheatstone.g10code.de>
Message-ID: <20170613105101.GA4670@c720-r314251>

El d?a martes, junio 13, 2017 a las 11:58:51a. m. +0200, Werner Koch escribi?:

> On Mon, 12 Jun 2017 20:12, guru at unixarea.de said:
> 
> > create some backup of the secret key into a file. It is totally unclear
> > to me how to make something usefull out of this file, for example import
> > it into a "normal" secret keyring to use it in case of the GnuPG acrd
> 
> To try it you best insert a new or scratch card.  Make sure your
> _public key_ exists.  Then run
> 
>   gpg --edit-key YOURKEY
> 
> and at the prompt enter
> 
>   bkuptocard FILENAME
> 
> the FILENAME is the sk_foo file.  You will then be asked where to store
> the key on the card (Signing, encryption, or authentication key).
> 

I tried (~/.gnupg-test is a copy of my normal GNUPGHOME):

$ cd .gnupg-test/
$ GNUPGHOME=`pwd`
$ env | grep GNU
GNUPGHOME=/home/guru/.gnupg-test

$ ls -l sk_61F1ECB625C9A6C3.gpg
-r--------  1 guru  wheel  1865 May 14 20:29 sk_61F1ECB625C9A6C3.gpg

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

gpg: key "sk_61F1ECB625C9A6C3.gpg" not found: No public key

$ gpg2 --import ../GnuPG/ccid--export-key-guru.pub
gpg: key 47CCF7E476FE9D11: "Matthias Apitz (GnuPG CCID) <guru at unixarea.de>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

The file "ccid--export-key-guru.pub" was created from the card with:

$ gpg2 --export --armor > ccid--export-key-guru.pub

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170613/dd89902e/attachment.sig>

From thomas.jarosch at intra2net.com  Tue Jun 13 11:52:46 2017
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Tue, 13 Jun 2017 11:52:46 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170612181257.GA2545@c720-r314251>
References: <20170611180712.GA2572@c720-r314251>
 <87a85ejr1t.fsf@wheatstone.g10code.de> <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251> <20170612181257.GA2545@c720-r314251>
Message-ID: <89039175-b871-edc8-4dbf-0d589f09e6dc@intra2net.com>

Hi Matthias,

Am 12.06.2017 um 20:12 schrieb Matthias Apitz:
> 
> Please note: I have changed the Subject: of the thread to match better
> the real problem. 
> 
> During generating the keys on the GnuPG card, one can (and should)
> create some backup of the secret key into a file. It is totally unclear
> to me how to make something usefull out of this file, for example import
> it into a "normal" secret keyring to use it in case of the GnuPG acrd
> gots lost.

AFAIK the "backup process" during key creation for the OpenPGP smartcard
is a bit different: There is no interface / function on the card to
export a key. Therefore, if you decide to create a backup, a key is
first created on the host and *then* transferred onto the card.
At least that's my understanding of it.

When we developed the paper backup tool
(https://github.com/intra2net/paperbackup/blob/master/README.md)
we created several keys on the host machine, transferred the key
to the card and created a backup on paper.

During this process we also tested the restore of a card,
it worked just fine. Basically you re-import a private key from file
and tell gpg2 to move it to the card with the --edit-key command.

btw: If you create the keys on a preferable air gaped machine,
there's the "scdrand" tool to feed the kernel random pool with random
numbers generated by the hardware RNG from the OpenGPG card.
We used this script:

------------------------------
#!/bin/bash
set -u

if [ "$(whoami)" != "root" ]; then
    echo "Must be root (only root can add entropy to the kernel)"
    exit 1
fi

echo "Activating scdaemon"
gpg2 --card-status

current_bytes=$(( $(cat "/proc/sys/kernel/random/entropy_avail") / 8))
echo "Emptying existing kernel random pool ($current_bytes)"
dd if=/dev/random of=/dev/null bs=1 count="$current_bytes"

echo "Starting scdrand with:"
echo "    - sleep time 2s"
echo "    - continuously add 128 random bytes from smartcard"

./scdrand.f25 -l -i 2 128 &

sleep 3
watch -n 1 cat "/proc/sys/kernel/random/entropy_avail"
------------------------------


Cheers,
Thomas

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

From thomas.jarosch at intra2net.com  Tue Jun 13 12:45:57 2017
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Tue, 13 Jun 2017 12:45:57 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170613102025.GA4228@c720-r314251>
References: <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251> <20170612181257.GA2545@c720-r314251>
 <89039175-b871-edc8-4dbf-0d589f09e6dc@intra2net.com>
 <20170613102025.GA4228@c720-r314251>
Message-ID: <c144d40c-d890-32b5-6826-53ed993f1480@intra2net.com>

Am 13.06.2017 um 12:20 schrieb Matthias Apitz:
>> AFAIK the "backup process" during key creation for the OpenPGP smartcard
>> is a bit different: There is no interface / function on the card to
>> export a key. Therefore, if you decide to create a backup, a key is
>> first created on the host and *then* transferred onto the card.
>> At least that's my understanding of it.
> 
> Thanks for your posting, but now I'm really confused. The howto about
> the card in https://gnupg.org/howtos/card-howto/en/smartcard-howto-single.html
> says:
> 
> ...
> 3.3.2. Generating keys
> 
> To generate a key on the card enter generate. You will be asked if you would like to make an off-card copy of the encryption key. It is useful to say yes here.
> Note
> 
> Without a backup you will not be able to access any data you encrypted
> with the card if it gets lost or damaged.
> ...
just checked the source code: If you want a backup of the key,
the "want_backup" variable is set. This later on translates
to the "card_backup_key" variable.

---keygen.c---
/*
 * Generate a keypair (fname is only used in batch mode) If
 * CARD_SERIALNO is not NULL the function will create the keys on an
 * OpenPGP Card.  If CARD_BACKUP_KEY has been set and CARD_SERIALNO is
 * NOT NULL, the encryption key for the card is generated on the host,
 * imported to the card and a backup file created by gpg-agent.  If
 * FULL is not set only the basic prompts are used (except for batch
 * mode).
 */
void
generate_keypair (ctrl_t ctrl, int full, const char *fname,
                  const char *card_serialno, int card_backup_key)
---keygen.c---


-> so yes, if you want a backup, the key is created on the host.
Security wise it would be bad if the card has a function to extract
a key from it and there's a bug that could somehow trigger this function.

Also it does not make a big difference if the key is created
on the host or on the card if it ends up on the host anyway :)

May be the documentation needs to clarify the situation a bit.

Cheers,
Thomas

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

From tlikonen at iki.fi  Tue Jun 13 13:30:05 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Tue, 13 Jun 2017 14:30:05 +0300
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170613105101.GA4670@c720-r314251> (Matthias Apitz's message of
 "Tue, 13 Jun 2017 12:51:01 +0200")
References: <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
 <20170612181257.GA2545@c720-r314251>
 <87vao0fbtw.fsf@wheatstone.g10code.de>
 <20170613105101.GA4670@c720-r314251>
Message-ID: <87poe8nn0i.fsf@mithlond.arda>

Matthias Apitz [2017-06-13 12:51:01+02] wrote:

> $ gpg2 --edit-key sk_61F1ECB625C9A6C3.gpg

Command --edit-key edits a key in your keyring. I'd guess that you want
to import keys:

    gpg2 --import sk_61F1ECB625C9A6C3.gpg

Then you can edit them with --edit-key.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170613/4f7985d8/attachment.sig>

From guru at unixarea.de  Tue Jun 13 13:35:52 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 13 Jun 2017 13:35:52 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <87poe8nn0i.fsf@mithlond.arda>
References: <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251>
 <20170612181257.GA2545@c720-r314251>
 <87vao0fbtw.fsf@wheatstone.g10code.de>
 <20170613105101.GA4670@c720-r314251> <87poe8nn0i.fsf@mithlond.arda>
Message-ID: <20170613113552.GA5132@c720-r314251>

El d?a martes, junio 13, 2017 a las 02:30:05p. m. +0300, Teemu Likonen escribi?:

> Matthias Apitz [2017-06-13 12:51:01+02] wrote:
> 
> > $ gpg2 --edit-key sk_61F1ECB625C9A6C3.gpg
> 
> Command --edit-key edits a key in your keyring. I'd guess that you want

I did 1:1 what Werner suggested;

> to import keys:
> 
>     gpg2 --import sk_61F1ECB625C9A6C3.gpg

This is not working as I said yesterday:

$ gpg2 --import sk_61F1ECB625C9A6C3.gpg
gpg: key 61F1ECB625C9A6C3: no user ID
gpg: Total number processed: 1
gpg:       secret keys read: 1

Btw: the publickey is there:

gpg2 --list-keys
/home/guru/.gnupg-test/pubring.kbx
----------------------------------
pub   rsa4096 2017-05-14 [SC]
      5E69FBAC1618562CB3CBFBC147CCF7E476FE9D11
uid           [ultimate] Matthias Apitz (GnuPG CCID) <guru at unixarea.de>
sub   rsa4096 2017-05-14 [A]
sub   rsa4096 2017-05-14 [E]
...

-- 
Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/  ? +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170613/7c4ce1e1/attachment.sig>

From peter at digitalbrains.com  Tue Jun 13 14:16:46 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 13 Jun 2017 14:16:46 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <a753e14e-24cb-dd72-86aa-9c1031232e4a@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
 <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
 <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>
 <ccd59e47-ce7f-9f1b-5ac8-c1329a4d0ec5@nofroth.com>
 <a753e14e-24cb-dd72-86aa-9c1031232e4a@posteo.de>
Message-ID: <7d6ad2b8-9f2b-ed99-3fbb-e3c2188e6d49@digitalbrains.com>

On 13/06/17 09:43, Stefan Claas wrote:
> Another thing i will do in the future, which i haven't read in popular
> tutorials,
> is that once checking the hash/sig of the provided package i will also hash
> the binaries after unpacking and print them out on a piece of paper, so
> that i
> can frequently check the values.

I use Open Source Tripwire for that. Its specification language is quite
lacking in my opinion, but it's not so bad that I start looking around
for a different solution. I've been using it for ages, and haven't
noticed any significant development on it since I started using it. As
far as I remember.

Note that someone in a position to replace your binaries is also in a
position to replace the sha256sum binary or whatever other binary you
are using to generate the hashes, so your hashes can just lie to you. As
can Tripwire.

And so I come to my other comment, in reply to:

>  So what i have learned from this whole
> thread, also about my proposal for identicons, i should buy me
> an offline computer, send Thunderbird/Enigmail to /dev/null
> and transfer signed/encrypted messages from my online usage
> computer with a USB stick to my offline computer and verify
> decrypt the messages there. :-)

Security is not an absolute. Quite the opposite: security is rather
simple economics. How much are you willing to spend on your protection,
and how much is an attacker willing to spend to compromise you? It's
that simple. There are some unpleasant little factors such as that you
need to do it right all the time, yet the attacker only needs to do it
right once. But in the end, it all boils down to: who is willing to go
that step further? As long as your secrets aren't very valuable, an
attacker will not want to spend a lot on obtaining those secrets; they'd
rather point their attention and money elsewhere.

So Tripwire is something that raises the cost of the attack; it's
defence in depth, not an absolute defence. And as the name suggests, if
the attacker doesn't notice Tripwire, they might well set off an alarm.
But if they notice it.... <snip>.

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/20170613/4a7f3df7/attachment.sig>

From peter at digitalbrains.com  Tue Jun 13 14:46:17 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 13 Jun 2017 14:46:17 +0200
Subject: GnuPG card && using the backup secret key
In-Reply-To: <20170613105101.GA4670@c720-r314251>
References: <87a85ejr1t.fsf@wheatstone.g10code.de>
 <20170611190554.GA3515@c720-r314251>
 <cd324292-9c16-64d7-a1d3-2757000f79f9@digitalbrains.com>
 <20170611194847.GA4155@c720-r314251>
 <3cd473e3-b781-31da-4f39-f020d8983bee@digitalbrains.com>
 <20170612053158.GA2502@c720-r314251>
 <0380e293-659d-8d5d-797c-29bb39453585@incenp.org>
 <20170612121501.GB5010@c720-r314251> <20170612181257.GA2545@c720-r314251>
 <87vao0fbtw.fsf@wheatstone.g10code.de> <20170613105101.GA4670@c720-r314251>
Message-ID: <96916804-d7e1-e502-2713-7c17ed9d7dc4@digitalbrains.com>

On 13/06/17 12:51, Matthias Apitz wrote:
> $ gpg2 --edit-key sk_61F1ECB625C9A6C3.gpg

Unfortunately you got lost in the advice from multiple people :-).

This file sk_... is not a public key. It is just the backup of the
material that is in one of the slots of the card.

When Werner said "make sure your public key exists", he meant you should
perhaps import the file created with:

> $ gpg2 --export --armor > ccid--export-key-guru.pub

So:

Let's not use a temporary homedir. There have been some changes lately
regarding locating the agent and scdaemon with a changed homedir. I
don't know off the top of my head what the currect situation is. GnuPG
getting confused about its homedir is a great way to make you confused
as well.

However, *backup your homedir*. If all goes awry, you can restore from
backup.

And do you have a spare OpenPGP card? Don't use your OpenPGP card with
the keys on it! Or else you'll get "I tried to be prudent and test my
backup, my backup wasn't good and it trashed my card. I now need a
backup to restore my card. Hmmmm."

Since you are using your normal GnuPG installation to do this operation,
the public key is already available! If you do start from scratch, first do:

$ gpg2 --import ccid--export-key-guru.pub

Then do:

$ gpg2 --edit-key 47CCF7E476FE9D11

You don't specify a filename to --edit-key, you specify a key in your
keyring. In your original post, one can see that you could have also done:

$ gpg2 --edit-key Matthias

but this would fail as soon as you import another Matthias's key or you
generate a second key for yourself, since GnuPG wouldn't know which key
you meant.

And then at the prompt enter:

gpg> bkuptocard sk_61F1ECB625C9A6C3.gpg

*But do this to a scratch card*! Direct GnuPG to put it in the
Encryption slot.

Now that card holds another copy of your key. What I don't know is
whether this will also tell GnuPG to look for this key on the new card
from now on. Actually, that would be a good way to really test the
backup, but that shouldn't be necessary. If it is the case and GnuPG
asks for that new card any time you want to decrypt, proceed as follows:

- Determine the keygrip of your encryption key.

$ gpg2 --with-keygrip -k 47CCF7E476FE9D11

For me, the output is as follows:

> pub   rsa2048 2009-11-12 [C] [expires: 2017-10-19]
>       8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E
>       Keygrip = 13790148EEE34BC5140DD31B6F95EABA8A19E419
> uid           [ultimate] Peter Lebbing <peter at digitalbrains.com>
> sub   rsa2048 2009-11-12 [S] [expires: 2017-10-19]
>       Keygrip = 46E61BB13BF429980D89B6B7BDE0F70E55E41A03
> sub   rsa2048 2009-11-12 [E] [expires: 2017-10-19]
>       Keygrip = A9C7C73653BEDAF478E4956FCF4C3AFC7CB9A00C
> sub   rsa2048 2009-12-05 [A] [expires: 2017-10-19]
>       Keygrip = 2DD5CC89FE601845C8C4F74F9643724A08D878FD

My encryption subkey has the keygrip
A9C7C73653BEDAF478E4956FCF4C3AFC7CB9A00C.

- Delete the smartcard key stub:

$ rm ~/.gnupg/private-keys-v1.d/<keygrip>.key

- Insert your regular smartcard, the one which also holds the SC and A key.

- Execute:

$ gpg2 --card-status

Now GnuPG will once again pick up the E key on your regular card.

Finally, if you want to remove the restored backup from the new/scratch
OpenPGP card, do (with that scratch card in the reader):

$ gpg2 --card-edit
gpg/card> admin
gpg/card> factory-reset

That should be it.

At some point earlier you deleted a file from
~/.gnupg/private-keys-v1.d/. If you deleted the wrong one, you'll be
very glad you made that backup of the directory. Restore from backup.
Since the backup was made before you started fiddling with stuff, if you
restore the whole .gnupg directory, it will automagically restore the
correct situation you started out with, and it will ask for your regular
card, not the new one.

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/20170613/78b5a90c/attachment.sig>

From peter at digitalbrains.com  Tue Jun 13 15:02:35 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Tue, 13 Jun 2017 15:02:35 +0200
Subject: Key expiration question
In-Reply-To: <wJSA_AqTA9t74bMVquBBMPn88klEoaBQMnOrOct-8nnY0lbRu5Vr0URFNHrE_ne6AfPNR9AEJ2dQWPHddWXmQYWeGwNqmfA7D15YehezgFg=@hor.rocks>
References: <wJSA_AqTA9t74bMVquBBMPn88klEoaBQMnOrOct-8nnY0lbRu5Vr0URFNHrE_ne6AfPNR9AEJ2dQWPHddWXmQYWeGwNqmfA7D15YehezgFg=@hor.rocks>
Message-ID: <2d98d78f-bc75-f673-1e78-f97be8abcfed@digitalbrains.com>

On 13/06/17 09:55, Chris Horrocks wrote:
> At first I thought it may be a mechanism for revalidating private
> key ownership but key expiration doesnt appear to impact on trust or
> validity.

An expired key will definitely not be able to issue valid signatures
after the expiration date. So any certifications made after the expiry
will definitely not influence the validity of another key either, either
positively or negatively.

I don't know how certifications made before the expiry are handled. So,
I don't know whether some other keys either lose their validity after
the expiry or they keep their validity.

So I disagree that expiry doesn't impact trust and validity.

> So I thought it may be a mechanism for time constraining key
> use but there doesnt appear to be anything in the RFC to mandate the
> handling (or not as the case may/should be) of expired keys.

Not everything that is needed for a sane implementation is in the RFC.

Expiring your key will certainly force your correspondents to see if
there is anything new about it if they still want to verify your
signatures or encrypt messages to you (you can't encrypt to an expired key).

You ask what the purpose is of key expiry, but I think it has multiple
possible purposes. I'd phrase it as "what is the mechanism of key
expiry" and then decide whether that mechanism fits the purpose you have
in mind or not. Supposing that you do have a purpose in mind.

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/20170613/1abfff6f/attachment.sig>

From stefan.claas at posteo.de  Tue Jun 13 15:33:57 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Tue, 13 Jun 2017 15:33:57 +0200
Subject: Question for app developers, like Enigmail etc. - Identicons
In-Reply-To: <7d6ad2b8-9f2b-ed99-3fbb-e3c2188e6d49@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <611ef514-d2bb-7f8a-d449-f814892755db@srcf.net>
 <4279c081-852b-a7b6-89a5-ab4876536b42@posteo.de>
 <375302a9-c94e-08a6-a8d5-b87a32eebde2@enigmail.net>
 <c194ab79-382f-4d4e-b785-1db5ad115dae@posteo.de>
 <7a4d725e-ff1d-980f-08ae-17ef7f351b3a@enigmail.net>
 <cdfd62f3-4ca6-fc20-dc85-f43e11ce0e08@posteo.de>
 <f2829890-9f7b-87c2-2f42-eac15b53b9e3@digitalbrains.com>
 <69a0ebde-fc5a-0afb-b3a2-9b0872f4c2f3@posteo.de>
 <f8d24d89-7f56-96ea-1f0a-46878ad563d7@sixdemonbag.org>
 <43d02bad-6fbc-ffd8-26f1-29eeca205629@posteo.de>
 <a17952a0-7ace-5667-d246-b06e858f45f0@sixdemonbag.org>
 <a39489d8-5721-b9d4-e6c9-db702ef0767a@posteo.de>
 <ccd59e47-ce7f-9f1b-5ac8-c1329a4d0ec5@nofroth.com>
 <a753e14e-24cb-dd72-86aa-9c1031232e4a@posteo.de>
 <7d6ad2b8-9f2b-ed99-3fbb-e3c2188e6d49@digitalbrains.com>
Message-ID: <11f915d5-ef39-9f4b-0234-19c1ad322d71@posteo.de>

On 13.06.17 14:16, Peter Lebbing wrote:
> On 13/06/17 09:43, Stefan Claas wrote:
>> Another thing i will do in the future, which i haven't read in popular
>> tutorials,
>> is that once checking the hash/sig of the provided package i will also hash
>> the binaries after unpacking and print them out on a piece of paper, so
>> that i
>> can frequently check the values.
> I use Open Source Tripwire for that. Its specification language is quite
> lacking in my opinion, but it's not so bad that I start looking around
> for a different solution. I've been using it for ages, and haven't
> noticed any significant development on it since I started using it. As
> far as I remember.
>
> Note that someone in a position to replace your binaries is also in a
> position to replace the sha256sum binary or whatever other binary you
> are using to generate the hashes, so your hashes can just lie to you. As
> can Tripwire.

During my lunch break i thought of that too. I think as a good start
i will next time (which popular tutorials also do not mention) install
the next version available on an USB stick, symlink to them and put
the USB stick in a safe place. Should an email arrive i will then insert
the USB stick to decrypt/verify the message.

Regarding hashes, maybe it's possible for the authors who are
providing packages that they not only include the hash or sig,
of the package but the hashes of the unpacked binaries too,
on their download page. Should one hash discrepancy show
up on my computer i could try another one and see if the hash
matches then.
>
> And so I come to my other comment, in reply to:
>
>>  So what i have learned from this whole
>> thread, also about my proposal for identicons, i should buy me
>> an offline computer, send Thunderbird/Enigmail to /dev/null
>> and transfer signed/encrypted messages from my online usage
>> computer with a USB stick to my offline computer and verify
>> decrypt the messages there. :-)
> Security is not an absolute. Quite the opposite: security is rather
> simple economics. How much are you willing to spend on your protection,
> and how much is an attacker willing to spend to compromise you? It's
> that simple. There are some unpleasant little factors such as that you
> need to do it right all the time, yet the attacker only needs to do it
> right once. But in the end, it all boils down to: who is willing to go
> that step further? As long as your secrets aren't very valuable, an
> attacker will not want to spend a lot on obtaining those secrets; they'd
> rather point their attention and money elsewhere.
>
> So Tripwire is something that raises the cost of the attack; it's
> defence in depth, not an absolute defence. And as the name suggests, if
> the attacker doesn't notice Tripwire, they might well set off an alarm.
> But if they notice it.... <snip>.
>
>
For me i see this way, for big Organizations i would not have a single
chance, but i assume that i am no target for them, because i am of no
interest to them.

On the other side, where money is involved etc. and people are good
in keeping their computers clean, and they rely on popular tutorials,
the "green bar problem" would still be there, imho.

Regards
Stefan






From lee.yanzhe at yanzhe.org  Wed Jun 14 07:38:50 2017
From: lee.yanzhe at yanzhe.org (Yanzhe Lee)
Date: Wed, 14 Jun 2017 05:38:50 +0000
Subject: Cannot choose specific signing key with option --default-key
Message-ID: <CAMWwZzijoOFsN2Ledt2+h4LVxb3QcSE3cmU2SbcXXpNJBr5VaA@mail.gmail.com>

GPG Version: gpg (GnuPG) 2.1.21 libgcrypt 1.7.6
Operate System: macOS sierra 10.12.5

I have these keys with private key

pub brainpoolP512r1/3EA647C79FDA9CD1
created: 2017-01-08 expires: 2032-01-05 usage: SCA
trust: ultimate validity: ultimate

ssb brainpoolP512r1/2D8801CE07BCC5B5
created: 2017-01-08 expires: 2032-01-05 usage: S

ssb brainpoolP512r1/C78A6E620F333355
created: 2017-01-08 expires: 2032-01-05 usage: E

ssb nistp521/D97F950D0F500332
created: 2017-02-04 expires: 2027-02-02 usage: A

ssb rsa4096/5BE7F1861B56E399
created: 2017-02-09 expires: 2025-02-07 usage: S
card-no: 0006 04175643

ssb rsa4096/9149FF3E60054D0C
created: 2017-02-09 expires: 2025-02-07 usage: E
card-no: 0006 04175643

ssb rsa4096/8C31540043B61A0A
created: 2017-02-09 expires: 2025-02-07 usage: A
card-no: 0006 04175643

[ultimate] (1). TEST (Local) <test at test.org>
[ultimate] (2) TEST (Online) <admin at test.org>

RSA private keys are stored in a yubikey smart card
ECC private keys are stored in keyring.

When I use the command to specify using ECC key 2D8801CE07BCC5B to sign a
file

gpg2 -v -u 2D8801CE07BCC5B5 -a -s test.jpg

It prompt me to insert my smart card. After I insert it and input my pin,
it outputs:

gpg: using subkey 5BE7F1861B56E399 instead of primary key 3EA647C79FDA9CD1
gpg: writing to 'test.jpg.asc'
gpg: RSA/SHA512 signature from: "5BE7F1861B56E399 TEST <test at test.org>"

So when I verify the signature file, it was signed by my RSA key which was
not what I specified.
It was supposed not to prompt me to insert my smart card because the
private key of my ECC key was not in the card.
The key 2D8801CE07BCC5B5 was not my primary key, so gpg shouldn't change
the signature key with a subkey.

I tried other options as follows, and the result was same.
gpg2 -v --default-key 2D8801CE07BCC5B5 -a -s test.jpg
gpg2 -v --local-user 2D8801CE07BCC5B5 -a -s test.jpg

However, if I delete the RSA subkey, it will sign my file with correct ECC
key.

Maybe there was a priority when sign files with RSA and ECC keys? How can I
override it?


-- 

Best regards!

LI YANZHE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170614/543f5713/attachment.html>

From kristian.fiskerstrand at sumptuouscapital.com  Wed Jun 14 13:15:28 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 14 Jun 2017 13:15:28 +0200
Subject: Cannot choose specific signing key with option --default-key
In-Reply-To: <CAMWwZzijoOFsN2Ledt2+h4LVxb3QcSE3cmU2SbcXXpNJBr5VaA@mail.gmail.com>
References: <CAMWwZzijoOFsN2Ledt2+h4LVxb3QcSE3cmU2SbcXXpNJBr5VaA@mail.gmail.com>
Message-ID: <1f66b7ca-714e-296d-448b-d37724ec95e7@sumptuouscapital.com>

On 06/14/2017 07:38 AM, Yanzhe Lee wrote:
> Maybe there was a priority when sign files with RSA and ECC keys? How
> can I override it?

Try adding a "!" suffix to the fingerprint specification of the subkey

-- 
----------------------------
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
----------------------------
"Be a yardstick of quality. Some people aren't used to an environment
where excellence is expected."
(Steve Jobs)

-------------- 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/20170614/0e33d48c/attachment.sig>

From lists at binarus.de  Wed Jun 14 16:04:40 2017
From: lists at binarus.de (Binarus)
Date: Wed, 14 Jun 2017 16:04:40 +0200
Subject: How to join pubring.kbx and pubring.gpg?
Message-ID: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>

Dear experts,

I am running Thunderbird, Enigmail and gpg4win on Windows 7. All
components are up to date, and I am using this combination successfully
since several years for signing, encrypting and decrypting email messages.

Now, for the first time, a new communication partner won't provide his
public GPG key directly, but only in form of a .p7b certificate. Since
several hours, I am having a remarkably hard time trying to import his
public key into the setup mentioned above.

1) gpgsm seems to be the only tool which can be used to extract public
keys or convert certificates from the .p7b format to the format needed
by GPG. Fortunately, gpgsm is included in the gpg4win package, so I
could use it on my system.

2) But whatever I did, I could not see the new public keys in the key
list gpg shows. So I tracked the issue further down and noticed:

gpg -k correctly lists the keys I have currently in use, but not the
new, imported key.

gpgsm -k correctly lists the new key, but not the keys I have currently
in use.

3) Further research lead me to this post:

https://lists.gnupg.org/pipermail/gnupg-users/2015-December/054881.html

This at least gave me a vague idea about what might be going on.
Obviously, gpgsm had imported the new key into pubring.kbx, but not into
pubring.gpg (note: This seems to be expected behavior as I have found
out in the meantime).

So I closed Thunderbird and deleted pubring.gpg for testing purposes.
According to the post mentioned above, GPG then should have used
pubring.kbx instead of pubring.gpg, so I expected to see the new,
imported key when issuing gpg -k.

But instead, gpg -k generated a new (empty) pubring.gpg instead of using
pubring.kbx.

4) I have found no way to make GPG use pubring.kbx although I have
double checked that I am using the most recent version of gpg4win,
meaning that I am using gpg2. I also have double checked the
installation directory; there is no gpg.exe, but there is gpg2.exe (and
gpgv2.exe, whatever that might be). So it should use pubring.kbx,
shouldn't it?

5) I have found no way to convert pubring.kbx to pubring.gpg, or to join
them.

To summarize: I have a .pb7 certificate with a public PGP key. I can
import it to pubring.kbx. I can't import it to pubring.gpg. I can't use
it because gpg4win uses pubring.gpg. I can't convert pubring.kbx to
pubring.gpg. I can't join pubring.kbx with pubring.gpg.

Does anybody have an idea how I could get out of this? I have access to
full-blown Linux systems, so I could perform all conversions or import
steps on Linux if necessary. But I still have to use the end results
under Windows with the setup mentioned at the beginning of this post.

Thank you very much,

Binarus



From juanmi.3000 at gmail.com  Wed Jun 14 19:21:00 2017
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Wed, 14 Jun 2017 19:21:00 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
Message-ID: <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>

On 2017-06-14 at 16:04, Binarus wrote:

> 1) gpgsm seems to be the only tool which can be used to extract public
> keys or convert certificates from the .p7b format to the format needed
> by GPG. Fortunately, gpgsm is included in the gpg4win package, so I
> could use it on my system.
> 
As far as I know, GPGSM is a GPG tool to use X.509 certificates. That's
not the OpenPGP protocol. With this said...

> 2) But whatever I did, I could not see the new public keys in the key
> list gpg shows. So I tracked the issue further down and noticed:
> 
> gpg -k correctly lists the keys I have currently in use, but not the
> new, imported key.
> 
> gpgsm -k correctly lists the new key, but not the keys I have currently
> in use.
> 
... even if your GnuPG installation used .kbx format -which mine does-,
gpg will still show only OpenPGP keys while gpgsm will show x509 keys.

> 3) [...]
> 
> So I closed Thunderbird and deleted pubring.gpg for testing purposes.
> According to the post mentioned above, GPG then should have used
> pubring.kbx instead of pubring.gpg, so I expected to see the new,
> imported key when issuing gpg -k.
> 
> But instead, gpg -k generated a new (empty) pubring.gpg instead of using
> pubring.kbx.
> 
> 4) I have found no way to make GPG use pubring.kbx although I have
> double checked that I am using the most recent version of gpg4win,
> meaning that I am using gpg2. I also have double checked the
> installation directory; there is no gpg.exe, but there is gpg2.exe (and
> gpgv2.exe, whatever that might be). So it should use pubring.kbx,
> shouldn't it?
> 

For GnuPG to use KBX format, you must have the modern branch which is
2.1 and later. For that, you need to use the experimental version of
Gpg4Win:

https://files.gpg4win.org/Beta/current/

It should be very stable both with Kleopatra and gnupg in command line,
but if you find an error or bug please inform to the respective channel.

More info on how and where to report bugs here:
https://www.gpg4win.org/reporting-bugs.html

> 5) I have found no way to convert pubring.kbx to pubring.gpg, or to join
> them.
> 

After you download the experimental version, you must do the follow:

1. The first time you use gpg -K (and maybe gpg -k), GnuPG will
automatically convert the keys in secring.gpg to the new format which is
storing the secret parts in individual files in
%AppData%\gnupg\private-keys-v1.d (if you changed GNUPGHOME then this
may differ and it should be in %GNUPGHOME%\private-keys-v1.d\).
You can then delete your secring.gpg file if the secret keys conversion
has been successful as it won't be used anymore. This is only for
OpenPGP keys as x509 secret keys as far as I know have always used the
private-keys-v1.d folder and pubring.kbx file.

2. As you imported the x509 key and so you have a pubring.kbx, you won't
be able to see the OpenPGP stored in pubring.gpg as it will prefer the
.kbx format over the .gpg. To import those keys, you should be able to
execute gpg --import X:\Path\To\pubring.gpg and it should start
importing the keys to the new format.
Renaming pubring.gpg to publickeys and then using gpg --import
publickeys is also a good idea if you didn't have a pubring.kbx to begin
with.

I must remind you that your partner's key will still be a X.509 key and
so you'll still need to use GPGSM to list, verify messages from and
encrypt message to that key but now both public OpenPGP and X.509 keys
will be stored in pubring.kbx.

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- 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/20170614/14c7a393/attachment.sig>

From ndk.clanbo at gmail.com  Thu Jun 15 14:13:38 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Thu, 15 Jun 2017 14:13:38 +0200
Subject: How to use a PKCS#15 with GnuPG?
Message-ID: <341d82e1-1fba-4a2a-40ae-0bb2ef74b2ce@gmail.com>

Hello all.

I'm trying to use an ePass2003 token (and possibly some Aventra MyID
cards) to have my keys around when I need 'em (especially for
authentication and signing). Both ePass2003 and MyID implement PKCS#15,
so IIUC they should be usable.
Too bad I can't find the needed infos...

I generated some test keys on the token (ssh one is imported, for
another test):
$ pkcs15-tool -D
Using reader with a card: Feitian ePass2003 00 00
PKCS#15 Card [NdK-test]:
	Version        : 0
	Serial number  : 0843420916091101
	Manufacturer ID: EnterSafe
	Last update    : 20170615092227Z
	Flags          : EID compliant

PIN [User PIN]
	Object Flags   : [0x3], private, modifiable
	ID             : 01
	Flags          : [0x32], local, initialized, needs-padding
	Length         : min_len:4, max_len:16, stored_len:16
	Pad char       : 0x00
	Reference      : 1 (0x01)
	Type           : ascii-numeric
	Path           : 3f005015

Private RSA Key [SSH key]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0x4], sign
	Access Flags   : [0xD], sensitive, alwaysSensitive, neverExtract
	ModLength      : 1024
	Key ref        : 0 (0x0)
	Native         : yes
	Path           : 3f0050152900
	Auth ID        : 01
	ID             : f3dcf75d07c02fd15ae7b7a335f84d46eda6049d
	MD:guid        : {323ba8f2-2b93-1900-fa3b-e1b4d2024011}
	  :cmap flags  : 0x0
	  :sign        : 0
	  :key-exchange: 0

Private RSA Key [Signature key]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0xC], sign, signRecover
	Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
	ModLength      : 2048
	Key ref        : 1 (0x1)
	Native         : yes
	Path           : 3f0050152901
	Auth ID        : 01
	ID             : 9e67a012e0e45f3ae9b1398b912bbf2ba1aef2d4
	MD:guid        : {6c1033ed-c1df-5baa-4e87-5be41c0a8b03}
	  :cmap flags  : 0x0
	  :sign        : 0
	  :key-exchange: 0

Private RSA Key [Decryption key]
	Object Flags   : [0x3], private, modifiable
	Usage          : [0x22], decrypt, unwrap
	Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
	ModLength      : 2048
	Key ref        : 2 (0x2)
	Native         : yes
	Path           : 3f0050152902
	Auth ID        : 01
	ID             : 7db41d5b2c07355dd361e0bffd543c0cfc51953b
	MD:guid        : {08884d6f-15a7-1ade-7183-04d4a4e6bc6f}
	  :cmap flags  : 0x0
	  :sign        : 0
	  :key-exchange: 0

Public RSA Key [SSH key]
	Object Flags   : [0x2], modifiable
	Usage          : [0x40], verify
	Access Flags   : [0x0]
	ModLength      : 1024
	Key ref        : 0 (0x0)
	Native         : no
	Path           : 3f0050153000
	ID             : f3dcf75d07c02fd15ae7b7a335f84d46eda6049d

Public RSA Key [Signature key]
	Object Flags   : [0x2], modifiable
	Usage          : [0xC0], verify, verifyRecover
	Access Flags   : [0x0]
	ModLength      : 2048
	Key ref        : 0 (0x0)
	Native         : no
	Path           : 3f0050153001
	ID             : 9e67a012e0e45f3ae9b1398b912bbf2ba1aef2d4

Public RSA Key [Decryption key]
	Object Flags   : [0x2], modifiable
	Usage          : [0x11], encrypt, wrap
	Access Flags   : [0x0]
	ModLength      : 2048
	Key ref        : 0 (0x0)
	Native         : no
	Path           : 3f0050153002
	ID             : 7db41d5b2c07355dd361e0bffd543c0cfc51953b

$ gpg2 --version
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://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: ~/.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

But:
$ gpg2 --card-edit

gpg: OpenPGP card not available: Not supported

gpg/card>

Well, actually it's not completely unexpected, but then I don't
understand why scdaemon is now locking my token, if it doesn't know how
to handle it:
$ pkcs15-tool -D
Using reader with a card: Feitian ePass2003 00 00
Failed to connect to card: Reader in use by another application

What am I missing?

Tks,
 Diego


From stefan.claas at posteo.de  Thu Jun 15 17:24:20 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 15 Jun 2017 17:24:20 +0200
Subject: modern GnuPG verify signatures
Message-ID: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>

Hi all,

when i sign a message and do a gpg --verify it shows "using RSA
key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4", in Terminal under
macOS, with my own key, but when doing the verify again with a
message from someone else it shows the long key-ID, instead of
the full key. Is this a bug?

Regards
Stefan




From peter at digitalbrains.com  Thu Jun 15 17:49:35 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 15 Jun 2017 17:49:35 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
Message-ID: <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>

On 15/06/17 17:24, Stefan Claas wrote:
> when i sign a message and do a gpg --verify it shows "using RSA
> key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4", in Terminal under
> macOS, with my own key, but when doing the verify again with a
> message from someone else it shows the long key-ID, instead of
> the full key.

It's much easier to see what is going on if you simply include the
terminal output in your mail. When using GUI tools, one loses this great
advantage, but if you're working on the terminal, please always include
the output from the program itself rather than merely describing what
happens.

Could you give us an example?

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/20170615/39bffedb/attachment.sig>

From thomas.orgis at uni-hamburg.de  Thu Jun 15 18:19:20 2017
From: thomas.orgis at uni-hamburg.de (Dr. Thomas Orgis)
Date: Thu, 15 Jun 2017 18:19:20 +0200
Subject: Behaviour of gpgsm / gpgme with multiple S/MIME
 certificates/keys per address (old/expired/about to expire and new)
In-Reply-To: <20170609141725.0960338e@cortex.rrz.uni-hamburg.de>
References: <20170609141725.0960338e@cortex.rrz.uni-hamburg.de>
Message-ID: <20170615181920.65ba33de@cortex.rrz.uni-hamburg.de>

Am Fri, 9 Jun 2017 14:17:24 +0200
schrieb "Dr. Thomas Orgis" <thomas.orgis at uni-hamburg.de>:

> But after that, claws-mail as well as gpgsm complain about
> the keys being ambiguous. Clearly, the call  

No takers? I am the only one getting a fresh S/MIME cert? I now
modified claws-mail to add preferences to each mail account for
separate PGP and S/MIME key choise and set the correct keys there.

I still wonder if that is the right approach or if there is a way to
convince gpgme to decide about the best key to use (clearly where all
others are expired).


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
Universit?t Hamburg
RRZ / Basis-Infrastruktur / HPC
Schl?terstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4967 bytes
Desc: not available
URL: </pipermail/attachments/20170615/49e711b4/attachment.bin>

From stefan.claas at posteo.de  Thu Jun 15 18:59:41 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 15 Jun 2017 18:59:41 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
Message-ID: <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>

Am 15.06.17 um 17:49 schrieb Peter Lebbing:
> On 15/06/17 17:24, Stefan Claas wrote:
>> when i sign a message and do a gpg --verify it shows "using RSA
>> key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4", in Terminal under
>> macOS, with my own key, but when doing the verify again with a
>> message from someone else it shows the long key-ID, instead of
>> the full key.
>
> It's much easier to see what is going on if you simply include the
> terminal output in your mail. When using GUI tools, one loses this great
> advantage, but if you're working on the terminal, please always include
> the output from the program itself rather than merely describing what
> happens.
>
> Could you give us an example?

Apollogies! Here's an example:

I clearsign a text file and verify it and modern GnuPG shows me this:

gpg --verify my_message.txt
gpg: Signature made Do 15 Jun 18:31:05 2017 CEST
gpg:                using RSA key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4
gpg: Good signature from "Stefan Claas <stefan.claas at posteo.de>" [ultimate]

A friend just recently posted a message in a Usenet Group and i get this:

gpg --verify m123.eml
gpg: Signature made Xx 00 Jun 00:00:00 2017 CEST
gpg:                using RSA key 0000000000000000
gpg: Good signature from "xxxxxx xxxxxxxxx <xxxxxxx at example.com>" [full]
gpg: xxxxxx at example.com: Verified 4 signatures in the past 7 days. 
Encrypted 0 messages.

I will now also sign my message and hope i don't mess this post up,
so that you can verify my sig and tell me if it shows you also the
long-key ID or full key on your system.

Regards
Stefan



-------------- 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/20170615/d085083c/attachment.sig>

From stefan.claas at posteo.de  Thu Jun 15 19:36:12 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 15 Jun 2017 19:36:12 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
Message-ID: <d9f7926f-01d9-4ee1-b36a-d712e5a5e6f2@posteo.de>


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

Am 15.06.17 um 18:59 schrieb Stefan Claas:

> I will now also sign my message and hope i don't mess this post up, > so that you can verify my sig and tell me if it shows you also the >
long-key ID or full key on your system. > ... just in case an inline
signed message.

Regards
Stefan


-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEK6+F+SgavVQ4I8fFmB63w4LsUrQFAllCxYIACgkQmB63w4Ls
UrRYqwgAyjwUtAY4D/aITtoGmjpk82Dkv4Qj2zIpUWe3SINTuvX5WiclGBOBkGQS
GkgdD/ZgeUlbbirf4sRrOoWj7HLNcHCm4tHt6hukn+QxBqOvaLmKOTOogPoP1t2R
dY813bKYyTmtd18JxgjyIoyFSZr1wqTb7Am5qAdtj6C/DbzDv9WMbTiSOfeld6T0
qlLB/fUJ5ZtgF9huSnOuHPh0yQvn9wGw0ue1r85dY7W+5Yp4wKlqWNhe8G14BjgU
1hg4JxtKTBiSPXszmw38HYjMXSAkFuZT26a+6aJtyGWxtYNmjr0Rlrgd1/iAkoWB
p7i1aBNE/rRgZun2HD4/FIgsKF+eEQ==
=+Jga
-----END PGP SIGNATURE-----



From stefan.claas at posteo.de  Thu Jun 15 19:39:10 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 15 Jun 2017 19:39:10 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <d9f7926f-01d9-4ee1-b36a-d712e5a5e6f2@posteo.de>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
 <d9f7926f-01d9-4ee1-b36a-d712e5a5e6f2@posteo.de>
Message-ID: <2a17f787-2844-4111-dbf8-2c22f1edb9b9@posteo.de>

Am 15.06.17 um 19:36 schrieb Stefan Claas:
>
> Am 15.06.17 um 18:59 schrieb Stefan Claas:
>
> > I will now also sign my message and hope i don't mess this post up,
> > so that you can verify my sig and tell me if it shows you also the >
> long-key ID or full key on your system. > ... just in case an inline
> signed message.
>
> Regards
> Stefan
>
>

I love Thunderbird and Enigmail.


-------------- 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/20170615/aa3e89f7/attachment.sig>

From tlikonen at iki.fi  Thu Jun 15 22:29:41 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Thu, 15 Jun 2017 23:29:41 +0300
Subject: modern GnuPG verify signatures
In-Reply-To: <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de> (Stefan Claas's
 message of "Thu, 15 Jun 2017 18:59:41 +0200")
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
Message-ID: <87y3st0zbe.fsf@mithlond.arda>

Stefan Claas [2017-06-15 18:59:41+02] wrote:

> I clearsign a text file and verify it and modern GnuPG shows me this:
>
> gpg --verify my_message.txt
> gpg: Signature made Do 15 Jun 18:31:05 2017 CEST
> gpg:                using RSA key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4
> gpg: Good signature from "Stefan Claas <stefan.claas at posteo.de>" [ultimate]
>
> A friend just recently posted a message in a Usenet Group and i get this:
>
> gpg --verify m123.eml
> gpg: Signature made Xx 00 Jun 00:00:00 2017 CEST
> gpg:                using RSA key 0000000000000000
> gpg: Good signature from "xxxxxx xxxxxxxxx <xxxxxxx at example.com>" [full]
> gpg: xxxxxx at example.com: Verified 4 signatures in the past 7 days. 
> Encrypted 0 messages.

Perhaps it can be seen as bug that there is the full fingerprint in some
places and long key id in other places.

I'm guessing that there are different code paths internally: In the
first example the trust level is calculated from web of trust (own key,
ultimate trust). In the second example there's also tofu trust model
involved because it shows statistics for verifying and encryption.

But those who know the code can answer.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170615/8bc71e75/attachment-0001.sig>

From stefan.claas at posteo.de  Thu Jun 15 22:47:00 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Thu, 15 Jun 2017 22:47:00 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <87y3st0zbe.fsf@mithlond.arda>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
 <87y3st0zbe.fsf@mithlond.arda>
Message-ID: <20170615224700.141b87387345556073b2769e@posteo.de>

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

On Thu, 15 Jun 2017 23:29:41 +0300
Teemu Likonen <tlikonen at iki.fi> wrote:

> Stefan Claas [2017-06-15 18:59:41+02] wrote:
> 
> > I clearsign a text file and verify it and modern GnuPG shows me this:
> >
> > gpg --verify my_message.txt
> > gpg: Signature made Do 15 Jun 18:31:05 2017 CEST
> > gpg:                using RSA key 2BAF85F9281ABD543823C7C5981EB7C382EC52B4
> > gpg: Good signature from "Stefan Claas <stefan.claas at posteo.de>" [ultimate]
> >
> > A friend just recently posted a message in a Usenet Group and i get this:
> >
> > gpg --verify m123.eml
> > gpg: Signature made Xx 00 Jun 00:00:00 2017 CEST
> > gpg:                using RSA key 0000000000000000
> > gpg: Good signature from "xxxxxx xxxxxxxxx <xxxxxxx at example.com>" [full]
> > gpg: xxxxxx at example.com: Verified 4 signatures in the past 7 days. 
> > Encrypted 0 messages.
> 
> Perhaps it can be seen as bug that there is the full fingerprint in some
> places and long key id in other places.
> 
> I'm guessing that there are different code paths internally: In the
> first example the trust level is calculated from web of trust (own key,
> ultimate trust). In the second example there's also tofu trust model
> involved because it shows statistics for verifying and encryption.
> 
> But those who know the code can answer.

Thanks for your reply!

Well, then let's wait and see what other people say, who know the code.
Maybe members can confirm the same behaviour under Windows and Linux.

Regards
Stefan

- -- 
https://keybase.io/stefan_claas
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEK6+F+SgavVQ4I8fFmB63w4LsUrQFAllC8kQACgkQmB63w4Ls
UrQNiAgAm18QjF4SzHpOvJZSCREFEtII57EKnrruV5jYqJRNAthqbDAdPJfP+x/z
eQ6MoomSm+0IZOKCfet22096SI1aTwsFaF7wmohpeqd03Rum3JEVpueYEdaZXWg0
gnV7t7wdThavFV6WBoJvnf3gvbVh0k92Pvo92Ns9UQQ01EZdlExEt4IkD9dzXlF5
JgtL2mpG3Nj3wM7Eanph0lfRaxeHo9Yi+iWaz35E6TIsRCmrmcBkGAmM5Kghb6Pr
pGk4VVPBpE0hJg8AdoAEy8/UacNebe6oIbmbI9PmpA58KVAHOam2t90Dj8g8Xp8W
GpBtDSb0KUrbKQSYzznBhCws649b2g==
=DS+C
-----END PGP SIGNATURE-----


From listofactor at mail.ru  Fri Jun 16 08:17:06 2017
From: listofactor at mail.ru (listo factor)
Date: Fri, 16 Jun 2017 06:17:06 +0000
Subject: Key expiration question
In-Reply-To: <2d98d78f-bc75-f673-1e78-f97be8abcfed@digitalbrains.com>
References: <wJSA_AqTA9t74bMVquBBMPn88klEoaBQMnOrOct-8nnY0lbRu5Vr0URFNHrE_ne6AfPNR9AEJ2dQWPHddWXmQYWeGwNqmfA7D15YehezgFg=@hor.rocks>
 <2d98d78f-bc75-f673-1e78-f97be8abcfed@digitalbrains.com>
Message-ID: <6944c93c-2368-9bb5-14b1-f2dca3db3dd5@mail.ru>

On 06/13/2017 01:02 PM, Peter Lebbing wrote:
> 
> An expired key will definitely not be able to issue valid signatures
> after the expiration date. 

There is nothing ~in the key itself~ that prevents any key
from being used to create signatures, it is only a feature of
the software used to create the signature to compare a date in
the key with some arbitrary external information (computer
system date) that may or may not observe such limitation.
The key expiration date should therefore be considered a only
~suggestion~, and not a ~limitation~ for creating or not
creating signatures.


From tlikonen at iki.fi  Fri Jun 16 09:06:38 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Fri, 16 Jun 2017 10:06:38 +0300
Subject: Revoking a certificate (--edit-key + revsig)
Message-ID: <87bmpobedd.fsf@mithlond.arda>

My question is simple (kind of): In what situations would you revoke a
certificate that you have made on someone else's key? (Technically:
--edit-key + revsig.)

Background concepts: When we sign a key (--edit-key + sign) we certify a
particular user id, the link between the user id and person (or
sometimes group) identity. Something like that. It's difficult to put
this concrete enough but abstract enough to cover all cases but you know
what I mean.

But what would you say about conceptual meaning of revoking such
certificate (--edit-key + revsig)? Maybe the link between the key or a
particular user id and the actual person or group identity has been cut:
person lost his secret key or just password and can't control the key
anymore. So maybe by revsig a person gives a signal that he knows the
link has been broken and tell people to not rely on his certificate
anymore. Am I right?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170616/c7ad434a/attachment.sig>

From lists at binarus.de  Fri Jun 16 10:27:19 2017
From: lists at binarus.de (Binarus)
Date: Fri, 16 Jun 2017 10:27:19 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
Message-ID: <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>

At first, I'd like to thank you for the great explanations.

On 14.06.2017 19:21, Juan Miguel Navarro Mart?nez wrote:

> As far as I know, GPGSM is a GPG tool to use X.509 certificates. That's
> not the OpenPGP protocol. With this said...

Here is where my worry begins. AFAIK, all PGP variants are using RSA key
pairs. A public X.509 certificate is just a container for such keys (and
possibly has information about the certificate chain). Given that, in my
naive world, it should be no problem to extract that public PGP key from
the certificate; the goal would be to gain the "pure" key which then
could be added to the traditional PGP (Enigmail / gpg4win) world.

Of course, any information regarding the certification chain would be
lost when doing so, but I really wouldn't care about that (I have
downloaded the certificate from the website of a very big well-known
company; the website is protected by TLS, and I have checked that there
was no man in the middle).

Unfortunately, I didn't find any hint on how to extract that key. It is
in the certificate for sure, and I think I will eventually be able to
dump it after playing some time with OpenSSL, but then I eventually
won't know how to integrate it into Enigmail / gpg4win.

Furthermore, I am still not sure if this is just a matter of
transforming the key or if the whole software / data exchange protocol
depends on the sort of key. In other words, even if I would manage to
extract the key and to integrate it into the Enigmail / gpg4win world,
would the communication partner be able to decrypt the respective messages?

> For GnuPG to use KBX format, you must have the modern branch which is
> 2.1 and later. For that, you need to use the experimental version of
> Gpg4Win:

This is a very important hint. I didn't even know that such a branch
exists. An average user visiting their website mainly for downloading
their software won't see any hint regarding that ... or I have missed
something.

> After you download the experimental version, you must do the follow:
[...]
> 
> I must remind you that your partner's key will still be a X.509 key and
> so you'll still need to use GPGSM to list, verify messages from and
> encrypt message to that key but now both public OpenPGP and X.509 keys
> will be stored in pubring.kbx.

Thank you very much for the manual :-) So I now know how use pubring.kbx
instead of pubring.gpg, but obviously, this is not the solution to my
problem (as I initially have thought).

The bottom line seems to be that I can't use Enigmail / gpg4win to
exchange email with communication partners which provide their keys in
form of certificates. This does not make much sense since there is a
strong trend among the big companies to provide only PGP certificates
instead of PGP keys.

Using gpgsm on the command line is not what I would like to in my daily
email routine (although I am a strong fan of the command line in other
situations).

Slightly off-topic: Does anybody eventually know if and when Enigmail /
gpg4win will support certificates?

Thank you very much,

Binarus


From peter at digitalbrains.com  Fri Jun 16 11:17:34 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 16 Jun 2017 11:17:34 +0200
Subject: Key expiration question
In-Reply-To: <6944c93c-2368-9bb5-14b1-f2dca3db3dd5@mail.ru>
References: <wJSA_AqTA9t74bMVquBBMPn88klEoaBQMnOrOct-8nnY0lbRu5Vr0URFNHrE_ne6AfPNR9AEJ2dQWPHddWXmQYWeGwNqmfA7D15YehezgFg=@hor.rocks>
 <2d98d78f-bc75-f673-1e78-f97be8abcfed@digitalbrains.com>
 <6944c93c-2368-9bb5-14b1-f2dca3db3dd5@mail.ru>
Message-ID: <f69f9fb1-a2ff-d2b7-c8bf-3bd48c1bc9aa@digitalbrains.com>

On 16/06/17 08:17, listo factor via Gnupg-users wrote:
>> An expired key will definitely not be able to issue valid 
>> signatures after the expiration date.
> 
> There is nothing ~in the key itself~ that prevents any key from
> being used to create signatures

There is nothing ~in the key itself~ that makes a signature /valid/ or
not. It's either correct or incorrect, but I distinctly said /valid/.
The OpenPGP-compatible software that checks the signature is what
decides whether the signature is valid or not, and a signature carrying
a timestamp later than the expiry date of the key will not be considered
valid.

> some arbitrary external information (computer system date)

I was talking about timestamps included in the key (expiry date) and
signature (signature creation time), not about the system time of the
system doing verification. On the other hand, stuff appearing to be from
the future is usually rejected outright, so the system time is somewhat
involved.

> The key expiration date should therefore be considered a only
> ~suggestion~, and not a ~limitation~ for creating or not creating
> signatures.

It's true it's not a limitation on creating signatures. But the
interesting bit isn't the creation of signatures. It's verifying the
validity of signatures, which is very much /limited/ by other factors
than just the raw key material, not merely suggested.

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/20170616/ac6e738f/attachment.sig>

From peter at digitalbrains.com  Fri Jun 16 11:29:10 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 16 Jun 2017 11:29:10 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
Message-ID: <5b2eb277-c12f-3601-ae2b-94d3e39e44bb@digitalbrains.com>

On 16/06/17 10:27, Binarus wrote:
> [...] or if the whole software / data exchange protocol depends on
> the sort of key. In other words, even if I would manage to extract
> the key and to integrate it into the Enigmail / gpg4win world, would
> the communication partner be able to decrypt the respective
> messages?

This. It serves no purpose other than to confuse, to send someone who
doesn't use OpenPGP an OpenPGP message. People using X.509 certificates
for e-mail will probably expect S/MIME messages, which while potentially
using RSA just as OpenPGP can use, are distinctly different from OpenPGP
messages.

> This does not make much sense since there is a strong trend among the
> big companies to provide only PGP certificates instead of PGP keys.

This is phrased wrong. Actually, what many people call OpenPGP keys are
more accurately called OpenPGP certificates. But X.509 certificates are
not OpenPGP certificates in any sense. They both potentially use RSA.
But RSA is an algorithm, giving computation rules for numbers. RSA is
not a data format or standard for message exchange. That would be
OpenPGP or S/MIME, which do not interoperate. And, by the way, don't
even necessarily use RSA at all, it's just a common option.

I hope this makes it more clear to you.

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/20170616/315ebc70/attachment.sig>

From dgouttegattat at incenp.org  Fri Jun 16 11:32:15 2017
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Fri, 16 Jun 2017 11:32:15 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
Message-ID: <ea624959-b12f-7bfe-616a-53559889cb18@incenp.org>

Hi,

On 06/16/2017 10:27 AM, Binarus wrote:
> Unfortunately, I didn't find any hint on how to extract that key. It is
> in the certificate for sure, and I think I will eventually be able to
> dump it after playing some time with OpenSSL, but then I eventually
> won't know how to integrate it into Enigmail / gpg4win.

Well, there is the Monkeysphere's pem2openpgp tool [1], but AFAIK it 
only works with *private* keys, not public keys.


> Furthermore, I am still not sure if this is just a matter of
> transforming the key or if the whole software / data exchange protocol
> depends on the sort of key. In other words, even if I would manage to
> extract the key and to integrate it into the Enigmail / gpg4win world,
> would the communication partner be able to decrypt the respective messages?

No. You would generate an OpenPGP-encrypted message that your partner 
won't be able to decrypt using their S/MIME software. They would need an 
OpenPGP implementation (be it GnuPG or any other one).



> The bottom line seems to be that I can't use Enigmail / gpg4win to
> exchange email with communication partners which provide their keys in
> form of certificates. This does not make much sense since there is a
> strong trend among the big companies to provide only PGP certificates
> instead of PGP keys.

You seem to be confused between OpenPGP certificates and X.509 
certificates, and I think this is the root of your problem.

Let me try to explain.

There are two completely independent standard for e-mail encryption and 
signing: OpenPGP and S/MIME.

Each standard uses its own formats. OpenPGP uses OpenPGP certificates 
(which are called "public key" out of habit, but they really are 
certificates), and S/MIME uses X.509 certificates.

Both partners in a conversation have to use the same standard, either 
OpenPGP or S/MIME (of course they can use *any* software implementing 
the same standard, because that's what standards are all about).

Now what you got from your partner is a X.509 certificate, which means 
that said partner is using S/MIME, not OpenPGP.

There's no many options here: you and your partner must agree on the 
standard you use for your communications. Either you convince your 
partner to switch to OpenPGP when he is communicating with you, or you 
switch yourself to S/MIME when you're communicating with him.


> Slightly off-topic: Does anybody eventually know if and when Enigmail /
> gpg4win will support certificates?

Thunderbird already supports S/MIME and X.509 certificates natively, you 
do not need Enigmail for that.


Damien

[1] http://web.monkeysphere.info/

-------------- 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/20170616/94c73b60/attachment-0001.sig>

From lists at binarus.de  Fri Jun 16 15:04:13 2017
From: lists at binarus.de (Binarus)
Date: Fri, 16 Jun 2017 15:04:13 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <ea624959-b12f-7bfe-616a-53559889cb18@incenp.org>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
 <ea624959-b12f-7bfe-616a-53559889cb18@incenp.org>
Message-ID: <64114c03-8514-4166-c0c4-223bf63f711f@binarus.de>

On 16.06.2017 11:32, Damien Goutte-Gattat wrote:

> Well, there is the Monkeysphere's pem2openpgp tool [1], but AFAIK it
> only works with *private* keys, not public keys.

Most articles / tutorials I came across during my research were dealing
with private keys ... that should have made me mistrustful on its own.

> No. You would generate an OpenPGP-encrypted message that your partner
> won't be able to decrypt using their S/MIME software. They would need an
> OpenPGP implementation (be it GnuPG or any other one).

This is where I have been mislead. Of course, I already knew that S/MIME
and PGP are both widely used, but totally different, and it was also
clear to me that a recipient who uses S/MIME has no way to decrypt PGP
messages, and vice versa.

There were three things which pulled me on the wrong track:

1) My new communication partner claimed that they supported S/MIME as
well as PGP, making the impression that I could choose which one I would
like to use. I told him that I would like to use PGP (as I've always
done in similar cases in the past) and not S/MIME.

2) My new communication partner claimed (even in written form) that the
certificate they provided to me was a "PGP certificate". Well, we all
probably know the level of technical knowledge in big companies'
customer support ... I should have been warned.

3) I would never have come to the idea that GnuPG handles S/MIME
certificates. Obviously, gpgsm is part of GnuPG, and obviously, it can
handle the certificate which I have been given. Thus, I have been quite
sure that it indeed must have been some sort of "PGP certificate",
because I couldn't imagine that a part of GnuPG software could deal with
S/MIME certificates.

So GnuPG seems to be in the process of becoming an S/MIME software, a
thing which I would have heavily denied until now if somebody would have
asked me.

These three reasons made me strongly believe that the certificate I have
been given actually was a thing like PGP key in a "modern" format. So I
was convinced that I could convert it to the usual PGP key format somehow.

(Sidenote: The naming of that utility of course finally makes sense now
... I have done gpgsm <some options> and have wondered about the name of
that program more than one time :-)

> You seem to be confused between OpenPGP certificates and X.509
> certificates, and I think this is the root of your problem.

Not at the level of general understanding, but having been heavily
mislead in this case (see above) ...

> Thunderbird already supports S/MIME and X.509 certificates natively, you
> do not need Enigmail for that.

Yes, I have configured Thunderbird often in all sorts of environment and
therefore often have come across the S/MIME configuration window. So I
knew it was in there, but I did not use it until now.

The actual cause of my problem, as you have already stated, is quite
simple: I just did not know nor assume nor even consider that the
certificate I have been given could be an S/MIME certificate. Now that I
know that, I am quite confident that I will be able to configure and use
S/MIME properly.

Once again, a big thanks for all the help and for your time!

Regards,

Binarus



From juanmi.3000 at gmail.com  Fri Jun 16 14:46:24 2017
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Fri, 16 Jun 2017 14:46:24 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
Message-ID: <b5216602-de9a-cf32-851c-7b84f211d76c@gmail.com>

On 2017-06-16 at 10:27, Binarus wrote:
> Here is where my worry begins. AFAIK, all PGP variants are using RSA key
> pairs. A public X.509 certificate is just a container for such keys (and
> possibly has information about the certificate chain). Given that, in my
> naive world, it should be no problem to extract that public PGP key from
> the certificate; the goal would be to gain the "pure" key which then
> could be added to the traditional PGP (Enigmail / gpg4win) world.
> 

I wouldn't try to transform an X.509 certificate into an OpenPGP
certificate for the reasons already talked in here.

If you want to use OpenPGP, tell your partner to make an OpenPGP
certificate using GnuPG or any OpenPGP supported software. You can them
make PGP/Inline or PGP/MIME (if your email client/plugin supports it,
Enigmail does) email.

If you want to use the X.509 certificate of your partner, you must use
an X.509-supported client to generate a certificate (OpenSSL normally
but Kleopatra, which comes by default with Gpg4Win unless selected
otherwise, also allows you to generate an X.509). Normally, email
software support S/MIME messages and there is no need for an extra
plugin. Thunderbird does so by default and you can configure your X.509
from the Security section of your account settings.

The problem with an X.509 is that it usually requires a Certificate
Authority (CA) to make a trusted signature. Comodo allows you to sign-up
for a free certificate X.509 certificate for each of your personal
emails. There may be others, some paid.

> Unfortunately, I didn't find any hint on how to extract that key. It is
> in the certificate for sure, and I think I will eventually be able to
> dump it after playing some time with OpenSSL, but then I eventually
> won't know how to integrate it into Enigmail / gpg4win.
> 

Enigmail only works with OpenPGP-related keys.
gpg4win is only a suite of GnuPG related software, with GPGSM for the
management of X.509 certs. Kleopatra is only a front-end GUI client for
both OpenPGP and X.509 operations with the respecting GnuPG tools.

> Furthermore, I am still not sure if this is just a matter of
> transforming the key or if the whole software / data exchange protocol
> depends on the sort of key. In other words, even if I would manage to
> extract the key and to integrate it into the Enigmail / gpg4win world,
> would the communication partner be able to decrypt the respective messages?
> 

As said above, if your partner uses X.509 then use X.509. If you want to
use OpenPGP tell him to make an OpenPGP key.

If he tries to decrypt a PGP/Inline or PGP/MIME message using an S/MIME
client it won't work. He'll need a PGP/Inline or PGP/MIME compatible
software for that (Thunderbird with Enigmail; Claws Mail, Mutt, etc...).

>> For GnuPG to use KBX format, you must have the modern branch which is
>> 2.1 and later. For that, you need to use the experimental version of
>> Gpg4Win:
> 
> This is a very important hint. I didn't even know that such a branch
> exists. An average user visiting their website mainly for downloading
> their software won't see any hint regarding that ... or I have missed
> something.
> 

It was announced on the mail-list of Gpg4Win. But you can also find the
Beta directory link in the mid part of "All Downloads" section in the
Download page.

> Using gpgsm on the command line is not what I would like to in my daily
> email routine (although I am a strong fan of the command line in other
> situations).
>

If you want to manage certs with GUI client use an S/MIME-supported
email client, which you do with Thunderbird, or Kleopatra for X.509 as I
said above.

> Slightly off-topic: Does anybody eventually know if and when Enigmail /
> gpg4win will support certificates?
> 

And to reiterate again, Enigmail, as far as I know, will only support
OpenPGP certificate or keys.
Gpg4Win supports X.509 by using the GPGSM CLI tool or Kleopatra as a GUI
front-end but for S/MIME emails I would recommend an email client like
Thunderbird.

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- 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/20170616/daf064df/attachment.sig>

From lists at binarus.de  Fri Jun 16 16:52:32 2017
From: lists at binarus.de (Binarus)
Date: Fri, 16 Jun 2017 16:52:32 +0200
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <b5216602-de9a-cf32-851c-7b84f211d76c@gmail.com>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
 <b5216602-de9a-cf32-851c-7b84f211d76c@gmail.com>
Message-ID: <7f91a856-9902-067d-f850-b8a0c2399471@binarus.de>

On 16.06.2017 14:46, Juan Miguel Navarro Mart?nez wrote:

[..]
> If you want to use OpenPGP, tell your partner to make an OpenPGP
> certificate using GnuPG or any OpenPGP supported software. You can them
> make PGP/Inline or PGP/MIME (if your email client/plugin supports it,
> Enigmail does) email.
[...]
> Enigmail only works with OpenPGP-related keys.
> gpg4win is only a suite of GnuPG related software, with GPGSM for the
> management of X.509 certs. Kleopatra is only a front-end GUI client for
> both OpenPGP and X.509 operations with the respecting GnuPG tools.
[...]
> As said above, if your partner uses X.509 then use X.509. If you want to
> use OpenPGP tell him to make an OpenPGP key.
[...]
> If he tries to decrypt a PGP/Inline or PGP/MIME message using an S/MIME
> client it won't work. He'll need a PGP/Inline or PGP/MIME compatible
> software for that (Thunderbird with Enigmail; Claws Mail, Mutt, etc...).
[...]
> It was announced on the mail-list of Gpg4Win. But you can also find the
> Beta directory link in the mid part of "All Downloads" section in the
> Download page.
[...]
> And to reiterate again, Enigmail, as far as I know, will only support
> OpenPGP certificate or keys.
> Gpg4Win supports X.509 by using the GPGSM CLI tool or Kleopatra as a GUI
> front-end but for S/MIME emails I would recommend an email client like
> Thunderbird.

Again, thank you very much for your time. I have got it now. I will just
use S/MIME to communicate with that partner.

Please see my previous post for a detailed explanation why I have been
worried so much (although it has been clear to me since a long time that
S/MIME and PGP are different things).

To make a long story short, my partner first asked me if I would like to
use PGP or S/MIME (I answered "PGP"), and then claimed that the
certificate he provided was a "PGP certificate".

Furthermore, I wouldn't have come to the idea that gpgsm handled S/MIME
certificates (although I am now understanding why it is named gpg>SM<
:-)). In my naive world, GnuPG software (and gpgsm obviously falls into
that category) dealt only with PGP, not with S/MIME. Worlds change ...

For that three reasons, I did not even consider that the certificate my
partner provided could be an S/MIME certificate, but believed that it
would be some sort of a "new, modern PGP certificate". If I only had
known that earlier ...

Sorry for the lengthy posts, and again: Thanks you very much!

Binarus



From stefan.claas at posteo.de  Fri Jun 16 20:39:31 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Fri, 16 Jun 2017 20:39:31 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <20170615224700.141b87387345556073b2769e@posteo.de>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
 <87y3st0zbe.fsf@mithlond.arda>
 <20170615224700.141b87387345556073b2769e@posteo.de>
Message-ID: <20170616203931.e72bac700a926299c9064cbf@posteo.de>

On Thu, 15 Jun 2017 22:47:00 +0200
Stefan Claas <stefan.claas at posteo.de> wrote:

> Well, then let's wait and see what other people say, who know the code.
> Maybe members can confirm the same behaviour under Windows and Linux.

O.k., i checked the Windows version of modern GnuPG and there it is correct.

The Mac version, which only shows the long key-ID and not the complete key,
like the Windows version does, is (again) downloaded from here:

https://sourceforge.net/p/gpgosx/docu/Download/

Regards
Stefan

-- 
https://keybase.io/stefan_claas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: </pipermail/attachments/20170616/1e667601/attachment.sig>

From guru at unixarea.de  Fri Jun 16 20:46:24 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 16 Jun 2017 20:46:24 +0200
Subject: setting GnuPG card to 'not forces' does not let sign
In-Reply-To: <87wp8hh3qo.fsf@wheatstone.g10code.de>
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>
Message-ID: <20170616184624.GA2410@c720-r314251>

El d?a lunes, junio 12, 2017 a las 12:58:23p. m. +0200, Werner Koch escribi?:

> On Mon, 12 Jun 2017 12:38, guru at unixarea.de said:
> 
> > Do you know of any other CCID reader for ID-000 size cards?
> 
> I have a sample of the Gemalto Shell Token here.  It has been around for
> quite some time and the kernelconcept folks that it works nicely.  See
> 
>   https://www.floss-shop.de/en/security-privacy/
> 
> On that page you also find the a bit more expensive uTrust token which
> would be my preferred choice. I used it for many years until it broke due
> to my fault.  In fact I recycled the case for my gnuk token.

I bought the uTrust token in the above mentioned FLOSS-shop and it arrived today.
It shows in my netbook the same problem as the other one from Omnikey:
it is not always detected at power-on boot:

In the boot at 14:17:02 it is seen, while later it takes three boot to be
seen by the kernel:

Jun 16 14:17:02 c720-r314251 syslogd: kernel boot file is /boot/kernel/kernel
Jun 16 14:17:02 c720-r314251 kernel: ugen0.2: <Identiv uTrust 3512 SAM slot Token> at usbus0

Jun 16 20:20:48 c720-r314251 syslogd: kernel boot file is /boot/kernel/kernel

Jun 16 20:23:28 c720-r314251 syslogd: kernel boot file is /boot/kernel/kernel

Jun 16 20:25:49 c720-r314251 syslogd: kernel boot file is /boot/kernel/kernel
Jun 16 20:25:49 c720-r314251 kernel: ugen0.4: <Identiv uTrust 3512 SAM slot Token> at usbus0

Perhaps, it is more a netbook's (Acer C720) or FreeBSD issue.

	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/20170616/7a640efe/attachment-0001.sig>

From wk at gnupg.org  Sat Jun 17 10:35:46 2017
From: wk at gnupg.org (Werner Koch)
Date: Sat, 17 Jun 2017 10:35:46 +0200
Subject: How to use a PKCS#15 with GnuPG?
In-Reply-To: <341d82e1-1fba-4a2a-40ae-0bb2ef74b2ce@gmail.com> (NdK's message
 of "Thu, 15 Jun 2017 14:13:38 +0200")
References: <341d82e1-1fba-4a2a-40ae-0bb2ef74b2ce@gmail.com>
Message-ID: <87a857j9jx.fsf@wheatstone.g10code.de>

On Thu, 15 Jun 2017 14:13, ndk.clanbo at gmail.com said:

> authentication and signing). Both ePass2003 and MyID implement PKCS#15,
> so IIUC they should be usable.

gpg expects an OpenPGP card.  For pkcs#15 you need to use gpgsm.  As a
starter do

 gpgsm --learn-card

which imports the certificates from such cards.  There is no --card-edit
etc, because in general PKCS#15 cards are distributed personalized.
Having done --learn-card once you can use the keys from the card for
X.509 or CMS (aks S/MIME) stuff.

But note, that PKCS#15 does not specifiy everything and card vendors
oftne implement proprietary extensions/modifications.  See
gnupg/scd/app-p15.c for some hints.



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/20170617/03c975d1/attachment.sig>

From stefan.claas at posteo.de  Sat Jun 17 11:01:18 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sat, 17 Jun 2017 11:01:18 +0200
Subject: modern GnuPG verify signatures
In-Reply-To: <20170616203931.e72bac700a926299c9064cbf@posteo.de>
References: <d331d5e5-8c77-1c93-2d70-62bee5e9ae3b@posteo.de>
 <d2a7c325-4471-280a-8277-7b0367e68ef0@digitalbrains.com>
 <79c1818f-a95f-6c70-6319-46ddf66df668@posteo.de>
 <87y3st0zbe.fsf@mithlond.arda>
 <20170615224700.141b87387345556073b2769e@posteo.de>
 <20170616203931.e72bac700a926299c9064cbf@posteo.de>
Message-ID: <20170617110118.feedd07f66c265560a3e613c@posteo.de>

On Fri, 16 Jun 2017 20:39:31 +0200
Stefan Claas <stefan.claas at posteo.de> wrote:

> On Thu, 15 Jun 2017 22:47:00 +0200
> Stefan Claas <stefan.claas at posteo.de> wrote:
> 
> > Well, then let's wait and see what other people say, who know the code.
> > Maybe members can confirm the same behaviour under Windows and Linux.
> 
> O.k., i checked the Windows version of modern GnuPG and there it is correct.
> 
> The Mac version, which only shows the long key-ID and not the complete key,

O.k. i figured out that it works the same on the Mac version, if the
signature is made with modern GnuPG too.

-- 
https://keybase.io/stefan_claas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: </pipermail/attachments/20170617/8872ad80/attachment.sig>

From ndk.clanbo at gmail.com  Sat Jun 17 11:15:53 2017
From: ndk.clanbo at gmail.com (NdK)
Date: Sat, 17 Jun 2017 11:15:53 +0200
Subject: How to use a PKCS#15 with GnuPG?
In-Reply-To: <87a857j9jx.fsf@wheatstone.g10code.de>
References: <341d82e1-1fba-4a2a-40ae-0bb2ef74b2ce@gmail.com>
 <87a857j9jx.fsf@wheatstone.g10code.de>
Message-ID: <1d3de13f-c694-eef9-4ed2-5d9b7ea9fc21@gmail.com>

Il 17/06/2017 10:35, Werner Koch ha scritto:

> gpg expects an OpenPGP card.  For pkcs#15 you need to use gpgsm.  As a
> starter do
>  gpgsm --learn-card
> which imports the certificates from such cards.  There is no --card-edit
> etc, because in general PKCS#15 cards are distributed personalized.
> Having done --learn-card once you can use the keys from the card for
> X.509 or CMS (aks S/MIME) stuff.
Then I don't understand the reason for gpgsm (the "niche" it fills)...
opensc already supports many cards, and can even edit some. And (via
PKCS#11) Firefox and Thunderbird (and many other programs, but only one
at a time) can use the cards for auth (and signing).

> But note, that PKCS#15 does not specifiy everything and card vendors
> oftne implement proprietary extensions/modifications.
As usual. But even openpgp RFCs are often implemented with proprietary
extensions...

> See gnupg/scd/app-p15.c for some hints.
I'll have a look.

Tks,
 Diego



From christopher.donald.jones at gmail.com  Sun Jun 18 03:48:17 2017
From: christopher.donald.jones at gmail.com (Christopher Jones)
Date: Sun, 18 Jun 2017 01:48:17 +0000
Subject: Using gpg for ssh (Maximum Portability)
Message-ID: <CADJBR=CpapYtoszWR2oNFqxpjRFXmsrYuVyLeYvxxhWqr12ccQ@mail.gmail.com>

I recently setup my GPG keys on yubikey. I carry it around and its pretty
great. One of the ways I use these keys is to ssh into various systems.
While the hardware is portable the system is a little more difficult.

It's a task to setup gpg on new boxes: Import pub key, ultimately trust my
key, and muck around with gpg and ssh agents.

Are there ways people on this list have found to make using PGP for ssh
more portable? Any shortcuts for scripting some of this nonsense out, or a
any way to carry what you need on a single hardware device like a yubikey?

I use fedora, Redd Hat, and windows with cygwin primarily,

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170618/cad97421/attachment.html>

From longsi0008 at gmail.com  Mon Jun 19 04:23:58 2017
From: longsi0008 at gmail.com (Long Si)
Date: Mon, 19 Jun 2017 10:23:58 +0800
Subject: Creating Unique Fingerprint
Message-ID: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>

Hi

I am on Linux, and would like to generate a key with "unique 40" fingerprint.

eg 1: Starts with ABCD XXXX ... XXXX

eg 2: Starts with AXXX XXXX ... XXXA ends with A

eg 3: XXXX ... XXXX without any '0' character at all

How would I go about writing such a script? Don't mind running for
months to get these sets.

Regards


From stefan.claas at posteo.de  Mon Jun 19 08:16:25 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Mon, 19 Jun 2017 08:16:25 +0200
Subject: Creating Unique Fingerprint
In-Reply-To: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
Message-ID: <3wrgjZ1Fxfz10HS@submission01.posteo.de>

Am Mon, 19 Jun 2017 10:23:58 +0800
schrieb Long Si <longsi0008 at gmail.com>:

> Hi
> 
> I am on Linux, and would like to generate a key with "unique 40"
> fingerprint.
> 
> eg 1: Starts with ABCD XXXX ... XXXX
> 
> eg 2: Starts with AXXX XXXX ... XXXA ends with A
> 
> eg 3: XXXX ... XXXX without any '0' character at all
> 
> How would I go about writing such a script? Don't mind running for
> months to get these sets.

If there would be such a script, we would have a problem... ;-)

But you can generate a key with a 32bit key-id of your choice,
with scallion:

https://github.com/lachesis/scallion

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170619/f92fc72a/attachment.sig>

From lewisurn at gmail.com  Mon Jun 19 08:00:04 2017
From: lewisurn at gmail.com (Lou Wynn)
Date: Sun, 18 Jun 2017 23:00:04 -0700
Subject: Creating Unique Fingerprint
In-Reply-To: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
Message-ID: <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>

According to my understanding of crypto theory, your only way is to
generate keys and compare their fingerprints and with the value you
want. I would be surprised that you can find one in your lifetime. Or
it'd be a breakthrough in cryptography if you managed to do it somehow.

Thanks,
Lou

On 06/18/2017 07:23 PM, Long Si wrote:
> Hi
>
> I am on Linux, and would like to generate a key with "unique 40" fingerprint.
>
> eg 1: Starts with ABCD XXXX ... XXXX
>
> eg 2: Starts with AXXX XXXX ... XXXA ends with A
>
> eg 3: XXXX ... XXXX without any '0' character at all
>
> How would I go about writing such a script? Don't mind running for
> months to get these sets.
>
> Regards
>
> _______________________________________________
> 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/20170618/837b84d1/attachment.html>

From kirelagin at gmail.com  Mon Jun 19 08:30:08 2017
From: kirelagin at gmail.com (Kirill Elagin)
Date: Mon, 19 Jun 2017 06:30:08 +0000
Subject: Creating Unique Fingerprint
In-Reply-To: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
Message-ID: <CABVT_geR2+JuuEJU=w5+oH6nA8MA3t6eZfM_7FcAnsDM0tEs+g@mail.gmail.com>

The easiest strategy, of course, is to simply use gpg to generate a key and
check its fingerprint until you get the one you need (see batch mode).
Generation of an RSA 2048 key is taking around a second, so e.g. for your
example #1 (four bytes fixed) we are talking tens of hours or ones of days.

In case you need something better, you?ll have to get inside the public key
packet. Basically, fingerprint is a hash of the actual public key material
and its creation timestamp, so if you do not care much about creation
timestamps, you can bruteforce _them_, which will be much faster. This way
you might get a timestamp that doesn?t make sense (e.g. in the future) and
some implementations can potentially become upset, so you either accept
that or choose timestamps carefully.

If you don?t need the key to actually work, that is, be able to
encrypt/decrypt, then you can safely brute force its other parameters, such
as p, q and e.

I do not know if there are tools around, but hacking GnuPG code should not
be too difficult.

On Mon, Jun 19, 2017 at 6:44 AM Long Si <longsi0008 at gmail.com> wrote:

> Hi
>
> I am on Linux, and would like to generate a key with "unique 40"
> fingerprint.
>
> eg 1: Starts with ABCD XXXX ... XXXX
>
> eg 2: Starts with AXXX XXXX ... XXXA ends with A
>
> eg 3: XXXX ... XXXX without any '0' character at all
>
> How would I go about writing such a script? Don't mind running for
> months to get these sets.
>
> Regards
>
> _______________________________________________
> 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/20170619/df9bd5f2/attachment-0001.html>

From longsi0008 at gmail.com  Mon Jun 19 16:34:52 2017
From: longsi0008 at gmail.com (Long Si)
Date: Mon, 19 Jun 2017 22:34:52 +0800
Subject: Creating Unique Fingerprint
In-Reply-To: <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
 <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>
Message-ID: <CAFfRHj1D7HhJq06nD=ovqe6JgWxoxcbFhNrCG-tYU6EwLHH0_w@mail.gmail.com>

Hi everyone

Thanks for your input so far. I am surprised to learn about the
suggested methods. For my example 1, I had assumed there would be only
(1/16)^4 combinations so it should be fairly quick (i.e. less than a
week to find one).

Let say for now, I just want my full fingerprint to start with a 'A'.
With a possibility of 1/16, I assumed this should take less than a day
of computing power. Can anyone show me a script to do so?

I wish to have a working key, of course, with my chosen name, email, etc...


Regards


From kirelagin at gmail.com  Mon Jun 19 17:56:47 2017
From: kirelagin at gmail.com (Kirill Elagin)
Date: Mon, 19 Jun 2017 15:56:47 +0000
Subject: Creating Unique Fingerprint
In-Reply-To: <CAFfRHj1D7HhJq06nD=ovqe6JgWxoxcbFhNrCG-tYU6EwLHH0_w@mail.gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
 <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>
 <CAFfRHj1D7HhJq06nD=ovqe6JgWxoxcbFhNrCG-tYU6EwLHH0_w@mail.gmail.com>
Message-ID: <CABVT_geO24hTO_HhxYd3Zj2RM=N3R4v_6w4qtryTwr7YuV1Zsw@mail.gmail.com>

Google is a pretty great tool for this kind of things.
Here is one of the results I found:
https://github.com/Valodim/pgp-vanity-keygen

As far as I can tell from the source, it uses the method I suggested,
decreasing timestamp one by one, and it finds a fingerprint that ends in a
given string of bytes. This last part is not exactly what you need, so
you?ll have to adjust the test yourself, but other than that it seems to be
a reasonable ?plug-and-play? solution for your task.

On Mon, Jun 19, 2017 at 6:38 PM Long Si <longsi0008 at gmail.com> wrote:

> Hi everyone
>
> Thanks for your input so far. I am surprised to learn about the
> suggested methods. For my example 1, I had assumed there would be only
> (1/16)^4 combinations so it should be fairly quick (i.e. less than a
> week to find one).
>
> Let say for now, I just want my full fingerprint to start with a 'A'.
> With a possibility of 1/16, I assumed this should take less than a day
> of computing power. Can anyone show me a script to do so?
>
> I wish to have a working key, of course, with my chosen name, email, etc...
>
>
> Regards
>
> _______________________________________________
> 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/20170619/e546bdac/attachment.html>

From dkg at fifthhorseman.net  Mon Jun 19 23:36:05 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 19 Jun 2017 17:36:05 -0400
Subject: How to join pubring.kbx and pubring.gpg?
In-Reply-To: <ea624959-b12f-7bfe-616a-53559889cb18@incenp.org>
References: <285f3697-9041-ad46-7ee7-c63cd5bdbd88@binarus.de>
 <6432c78a-6f71-f708-c062-6b9c2e9a7557@gmail.com>
 <d93136f8-31e5-79d3-8c0c-e7e0d5a9424a@binarus.de>
 <ea624959-b12f-7bfe-616a-53559889cb18@incenp.org>
Message-ID: <87mv93lkxm.fsf@fifthhorseman.net>

On Fri 2017-06-16 11:32:15 +0200, Damien Goutte-Gattat wrote:
> Well, there is the Monkeysphere's pem2openpgp tool [1], but AFAIK it 
> only works with *private* keys, not public keys.

for the record, pem2openpgp works with both public keys and private
keys.

        --dkg


From nils at familievogels.nl  Tue Jun 20 00:11:33 2017
From: nils at familievogels.nl (Nils Vogels)
Date: Tue, 20 Jun 2017 00:11:33 +0200
Subject: Hybrid keysigning party, your opinion?
In-Reply-To: <8f6baa7b-c1f5-3a00-ed30-e5e7f332817b@digitalbrains.com>
References: <ef4ac807-48d6-462b-8920-75739610fd11@digitalbrains.com>
 <46a4ec4d-d5da-432f-7210-40141aaf15fc@twopif.net>
 <fdcc36fc-01f3-1a9f-8cb7-bab2881ccd8c@digitalbrains.com>
 <4be0f.02234dc6be.9633E9D0-9736-4200-97FF-9ABEE5256254@familievogels.nl>
 <8f6baa7b-c1f5-3a00-ed30-e5e7f332817b@digitalbrains.com>
Message-ID: <01b115e545da50fd6db5f0f57650d37b@familievogels.nl>

Hey Peter, and list!

Peter Lebbing schreef op 2017-02-20 17:58:
> On 19/02/17 21:16, Nils Vogels wrote:
>> I'll read up on this thread from the archives, but I'm exploring 
>> possibilities
>> to enhance the FOSDEM format with the use of QR for on-the-spot 
>> signing for
>> those who want to and don't mind having signatures submitted by 
>> signers to
>> keyservers.
> 
> Thank you for organizing a party! I'm definitely up for assisting with 
> the
> organization.
> 

The keysigning party has been scheduled for monday 7/8/17, and I'm 
drafting the wiki pages with instructions as we speak, using a slightly 
modernized Sassaman-Efficient protocol, and see where we go from there.

Feel free to check out https://program.sha2017.org/events/245.html and 
https://wiki.sha2017.org/w/Keysigning-Party, and offcourse, join in! :)

Regards,
Nils


From madduck at madduck.net  Tue Jun 20 15:34:44 2017
From: madduck at madduck.net (martin f krafft)
Date: Tue, 20 Jun 2017 15:34:44 +0200
Subject: Managing the WoT with GPG
Message-ID: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>

Hello,

I've spent some time trying to figure out how to make actual use of
the web-of-trust (the "pgp" trust-model), and I am turning to this
list for some advice, related to a couple of questions:

1. My public keyring has several thousand keys and "weighs" almost
   500Mb. Every couple of runs, I'm told to run --check-trustdb,
   which takes several minutes to complete, then tells me that the
   next run will be in like 2 weeks, but three operations later, I'm
   again being asked to run --check-trustdb. The funny thing is that
   these operations are just message signing and authentication,
   sometimes decryption. However, parcimonie is running in the
   background, updating the keyring one key at a time. Is that the
   reason? If yes, is there any way to mitigate this? I've sketched
   out an idea under (3.) below, but maybe there's another way??

2. I've also tried running --update-trustdb, but it seems that this
   process is *endless*. I have no idea how many keys remain, and
   I also got the impression that I keep seeing keys I already
   processed. How do you approach this? Or does everyone just use
   tofu these days?

3. Is there a way to run --check-trustdb or --update-trustdb not
   over the entire key graph, but only traversing to a certain depth
   starting from a specific key? Then I could tell parcimonie to run
   --check-trustdb for every key it imports, or have mutt run
   --update-trustdb for every key I want to use. This would
   iteratively achieve the job with the benefit that no cycles would
   be wasted processing trust for keys I never use. I understand
   --edit-key can be used to change the ownertrust, but I don't
   think it recomputes the WoT on change, does it?

   If there's no way to do this yet, would this be a useful addition
   to the UI, assuming it's technically possible?

4. Is there a tool to visualise or explain the computed validity of
   a key? I.e. one saying that e.g. Werner's key is valid because
   Daniel signed it, and I fully trust Daniel? There's wotsap, but
   I want to analyse my own keyring, not a .wot file?

5. Has anyone come up with a smart way to keep pubring/trustdb
   synchronised between multiple workstations?

Thanks for any insights!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
darwinism is nothing without enough dead bodies.
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170620/2aed2238/attachment.sig>

From rexk99 at gmail.com  Tue Jun 20 17:43:16 2017
From: rexk99 at gmail.com (Rex Kneisley)
Date: Tue, 20 Jun 2017 08:43:16 -0700
Subject: Having trouble adding gpg key to apt keyring in Debian 9.0 (Stretch)
Message-ID: <CAEbDWPVWE78mO_Pu95tHBmcyKc4QFSUp-dPhuUTh1XWJOJ5Hgg@mail.gmail.com>

Hey Guys,

So I recently did a fresh install of Debian 9.0 (Stretch).

Now I'm trying to reinstall all of my software.

I had Sublime Text installed in 8.6 (Jessie)

But when I try to install Sublime Text, I encounter the following error
when trying to add the PGP key to apt-key.

root at debian-rig:/home/rexk# wget -qO -
https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
gpg: WARNING: nothing exported
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

This process worked flawlessly in Debian Jessie

Is the Sublime Text gpg key formatted wrong since now version 2.1.18 is
built in to Debian?

root at debian-rig:/home/rexk# gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta
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: /root/.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


By the way, I can download this key directly and import it in the GnuPG
Keyring without any problems.

root at debian-rig:/home/rexk# gpg --import sublimehq-pub.gpg
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key ADAE6AD28A8F901A: public key "Sublime HQ Pty Ltd <
support at sublimetext.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1


-- 
Sincerely,


Rex Kneisley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170620/ce964876/attachment-0001.html>

From dkg at fifthhorseman.net  Tue Jun 20 19:56:57 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jun 2017 13:56:57 -0400
Subject: Having trouble adding gpg key to apt keyring in Debian 9.0
 (Stretch)
In-Reply-To: <CAEbDWPVWE78mO_Pu95tHBmcyKc4QFSUp-dPhuUTh1XWJOJ5Hgg@mail.gmail.com>
References: <CAEbDWPVWE78mO_Pu95tHBmcyKc4QFSUp-dPhuUTh1XWJOJ5Hgg@mail.gmail.com>
Message-ID: <874lvaleza.fsf@fifthhorseman.net>

Hi Rex--

On Tue 2017-06-20 08:43:16 -0700, Rex Kneisley wrote:
> root at debian-rig:/home/rexk# wget -qO -
> https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
> gpg: WARNING: nothing exported
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0

While it's a common recommendation, "apt-key add -" is generally a bad
idea, because it mixes the fetched keys in with all the other keys.
It's a better idea to fetch the keys for a given repository separately
and mark them as acceptable only for this specific repo.

Since you're using debian stable (stretch), you might want to read:

    https://wiki.debian.org/DebianRepository/UseThirdParty

From its suggestions, if you want to add the sublime repo (which i have
never vetted and am not personally recommending here), you might prefer
to do the following on debian stretch:

    wget -O /usr/share/keyring/sublimehq-pub.gpg.asc https://download.sublimetext.com/sublimehq-pub.gpg
    gpg --dearmor < /usr/share/keyring/sublimehq-pub.gpg.asc > /usr/share/keyring/sublimehq-pub.gpg
    echo 'deb [signed-by=/usr/share/keyring/sublimehq-pub.gpg] https://download.sublimetext.com/ apt/stable/' > /etc/apt/sources.list.d/sublime.list

This makes it so the sublime repository key is not accepted for
certifying the main debian repos (which it should not be doing).

I suspect that the problem you were having may have to do with the
ascii-armoring on the fetched file, which is why i've included the
--dearmor line in the middle of the three steps above.

hope this helps,

     --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/20170620/bf3359ce/attachment.sig>

From mailinglist at darac.org.uk  Wed Jun 21 11:27:31 2017
From: mailinglist at darac.org.uk (Darac Marjal)
Date: Wed, 21 Jun 2017 10:27:31 +0100
Subject: Having trouble adding gpg key to apt keyring in Debian 9.0
 (Stretch)
In-Reply-To: <874lvaleza.fsf@fifthhorseman.net>
References: <CAEbDWPVWE78mO_Pu95tHBmcyKc4QFSUp-dPhuUTh1XWJOJ5Hgg@mail.gmail.com>
 <874lvaleza.fsf@fifthhorseman.net>
Message-ID: <20170621092731.hmo2sguzkv3ot4x3@darac.org.uk>

On Tue, Jun 20, 2017 at 01:56:57PM -0400, Daniel Kahn Gillmor wrote:
>Hi Rex--
>
>On Tue 2017-06-20 08:43:16 -0700, Rex Kneisley wrote:
>> root at debian-rig:/home/rexk# wget -qO -
>> https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
>> gpg: WARNING: nothing exported
>> gpg: no valid OpenPGP data found.
>> gpg: Total number processed: 0
>
>While it's a common recommendation, "apt-key add -" is generally a bad
>idea, because it mixes the fetched keys in with all the other keys.
>It's a better idea to fetch the keys for a given repository separately
>and mark them as acceptable only for this specific repo.
>
>Since you're using debian stable (stretch), you might want to read:
>
>    https://wiki.debian.org/DebianRepository/UseThirdParty
>
>From its suggestions, if you want to add the sublime repo (which i have
>never vetted and am not personally recommending here), you might prefer
>to do the following on debian stretch:
>
>    wget -O /usr/share/keyring/sublimehq-pub.gpg.asc https://download.sublimetext.com/sublimehq-pub.gpg
>    gpg --dearmor < /usr/share/keyring/sublimehq-pub.gpg.asc > /usr/share/keyring/sublimehq-pub.gpg
>    echo 'deb [signed-by=/usr/share/keyring/sublimehq-pub.gpg] https://download.sublimetext.com/ apt/stable/' > /etc/apt/sources.list.d/sublime.list

Thank you. I've been meaning to switch my apt sources over to this style
for a while, but couldn't seem to get apt to see the separate keys. It
looks like I was missing out the "[signed-by=...]" part.

>
>This makes it so the sublime repository key is not accepted for
>certifying the main debian repos (which it should not be doing).
>
>I suspect that the problem you were having may have to do with the
>ascii-armoring on the fetched file, which is why i've included the
>--dearmor line in the middle of the three steps above.
>
>hope this helps,
>
>     --dkg



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


-- 
For more information, please reread.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 906 bytes
Desc: not available
URL: </pipermail/attachments/20170621/70f6dc20/attachment.sig>

From madduck at madduck.net  Wed Jun 21 11:03:40 2017
From: madduck at madduck.net (martin f krafft)
Date: Wed, 21 Jun 2017 11:03:40 +0200
Subject: Key corruption: duplicate signatures and usage flags
Message-ID: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>

Hey,

My key on the keyservers is 0x55C9882D999BBCC4. If I download this
to a fresh keyring, I get some weird behaviours:

  % alias gpg='gpg --homedir=.'
  % gpg --recv-key 0x55C9882D999BBCC4
  gpg: keybox '/home/ssd/madduck/.tmp/cdt.p0R8ly/pubring.kbx' created
  gpg: /home/ssd/madduck/.tmp/cdt.p0R8ly/trustdb.gpg: trustdb created
  gpg: key 55C9882D999BBCC4: public key "Martin F. Krafft <mail at martin-krafft.net>" imported
  gpg: no ultimately trusted keys found
  gpg: Total number processed: 1
  gpg:               imported: 1

  % gpg --list-keys !$
  gpg --list-keys 0x55C9882D999BBCC4
  pub   rsa4096 2009-07-06 [SC] [expires: 2020-02-01]
      	2CCB26BC5C49BC221F20794255C9882D999BBCC4
  uid           [ unknown] Martin F. Krafft <mail at martin-krafft.net>
  uid           [ unknown] Martin F. Krafft <madduck at madduck.net>
  uid           [ unknown] Martin F. Krafft (Debian) <madduck at debian.org>
  uid           [ unknown] [jpeg image of size 2160]
  sub   rsa4096 2016-07-01 [E] [expires: 2018-02-01]
  sub   rsa4096 2016-12-01 [S] [expires: 2018-02-01]
  sub   rsa4096 2016-12-01 [A] [expires: 2018-02-01]

So far, so good. Do note the [SC] usage flags.

And then check this out:

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

  uid  Martin F. Krafft <madduck at madduck.net>
  sig!3        55C9882D999BBCC4 2009-07-06 never       [self-signature]
  sig!3        55C9882D999BBCC4 2017-06-07 never       [self-signature]*
              [expires: 2020-02-01 11:20:11]
  sig!3        55C9882D999BBCC4 2009-07-06 never       [self-signature]
    x-hkp://pool.sks-keyservers.net

  [?]

  sub  AD18B605905834CC
  sig!    P    55C9882D999BBCC4 2015-07-01 never       [self-signature]*
    Signature policy: http://martin-krafft.net/gpg/cert-policy/55c9882d999bbcc4/201412051354?sha512sum=a5f417ebe563ed63cc3bbc4b14da4983e30d8ada7b2ba94b6de5e7a74bee6ab55c6ca307e163c33a6bf242e8ce4ca5fe99a271dd3b41626d3b4a10203a5c7225
              [expires: 2010-08-07 08:37:18]

  [?]

  key 55C9882D999BBCC4:
  24 duplicate signatures removed

That's a bit weird. Where do these come from?

But there's more: now the usage flag of the primary key has been
changed to just 'C' (which is what I uploaded), and ?

  pub  rsa4096/55C9882D999BBCC4
      created: 2009-07-06  expires: 2020-02-01  usage: C
      trust: unknown       validity: unknown
  [?]

? a subsequent save spews a weird list of "Preferred keyserver:"
text to stdout, but now the usage flag of the primary key is also
just [C] in the --list-keys output:

  gpg> save
  Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: %

  % gpg --list-keys 0x55C9882D999BBCC4
  pub   rsa4096 2009-07-06 [C] [expires: 2020-02-01]
        2CCB26BC5C49BC221F20794255C9882D999BBCC4
  [?]

Do you have any idea what might be going on here? Is this a problem,
or just cosmetic? Is it fixable? How?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"life moves pretty fast. if you don't stop and look around once in
 a while, you could miss it."
                                                     -- ferris bueller
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170621/63121f2a/attachment.sig>

From tlikonen at iki.fi  Wed Jun 21 13:36:48 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Wed, 21 Jun 2017 14:36:48 +0300
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 (martin f. krafft's message of "Wed, 21 Jun 2017 11:03:40 +0200")
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
Message-ID: <87efudbmi7.fsf@mithlond.arda>

martin f. krafft [2017-06-21 11:03:40+02] wrote:

>   24 duplicate signatures removed
>
> That's a bit weird. Where do these come from?

I've seen the message with other keys too, just after --edit-key. The
number of duplicate signatures varies. Next --refresh-keys command
downloads the signatures back.

I tried your key and got the same results.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170621/c7748efa/attachment.sig>

From neal at walfield.org  Wed Jun 21 11:53:49 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 21 Jun 2017 11:53:49 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
Message-ID: <87mv911xaq.wl-neal@walfield.org>

Hi,

At Tue, 20 Jun 2017 15:34:44 +0200,
martin f krafft wrote:
> I've spent some time trying to figure out how to make actual use of
> the web-of-trust (the "pgp" trust-model), and I am turning to this
> list for some advice, related to a couple of questions:
> 
> 1. My public keyring has several thousand keys and "weighs" almost
>    500Mb. Every couple of runs, I'm told to run --check-trustdb,
>    which takes several minutes to complete, then tells me that the
>    next run will be in like 2 weeks, but three operations later, I'm
>    again being asked to run --check-trustdb. The funny thing is that
>    these operations are just message signing and authentication,
>    sometimes decryption. However, parcimonie is running in the
>    background, updating the keyring one key at a time. Is that the
>    reason? If yes, is there any way to mitigate this? I've sketched
>    out an idea under (3.) below, but maybe there's another way??

You figured it out: whenever your keyring is updated, 'gpg
--check-trustdb' needs to be run.  This is normally done on demand,
which is annoying for even moderately sized keyrings.  You can disable
this behavior by setting no-auto-check-trustdb in your gpg.conf file.
In that case, you'll want to run 'gpg --check-trustdb' periodically to
integrate new keys, expiry information, revocations, etc.  You can do
this in the background via e.g. a cron job.

> 2. I've also tried running --update-trustdb, but it seems that this
>    process is *endless*. I have no idea how many keys remain, and
>    I also got the impression that I keep seeing keys I already
>    processed. How do you approach this? Or does everyone just use
>    tofu these days?

Since I don't trust most people to sign keys correctly, I just invoke
'gpg --edit-key' (and use the trust subcommand) on the specific keys
that I want to have as trusted introducers.

> 3. Is there a way to run --check-trustdb or --update-trustdb not
>    over the entire key graph, but only traversing to a certain depth
>    starting from a specific key? Then I could tell parcimonie to run
>    --check-trustdb for every key it imports, or have mutt run
>    --update-trustdb for every key I want to use. This would
>    iteratively achieve the job with the benefit that no cycles would
>    be wasted processing trust for keys I never use. I understand
>    --edit-key can be used to change the ownertrust, but I don't
>    think it recomputes the WoT on change, does it?
> 
>    If there's no way to do this yet, would this be a useful addition
>    to the UI, assuming it's technically possible?

This isn't easy given the current implementation: GnuPG doesn't store
the graph, but traverses the graph and only saves whether a particular
key is trusted.

> 4. Is there a tool to visualise or explain the computed validity of
>    a key? I.e. one saying that e.g. Werner's key is valid because
>    Daniel signed it, and I fully trust Daniel? There's wotsap, but
>    I want to analyse my own keyring, not a .wot file?

See my answer to #3: this is not currently possible.

> 5. Has anyone come up with a smart way to keep pubring/trustdb
>    synchronised between multiple workstations?

This is a pain.  Something along the lines of the following should
work:

  gpg --export | ssh host gpg --import

:) Neal


From madduck at madduck.net  Wed Jun 21 13:55:52 2017
From: madduck at madduck.net (martin f krafft)
Date: Wed, 21 Jun 2017 13:55:52 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <87mv911xaq.wl-neal@walfield.org>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
Message-ID: <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>

also sprach Neal H. Walfield <neal at walfield.org> [2017-06-21 11:53 +0200]:
> > 3. Is there a way to run --check-trustdb or --update-trustdb not
> >    over the entire key graph, but only traversing to a certain depth
> >    starting from a specific key? Then I could tell parcimonie to run
> >    --check-trustdb for every key it imports, or have mutt run
> >    --update-trustdb for every key I want to use. This would
> >    iteratively achieve the job with the benefit that no cycles would
> >    be wasted processing trust for keys I never use. I understand
> >    --edit-key can be used to change the ownertrust, but I don't
> >    think it recomputes the WoT on change, does it?
> > 
> >    If there's no way to do this yet, would this be a useful addition
> >    to the UI, assuming it's technically possible?
> 
> This isn't easy given the current implementation: GnuPG doesn't store
> the graph, but traverses the graph and only saves whether a particular
> key is trusted.

It's gotta start somewhere, though, right? Can't it pick the leaf
where to start?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
dies ist eine manuell generierte email. sie beinhaltet
tippfehler und ist auch ohne gro?buchstaben g?ltig.
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170621/e1c172a8/attachment-0001.sig>

From neal at walfield.org  Wed Jun 21 14:00:30 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Wed, 21 Jun 2017 14:00:30 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
Message-ID: <87k2451rfl.wl-neal@walfield.org>

At Wed, 21 Jun 2017 13:55:52 +0200,
martin f krafft wrote:
> 
> also sprach Neal H. Walfield <neal at walfield.org> [2017-06-21 11:53 +0200]:
> > > 3. Is there a way to run --check-trustdb or --update-trustdb not
> > >    over the entire key graph, but only traversing to a certain depth
> > >    starting from a specific key? Then I could tell parcimonie to run
> > >    --check-trustdb for every key it imports, or have mutt run
> > >    --update-trustdb for every key I want to use. This would
> > >    iteratively achieve the job with the benefit that no cycles would
> > >    be wasted processing trust for keys I never use. I understand
> > >    --edit-key can be used to change the ownertrust, but I don't
> > >    think it recomputes the WoT on change, does it?
> > > 
> > >    If there's no way to do this yet, would this be a useful addition
> > >    to the UI, assuming it's technically possible?
> > 
> > This isn't easy given the current implementation: GnuPG doesn't store
> > the graph, but traverses the graph and only saves whether a particular
> > key is trusted.
> 
> It's gotta start somewhere, though, right? Can't it pick the leaf
> where to start?

It starts with the set of ultimately trusted keys.  But let's say that
you start with key X, which is not ultimately trusted.  What should
GnuPG do with the result?  Or, let's say that X is ultimately trusted
and it decides that key Y is only marginally trusted, but Y would have
been fully trusted if you started with all ultimately trusted keys.
How do you intelligently merge that?


From justus at g10code.com  Wed Jun 21 14:24:14 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 21 Jun 2017 14:24:14 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
Message-ID: <871sqdplzl.fsf@europa.jade-hamburg.de>

martin f krafft <madduck at madduck.net> writes:

> Hey,
>
> My key on the keyservers is 0x55C9882D999BBCC4. If I download this
> to a fresh keyring, I get some weird behaviours:

gpg --version please?

>   % alias gpg='gpg --homedir=.'

I tend to do: $ export GNUPGHOME=$(mktemp -d)

> So far, so good. Do note the [SC] usage flags.

What are the capabilities of your primary key supposed to be?

>   key 55C9882D999BBCC4:
>   24 duplicate signatures removed
>
> That's a bit weird. Where do these come from?

Not sure, but anyone can append stuff to your key on the keyservers.
Maybe some faulty software reordered the packages and uploaded it?

> But there's more: now the usage flag of the primary key has been
> changed to just 'C' (which is what I uploaded), and ?
>
>   pub  rsa4096/55C9882D999BBCC4
>       created: 2009-07-06  expires: 2020-02-01  usage: C
>       trust: unknown       validity: unknown
>   [?]
>
> ? a subsequent save spews a weird list of "Preferred keyserver:"
> text to stdout, but now the usage flag of the primary key is also
> just [C] in the --list-keys output:
>
>   gpg> save
>   Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: %
>
>   % gpg --list-keys 0x55C9882D999BBCC4
>   pub   rsa4096 2009-07-06 [C] [expires: 2020-02-01]
>         2CCB26BC5C49BC221F20794255C9882D999BBCC4
>   [?]

This is odd indeed.


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/20170621/5da2ca7e/attachment.sig>

From justus at g10code.com  Wed Jun 21 15:10:52 2017
From: justus at g10code.com (Justus Winter)
Date: Wed, 21 Jun 2017 15:10:52 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
Message-ID: <87y3slo59f.fsf@europa.jade-hamburg.de>

martin f krafft <madduck at madduck.net> writes:

> And then check this out:
>
>   % gpg --edit-key 0x55C9882D999BBCC4
>   gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.
>
>   uid  Martin F. Krafft <madduck at madduck.net>
>   sig!3        55C9882D999BBCC4 2009-07-06 never       [self-signature]
>   sig!3        55C9882D999BBCC4 2017-06-07 never       [self-signature]*
>               [expires: 2020-02-01 11:20:11]
>   sig!3        55C9882D999BBCC4 2009-07-06 never       [self-signature]
>     x-hkp://pool.sks-keyservers.net

Here  ^ is the keyserver url.

>   [?]
>
>   gpg> save
>   Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: %

And these are the labels for these urls.  This was a cosmetic problem
that I just fixed.



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/20170621/1ec0b7a5/attachment.sig>

From andrewg at andrewg.com  Wed Jun 21 15:57:37 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 21 Jun 2017 14:57:37 +0100
Subject: Managing the WoT with GPG
In-Reply-To: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
Message-ID: <a9b0d3e3-9c4b-0e33-ec7a-6b7768d23da7@andrewg.com>

On 2017/06/20 14:34, martin f krafft wrote:
> 5. Has anyone come up with a smart way to keep pubring/trustdb
>    synchronised between multiple workstations?

I have a quick and dirty tool here:

https://github.com/andrewgdotcom/synctrust

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/20170621/e6996547/attachment.sig>

From guilhem at fripost.org  Wed Jun 21 14:41:23 2017
From: guilhem at fripost.org (Guilhem Moulin)
Date: Wed, 21 Jun 2017 14:41:23 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
Message-ID: <20170621124123.3xq5susc5ju5qhve@localhost.localdomain>

Hi Martin,

On Wed, 21 Jun 2017 at 11:03:40 +0200, martin f krafft wrote:
> And then check this out:
> 
> % gpg --edit-key 0x55C9882D999BBCC4
> [?]
> 
> key 55C9882D999BBCC4:
> 24 duplicate signatures removed
> 
> That's a bit weird. Where do these come from?

The OpenPGP packets were not ordered properly, and gpg tried to clean
that up.  (Typically the signatures were placed under a subkey or the
wrong UID, then reordered to be placed under the proper component;
duplicate sigs currently arise when the key is refreshed.)  See issue
2236 for details and background: https://dev.gnupg.org/T2236

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170621/c5019a5c/attachment.sig>

From mac3iii at gmail.com  Wed Jun 21 17:14:36 2017
From: mac3iii at gmail.com (murphy)
Date: Wed, 21 Jun 2017 11:14:36 -0400
Subject: speedo Error 2, download swdb.lst failed
Message-ID: <fe2b2548-f33d-4f59-1cb6-8617b770cef6@gmail.com>

Hi all - during a routine build of gnupg-2.1.21 for Ubuntu 16.04 LTS a
speedo build from source that has consistently worked as recently as a
few days ago has now consistently hung up.  This is true on a Raspberry
Pi 3 armhf environment as well as Ubuntu linux.  The offending command
seems to be:

$ sudo make -f build-aux/speedo.mk native INSTALL_PREFIX=/usr/local
[sudo] password for murphy:
make -f /home/murphy/Downloads/gnupg-2.1.21/build-aux/speedo.mk
UPD_SWDB=1 TARGETOS=native WHAT=release WITH_GUI=0 all
make[1]: Entering directory '/home/murphy/Downloads/gnupg-2.1.21'
download of swdb.lst failed.
/home/murphy/Downloads/gnupg-2.1.21/build-aux/speedo.mk:272: *** Error
getting GnuPG software version database.  Stop.
make[1]: Leaving directory '/home/murphy/Downloads/gnupg-2.1.21'
build-aux/speedo.mk:72: recipe for target 'native' failed
make: *** [native] Error 2

Has there been a recent change affecting swdb.lst???  I have been using
the provided speedo method for years and have never encountered this
problem before.  It is now reproducible even on installations where it
previously succeeded in installing gnupg-2.1.21.

Thanks in advance, Murphy




From peter at digitalbrains.com  Wed Jun 21 19:02:26 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Jun 2017 19:02:26 +0200
Subject: TOFU
In-Reply-To: <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
Message-ID: <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>

On 08/06/17 22:33, Stefan Claas wrote:
> I did a test today with Enigmail and with TOFU in command line mode.
> I posted 3 messages with a fantasy name to a Usenet test group where
> the 3rd message was signed with a fake key and Enigmail showed me this:
> 
> UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:07
> 
> UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:08
> 
> UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:17
> 
> (It's the usual message under macOS with the blue bar. Note: with auto
> key retrival on.)
> 
> Then i downloaded all messages run them through GnuPG and on the first
> message TOFU already told me that there are 3 equal email addresses!

I don't understand what you mean by "there are 3 equal email addresses".
I don't know what you expected either. But I spent some time doing a
little test of my own. Hopefully by reading along with what I did, it
becomes clear how stuff works and to what extent Enigmail can already
work with TOFU even though it doesn't really support it.

TL;DR: Enigmail can correctly identify "genuine" signatures by awarding
them a green bar with "Good signature". Fakes can be spotted by the fact
they only get the blue "UNTRUSTED Good signature".

A little side note: since plaintext mails don't support much formatting,
the following is a tad bit hard to read. If I could have marked the
pieces with console output with a more distinguishing formatting, the
mail would have been a lot easier to read, but alas.


I created two keys bound to an existing e-mail address. (Note that the
address will not accept mail from the internet, only from within my
local network.) I will consider one key to be the "genuine" article, and
one key to be fake. Using Thunderbird and Enigmail, I sent myself two
messages with either key. One message is PGP/MIME. But since that is not
pleasant to work with on the command line and I wanted to do some
command line stuff as well, I also sent a message with an inline
signature, which I could then easily export to a file. So all in all, I
have four messages: one PGP/MIME from the real key, one inline from the
real key, one PGP/MIME from the fake key, and one inline from the fake key.

I then moved my real ~/.gnupg home directory out of the way and started
with a maiden directory containing just gpg.conf. gpg.conf contains
"trust-model tofu+pgp" (and nothing else).

Then I did the following steps:

- Using Thunderbird, open mail considered genuine
  Yellow bar, "Unverified signature", no key
- Import genuine key
- Go back to Thunderbird, re-open message:
  Blue bar, "UNTRUSTED Good signature"
- Go to command line:

---------------------------8<---------------->8---------------------------
$ gpg2 -k testgpg at butters.digitalbrains.com
pub   rsa2048 2017-06-21 [SC] [expires: 2019-06-21]
      ABEA7F4D39F72D2F15228F1206B2298382E57EFB
uid           [marginal] Test Real Mail <testgpg at butters.digitalbrains.com>
sub   rsa2048 2017-06-21 [E] [expires: 2019-06-21]
---------------------------8<---------------->8---------------------------

Marginal validity, per documentation for --tofu-default-policy auto.
Marginal validity is not enough for positively verifying signature
validity. Let's set tofu-policy to "good".

---------------------------8<---------------->8---------------------------
$ gpg2 --tofu-policy good ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Changing TOFU trust policy for binding <key:
ABEA7F4D39F72D2F15228F1206B2298382E57EFB, user id: Test Real Mail
<testgpg at butters.digitalbrains.com>> from auto to good.
---------------------------8<---------------->8---------------------------

- Go back to Thunderbird, re-open message:
  Green bar, "Good signature"
- Open second, inline signed message:
  Green bar, "Good signature"
- To the command line! Check inline message:
---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-genuine.asc
This is a signed mail from the account considered "genuine" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:37:46 CEST
gpg:                using RSA key ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [full]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     9 minutes.  Encrypted 0 messages.
---------------------------8<---------------->8---------------------------

Ah, good. The two signatures are the two mail messages. Note any
signature is always only counted once (it keeps a database of verified
signatures for that purpose).

- Go to Thunderbird, open "fake" message
  Yellow bar, "Unverified signature", no key
- Import fake key
- Go to Thunderbird, open "fake" message
  Blue bar, "UNTRUSTED Good signature"

Ah, good, it is not considered a "Good signature" (which I would have
called "Valid signature" to avoid confusion with "UNTRUSTED Good
signature" where "Good" means "correct" rather than "valid").

- Let's take a look at what happens if we look at the inline sig by the
fake key on the command line:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-fake.asc
This is a signed mail from the account considered "fake" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:43:17 CEST
gpg:                using RSA key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [undefined]
The email address "testgpg at butters.digitalbrains.com" is associated with
2 keys!  Please indicate whether this email address should be associated
with key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE or whether you think
someone is impersonating "testgpg at butters.digitalbrains.com".

This key's user IDs:
  Test Real Mail <testgpg at butters.digitalbrains.com> (policy: auto)

Statistics for keys with the email address
"testgpg at butters.digitalbrains.com":
  B0E1 6AFE C070 0656 231A  CCC3 4FC8 B80F 5FF2 12AE (this key):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 2.
  ABEA 7F4D 39F7 2D2F 1522  8F12 06B2 2983 82E5 7EFB (policy: good):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 2.

Normally, an email address is associated with a single key.  However,
people sometimes generate a new key if their key is too old or they think
it might be compromised.  Alternatively, a new key may indicate a
man-in-the-middle attack!  Before accepting this association, you should
talk to or call the person to make sure this new key is legitimate.

(G)ood, (A)ccept once, (U)nknown, (R)eject once, (B)ad?
---------------------------8<---------------->8---------------------------

So while Enigmail doesn't really support TOFU, merely not assigning
validity to wrong keys (which would be really bad), the command line
interface will immediately be very verbose about this situation. Let's
confirm that this is indeed an impostor by answering with a b for Bad.

---------------------------8<---------------->8---------------------------
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     2 minutes.  Encrypted 0 messages.
gpg: WARNING: We do NOT trust this key!
gpg:          The signature is probably a FORGERY.
---------------------------8<---------------->8---------------------------

Let's verify the same message again:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-fake.asc
This is a signed mail from the account considered "fake" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:43:17 CEST
gpg:                using RSA key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [never]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     8 minutes.  Encrypted 0 messages.
gpg: WARNING: We do NOT trust this key!
gpg:          The signature is probably a FORGERY.
---------------------------8<---------------->8---------------------------

GnuPG has indeed set the --tofu-policy for this key to "bad".

- Open a fake message again in Thunderbird:
  Blue bar, "UNTRUSTED Good signature"

Luckily it's still not assigning green "Good signature", but seeing how
the validity of this key is now "Never", it could, IMHO, also have said
something more explicit than UNTRUSTED.


Instead of the default --tofu-default-policy auto, you could also use
--tofu-default-policy good. I'll clear out my ~/.gnupg again and add
that to my gpg.conf. Then it will look as follows:

- Opening mail considered genuine
  Yellow bar, "Unverified signature", no key
- Import genuine key
- Go back to Thunderbird, re-open message:
  Green bar, "Good signature"
- Let's have a look at the command line:
---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-genuine.asc
This is a signed mail from the account considered "genuine" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:37:46 CEST
gpg:                using RSA key ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [full]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     20 seconds.  Encrypted 0 messages.
---------------------------8<---------------->8---------------------------

Signatures by this key are now considered fully valid, because we have
--tofu-default-policy good.

- Go to Thunderbird, open "fake" message
  Yellow bar, "Unverified signature", no key
- Import fake key
- Go to Thunderbird, open "fake" message
  Blue bar, "UNTRUSTED Good signature"

Ah, but since we already had a key for this e-mail address, TOFU no
longer defaults to considering the signature good. We have spotted the
fake: a real signature, either from a key seen before or from a key and
e-mail address never seen before, would be considered good, but not this
one.

- Let's take a look what the command line additionally tells us. Open a
signature by the real key:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-genuine.asc
This is a signed mail from the account considered "genuine" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:37:46 CEST
gpg:                using RSA key ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [undefined]
The email address "testgpg at butters.digitalbrains.com" is associated with
2 keys!  Please indicate whether this email address should be associated
with key ABEA7F4D39F72D2F15228F1206B2298382E57EFB or whether you think
someone is impersonating "testgpg at butters.digitalbrains.com".

This key's user IDs:
  Test Real Mail <testgpg at butters.digitalbrains.com> (policy: auto)

Statistics for keys with the email address
"testgpg at butters.digitalbrains.com":
  ABEA 7F4D 39F7 2D2F 1522  8F12 06B2 2983 82E5 7EFB (this key):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 2.
  B0E1 6AFE C070 0656 231A  CCC3 4FC8 B80F 5FF2 12AE (policy: auto):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 1.

Normally, an email address is associated with a single key.  However,
people sometimes generate a new key if their key is too old or they think
it might be compromised.  Alternatively, a new key may indicate a
man-in-the-middle attack!  Before accepting this association, you should
talk to or call the person to make sure this new key is legitimate.

(G)ood, (A)ccept once, (U)nknown, (R)eject once, (B)ad?
---------------------------8<---------------->8---------------------------

Since we haven't manually marked the real key as "good" yet, as can be
seen by "(policy: auto)" above, it will now present this conflict to us.
We can now flag the key as good, and it will no longer present us with
this conflict:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-genuine.asc
This is a signed mail from the account considered "genuine" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:37:46 CEST
gpg:                using RSA key ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [full]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     12 minutes.  Encrypted 0 messages.
---------------------------8<---------------->8---------------------------

I verified that marking the tofu-policy as good before even ever
encountering the fake key will avoid the message about the conflict and
immediately show this latest result.

Looking at a "fake" signature on the command line gives:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-fake.asc
This is a signed mail from the account considered "fake" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:43:17 CEST
gpg:                using RSA key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [undefined]
The email address "testgpg at butters.digitalbrains.com" is associated with
2 keys!  Please indicate whether this email address should be associated
with key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE or whether you think
someone is impersonating "testgpg at butters.digitalbrains.com".

This key's user IDs:
  Test Real Mail <testgpg at butters.digitalbrains.com> (policy: auto)

Statistics for keys with the email address
"testgpg at butters.digitalbrains.com":
  B0E1 6AFE C070 0656 231A  CCC3 4FC8 B80F 5FF2 12AE (this key):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 2.
  ABEA 7F4D 39F7 2D2F 1522  8F12 06B2 2983 82E5 7EFB (policy: good):
    Encrypted 0 messages.
    Messages verified over the past 1 day: 2.

Normally, an email address is associated with a single key.  However,
people sometimes generate a new key if their key is too old or they think
it might be compromised.  Alternatively, a new key may indicate a
man-in-the-middle attack!  Before accepting this association, you should
talk to or call the person to make sure this new key is legitimate.

(G)ood, (A)ccept once, (U)nknown, (R)eject once, (B)ad?
---------------------------8<---------------->8---------------------------

Let's choose b. From now on verifying a bad signature gives:

---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-fake.asc
This is a signed mail from the account considered "fake" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:43:17 CEST
gpg:                using RSA key B0E16AFEC0700656231ACCC34FC8B80F5FF212AE
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [never]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     4 minutes.  Encrypted 0 messages.
gpg: WARNING: We do NOT trust this key!
gpg:          The signature is probably a FORGERY.
---------------------------8<---------------->8---------------------------

Good signatures will stay as:
---------------------------8<---------------->8---------------------------
$ gpg2 -d inline-genuine.asc
This is a signed mail from the account considered "genuine" (inline
signature).
gpg: Signature made Wed 21 Jun 2017 17:37:46 CEST
gpg:                using RSA key ABEA7F4D39F72D2F15228F1206B2298382E57EFB
gpg: Good signature from "Test Real Mail
<testgpg at butters.digitalbrains.com>" [full]
gpg: testgpg at butters.digitalbrains.com: Verified 2 signatures in the past
     6 minutes.  Encrypted 0 messages.
---------------------------8<---------------->8---------------------------

We are no longer bothered about the fake key; it would be a bit annoying
if it kept droning on about it after we've already said it was bad.

I hope this has given you some more insight into how it works!

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/20170621/5b4eb1a5/attachment-0001.sig>

From peter at digitalbrains.com  Wed Jun 21 19:11:43 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Jun 2017 19:11:43 +0200
Subject: speedo Error 2, download swdb.lst failed
In-Reply-To: <fe2b2548-f33d-4f59-1cb6-8617b770cef6@gmail.com>
References: <fe2b2548-f33d-4f59-1cb6-8617b770cef6@gmail.com>
Message-ID: <83c67bd7-eb36-ab76-8fc0-afe790f2ac07@digitalbrains.com>

On 21/06/17 17:14, murphy wrote:
> download of swdb.lst failed.

I think this is because of an expired certificate for versions.gnupg.org:

$ wget -S https://versions.gnupg.org/swdb.lst
--2017-06-21 19:11:03--  https://versions.gnupg.org/swdb.lst
Resolving versions.gnupg.org (versions.gnupg.org)...
2001:aa8:fff1:2100::56, 217.69.76.56
Connecting to versions.gnupg.org
(versions.gnupg.org)|2001:aa8:fff1:2100::56|:443... failed: Connection
refused.
Connecting to versions.gnupg.org
(versions.gnupg.org)|217.69.76.56|:443... connected.
ERROR: The certificate of ?versions.gnupg.org? is not trusted.
ERROR: The certificate of ?versions.gnupg.org? has expired.
The certificate has expired

$ gnutls-cli -p https versions.gnupg.org
Processed 175 CA certificate(s).
Resolving 'versions.gnupg.org'...
Connecting to '2001:aa8:fff1:2100::56:443'...
Cannot connect to 2001:aa8:fff1:2100::56:443: Connection refused
Connecting to '217.69.76.56:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=versions.gnupg.org', issuer `C=US,O=Let's
Encrypt,CN=Let's Encrypt Authority X3', RSA key 2048 bits, signed using
RSA-SHA256, activated `2017-03-22 09:00:00 UTC', expires `2017-06-20
09:00:00 UTC', SHA-1 fingerprint `57a54fb00d2eabc40afe221720b73fd3038e3929'
        Public Key ID:
                ee4ff057a2b9a377fd7c4499e48f535633ccf304
        Public key's random art:
                +--[ RSA 2048]----+
                |              E. |
                |               Bo|
                |              o.O|
                |               +=|
                |        S   . .=.|
                |       . o o oo o|
                |        . = .. o |
                |       . .oo. ...|
                |        o+oo   .+|
                +-----------------+

- Certificate[1] info:
 - subject `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', issuer
`O=Digital Signature Trust Co.,CN=DST Root CA X3', RSA key 2048 bits,
signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires
`2021-03-17 16:40:46 UTC', SHA-1 fingerprint
`e6a3b45b062d509b3382282d196efe97d5956ccb'
- Status: The certificate is NOT trusted. The certificate chain uses
expired certificate.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.


My guess is that certbot, the tool usually responsible for downloading
new Let's Encrypt! certificates, hasn't been able to get a new
certificate for a month, and a system administrator needs to look into
getting it to succesfully obtain a new one.

The webserver also seems to reject IPv6 connections, BTW. I can
succesfully open IPv6 https connections with gnutls-cli to other sites.

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/20170621/e9712b2f/attachment.sig>

From peter at digitalbrains.com  Wed Jun 21 19:17:44 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Jun 2017 19:17:44 +0200
Subject: Using gpg for ssh (Maximum Portability)
In-Reply-To: <CADJBR=CpapYtoszWR2oNFqxpjRFXmsrYuVyLeYvxxhWqr12ccQ@mail.gmail.com>
References: <CADJBR=CpapYtoszWR2oNFqxpjRFXmsrYuVyLeYvxxhWqr12ccQ@mail.gmail.com>
Message-ID: <b3ed4af3-7bfc-f6e0-8b12-f63e64bd894a@digitalbrains.com>

On 18/06/17 03:48, Christopher Jones wrote:
> It's a task to setup gpg on new boxes: Import pub key, ultimately trust
> my key, and muck around with gpg and ssh agents.

If all you want to do is SSH, you don't need your key, so it reduces to
"muck around with gpg and ssh agents". As long as gpg-agent is correctly
configured to be an SSH agent, it will automagically use a plugged in
OpenPGP card with material in the Auth slot to do SSH authentication. No
OpenPGP key needed at all!

Configuring gpg as an SSH agent for Linux in the easiest way is very,
very distribution dependent. If you're lucky, it's a single switch
somewhere. systemd, or Xsession, or something similar.

And for non-Linux, I have no experience with that.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From dkg at fifthhorseman.net  Wed Jun 21 20:03:00 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 21 Jun 2017 14:03:00 -0400
Subject: Revoking a certificate (--edit-key + revsig)
In-Reply-To: <87bmpobedd.fsf@mithlond.arda>
References: <87bmpobedd.fsf@mithlond.arda>
Message-ID: <87y3slgqwb.fsf@fifthhorseman.net>

On Fri 2017-06-16 10:06:38 +0300, Teemu Likonen wrote:
> My question is simple (kind of): In what situations would you revoke a
> certificate that you have made on someone else's key? (Technically:
> --edit-key + revsig.)

That action would be me saying "i no longer believe that this key is
only controlled by the entity that corresponds to the identity in the
User ID"

in the abstract:

 * i learned via some channel i consider trustworthy that this key isn't
   appropriate for use with this User ID any more.

more concretely:

 * "I had lunch with Sarah and she told me she'd lost access to her
   secret key and didn't have a revocation certificate available."

or

 * "Acme Corp. just published a press release on their https website
   indicating that there was a break-in on their server "astrid".  I
   happen to know that the user account "archivemaster" on "astrid" has
   a copy of their software-signing secret keys, but they haven't
   revoked them publicly.  I no longer have confidence that this key is
   controlled solely by Acme Corp, so i'm removing my public attestation
   of it."

Does this make sense?  From the point of view of the person evaluating
the third-party signature, they can't tell the difference.  they just
know that before they saw the revocation, they know that "dkg says this
key belongs to Sarah" or "dkg says that this is Acme Corp's
software-signing key", and after they see the revocation, they know "dkg
doesn't have anything useful to say about the identities on this key --
they could belong to anyone".

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/20170621/d58465ae/attachment.sig>

From stefan.claas at posteo.de  Wed Jun 21 20:30:49 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 21 Jun 2017 20:30:49 +0200
Subject: TOFU
In-Reply-To: <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
Message-ID: <3wtCvm4lXxz105v@submission01.posteo.de>

On Wed, 21 Jun 2017 19:02:26 +0200, Peter Lebbing wrote:
> On 08/06/17 22:33, Stefan Claas wrote:
> > I did a test today with Enigmail and with TOFU in command line mode.
> > I posted 3 messages with a fantasy name to a Usenet test group where
> > the 3rd message was signed with a fake key and Enigmail showed me
> > this:
> > 
> > UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> > Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:07
> > 
> > UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> > Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:08
> > 
> > UNTRUSTED Good signature from Ernst Mustermann <em at example.com>
> > Key ID: 0x4608CFA2 / Signed on: 08.06.17, 21:17
> > 
> > (It's the usual message under macOS with the blue bar. Note: with
> > auto key retrival on.)
> > 
> > Then i downloaded all messages run them through GnuPG and on the
> > first message TOFU already told me that there are 3 equal email
> > addresses!  
> 
> I don't understand what you mean by "there are 3 equal email
> addresses". I don't know what you expected either. But I spent some
> time doing a little test of my own. Hopefully by reading along with
> what I did, it becomes clear how stuff works and to what extent
> Enigmail can already work with TOFU even though it doesn't really
> support it.
> 
> TL;DR: Enigmail can correctly identify "genuine" signatures by
> awarding them a green bar with "Good signature". Fakes can be spotted
> by the fact they only get the blue "UNTRUSTED Good signature".

[snip]

> I hope this has given you some more insight into how it works!

What i mean with my example is: As you can see there are 3 messages
with the same email address "em at example.com" The third message was
signed with a key having a fake 32bit key-id, which was generated
with scallion.

Technically spoken Enigmail showed all three messages as "Untrusted
Good Signature from Ernst Mustermann etc. , because i have not signed
the first key locally, to get for the first two messages a green bar
in Enigmail.

Had i used TOFU in CLI mode then of course TOFU had detected that the
third message is not done with the first key, used for the previous
two messages.

What i mean also with this example is that if people do not sign a
key locally after the second message, from people they do not know
personally, they may have a surprise in Enigmail when receiving the
third message.

This assumes auto-key-retrieve is on. Sure when replying to the third
message the user may be warned because now he/she should have two
public keys in his/her keyring.

To be fair, Ludwig announced the update to 64bit key-id's in Enigmail,
so that this issue should be gone by then.

Regards
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170621/8ab3b8cd/attachment.sig>

From peter at digitalbrains.com  Wed Jun 21 20:49:42 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Jun 2017 20:49:42 +0200
Subject: TOFU
In-Reply-To: <3wtCvm4n8Kz10HD@submission01.posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
Message-ID: <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>

On 21/06/17 20:30, Stefan Claas wrote:
> Technically spoken Enigmail showed all three messages as "Untrusted
> Good Signature from Ernst Mustermann etc. , because i have not signed
> the first key locally, to get for the first two messages a green bar
> in Enigmail.

Or either:
- Used --tofu-policy good on the key after the first message
- or even easier: used --tofu-default-policy good in gpg.conf

But think a while about what you want from TOFU before doing the latter.
It will automatically flag any non-conflicting OpenPGP key as valid (but
you could still manually flag a key as bad).

An "UNTRUSTED Good" signature from Enigmail means that you *should*
*not* award any credibility to the signature. It means there is *no*
indication that it belongs to the one you consider the real person
behind the address. I think it's a bad UX choice to name an invalid
signature "UNTRUSTED Good" and a valid signature "Good". I think it
suggests they both have some credibility, which is a false suggestion.

(When I say "invalid signature" I mean a signature by a key that does
not have full validity.)

> What i mean also with this example is that if people do not sign a
> key locally after the second message, from people they do not know
> personally, they may have a surprise in Enigmail when receiving the
> third message.

That stems from a misinterpretation. On the first and second messages,
"UNTRUSTED Good" is indicating it can't award any validity to the
signature. On the third message, it still cannot award any validity to
the signature. There is no surprise if you interpret it as this.

And the correct interpretation is vitally important! *Don't* *trust* any
signature that is "UNTRUSTED Good".

> To be fair, Ludwig announced the update to 64bit key-id's in Enigmail,
> so that this issue should be gone by then.

I think those things are unrelated. You don't use key ID's for
verification, neither short nor long ones. They are just easy
identifiers to refer to a key; if you need to verify the authenticity
you check the fingerprint, period. Not a long key ID, which would still
be marginally safe until computers are much faster, and certainly not a
short ID which is utterly unsafe and has always been.

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/20170621/4d5b787e/attachment.sig>

From peter at digitalbrains.com  Wed Jun 21 21:04:09 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 21 Jun 2017 21:04:09 +0200
Subject: TOFU
In-Reply-To: <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
Message-ID: <73cbee75-bb52-43c9-abf8-78740ddf8357@digitalbrains.com>

On 21/06/17 20:49, Peter Lebbing wrote:
> which would still
> be marginally safe until computers are much faster, and certainly not a
> short ID which is utterly unsafe and has always been.

Which *might* still be marginally safe. I haven't done any actual
calculations, and I want to seriously dissuade anyone from verifying
keys by their long key ID. Don't do it, kids! 64 bits can be brute
forced, but perhaps it might still be quite some effort to get a working
key with a colliding long ID.

I really should not have written it the way I did in the previous mail,
it was very sloppy.

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/20170621/c1b5b2e3/attachment-0001.sig>

From wk at gnupg.org  Wed Jun 21 21:02:31 2017
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jun 2017 21:02:31 +0200
Subject: speedo Error 2, download swdb.lst failed
In-Reply-To: <83c67bd7-eb36-ab76-8fc0-afe790f2ac07@digitalbrains.com> (Peter
 Lebbing's message of "Wed, 21 Jun 2017 19:11:43 +0200")
References: <fe2b2548-f33d-4f59-1cb6-8617b770cef6@gmail.com>
 <83c67bd7-eb36-ab76-8fc0-afe790f2ac07@digitalbrains.com>
Message-ID: <87mv91cgfs.fsf@wheatstone.g10code.de>

On Wed, 21 Jun 2017 19:11, peter at digitalbrains.com said:

> I think this is because of an expired certificate for versions.gnupg.org:

Sorry for this.  Fixed.


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/20170621/72e8e7c2/attachment.sig>

From tlikonen at iki.fi  Wed Jun 21 21:12:51 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Wed, 21 Jun 2017 22:12:51 +0300
Subject: Revoking a certificate (--edit-key + revsig)
In-Reply-To: <87y3slgqwb.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message
 of "Wed, 21 Jun 2017 14:03:00 -0400")
References: <87bmpobedd.fsf@mithlond.arda> <87y3slgqwb.fsf@fifthhorseman.net>
Message-ID: <87zid19mto.fsf@mithlond.arda>

Daniel Kahn Gillmor [2017-06-21 14:03:00-04] wrote:

> in the abstract:
>
>  * i learned via some channel i consider trustworthy that this key isn't
>    appropriate for use with this User ID any more.
>
> more concretely:
>
>  * "I had lunch with Sarah and she told me she'd lost access to her
>    secret key and didn't have a revocation certificate available."

> Does this make sense?

Sure, thanks. This is what I thought. In the past I revoked one of my
certificates because the key's owner no longer remembered the password
and essentially had lost control of the key. Back then I didn't think of
the semantics of revsig that much but it seemed the right thing to do.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170621/e9e513b4/attachment.sig>

From stefan.claas at posteo.de  Wed Jun 21 21:26:55 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Wed, 21 Jun 2017 21:26:55 +0200
Subject: TOFU
In-Reply-To: <73cbee75-bb52-43c9-abf8-78740ddf8357@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <73cbee75-bb52-43c9-abf8-78740ddf8357@digitalbrains.com>
Message-ID: <3wtF8S3nX4z10HR@submission01.posteo.de>

On Wed, 21 Jun 2017 21:04:09 +0200, Peter Lebbing wrote:
> On 21/06/17 20:49, Peter Lebbing wrote:
> > which would still
> > be marginally safe until computers are much faster, and certainly
> > not a short ID which is utterly unsafe and has always been.  
> 
> Which *might* still be marginally safe. I haven't done any actual
> calculations, and I want to seriously dissuade anyone from verifying
> keys by their long key ID. Don't do it, kids! 64 bits can be brute
> forced, but perhaps it might still be quite some effort to get a
> working key with a colliding long ID.
> 
> I really should not have written it the way I did in the previous
> mail, it was very sloppy.

What i have learned is that i use with my (online) friends a separate
list with their name and fingerprint on, have let TOFU checked the
first couple of messages and then give them full trust with TOFU.
Since i have those contacts only sometimes, i think it's a good
procedure comparing a Good Signature's fingerprint on my monitor
with one from a paper list. (a copy of the paper list is also hidden
in a another place)

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170621/92c5ff4d/attachment.sig>

From guru at unixarea.de  Thu Jun 22 08:28:57 2017
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 22 Jun 2017 08:28:57 +0200
Subject: about CCID USB readers (Re: setting GnuPG card to 'not forces' does
 not let sign)
In-Reply-To: <87wp8hh3qo.fsf@wheatstone.g10code.de>
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>
Message-ID: <20170622062857.GA2681@c720-r314251>

El d?a lunes, junio 12, 2017 a las 12:58:23p. m. +0200, Werner Koch escribi?:

> On Mon, 12 Jun 2017 12:38, guru at unixarea.de said:
> 
> > Do you know of any other CCID reader for ID-000 size cards?
> 
> I have a sample of the Gemalto Shell Token here.  It has been around for
> quite some time and the kernelconcept folks that it works nicely.  See
> 
>   https://www.floss-shop.de/en/security-privacy/
> 
> On that page you also find the a bit more expensive uTrust token which
> would be my preferred choice. I used it for many years until it broke due
> to my fault.  In fact I recycled the case for my gnuk token.

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.

I tested a lot with this issue and now have some trick which seems to
make it at least less often fail: I insert the uTrust token before
power-on, start the laptop but hold the boot in the moment when you can
modify certain boot options, i.e. the device is powered on but awaiting
a keyboard input to continue loading the kernel. Only a few seconds.
Then the booting kernel sees the device as:

ugen0.2: <Identiv uTrust 3512 SAM slot Token> at usbus0

Is there something in the cards firmware which needs some time to come
up?

	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/20170622/d934ee94/attachment.sig>

From tlikonen at iki.fi  Thu Jun 22 08:42:50 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Thu, 22 Jun 2017 09:42:50 +0300
Subject: Are TOFU statistics used for validity or conflict resolution?
Message-ID: <87bmpg1q1h.fsf@mithlond.arda>

Are TOFU statistics used for key's validity calculations or TOFU
conflict resolution?

Some background: The TOFU system keeps statistics about key's use. I'll
quote some lines from the DETAILS document.

About --with-colons --witt-tofu-info --list-keys:


    *** TFS - TOFU statistics

        This field may follows a UID record to convey information about
        the TOFU database.  The information is similar to a TOFU_STATS
        status line.

        - Field 2 :: tfs record version (must be 1)
        - Field 3 :: validity -  A number with validity code.
        - Field 4 :: signcount - The number of signatures seen.
        - Field 5 :: encrcount - The number of encryptions done.
        - Field 6 :: policy - A string with the policy
        - Field 7 :: signture-first-seen - a timestamp or 0 if not known.
        - Field 8 :: signature-most-recent-seen - a timestamp or 0 if not known.
        - Field 9 :: encryption-first-done - a timestamp or 0 if not known.
        - Field 10 :: encryption-most-recent-done - a timestamp or 0 if not known.


About --status-fd output's TOFU_STATS:


    *** TOFU_STATS <MANY_ARGS>

        Statistics for the current user id.

        The <MANY_ARGS> are the usual space delimited arguments.  Here we
        have too many of them to fit on one printed line and thus they are
        given on 3 printed lines:

        : <summary> <sign-count> <encryption-count>
        : [<policy> [<tm1> <tm2> <tm3> <tm4>
        : [<validity> [<sign-days> <encrypt-days>]]]]

        Values for SUMMARY are:
        - 0 :: attention, an interaction with the user is required (conflict)
        - 1 :: key with no verification/encryption history
        - 2 :: key with little history
        - 3 :: key with enough history for basic trust
        - 4 :: key with a lot of history


It _seems_ to me that 

    - Field 3 :: validity -  A number with validity code.

is the same thing as SUMMARY in TOFU_STATS. Am I right?

And here's my question again: Does the SUMMARY field's value (0-4) have
effect on how key's validity is calculated or how TOFU conflicts are
resolved or presented to a user?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170622/9072f00b/attachment.sig>

From madduck at madduck.net  Thu Jun 22 13:22:46 2017
From: madduck at madduck.net (martin f krafft)
Date: Thu, 22 Jun 2017 13:22:46 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <871sqdplzl.fsf@europa.jade-hamburg.de>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <871sqdplzl.fsf@europa.jade-hamburg.de>
Message-ID: <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>

Hey Justus, thanks for writing in. Here are the answers you wanted:

> gpg --version please?

2.1.18

> > So far, so good. Do note the [SC] usage flags.
> 
> What are the capabilities of your primary key supposed to be?

There were [SC] when I created it, but I've recently changed to
a signing subkey and removed the flag from the primary key.

> >   key 55C9882D999BBCC4:
> >   24 duplicate signatures removed
> >
> > That's a bit weird. Where do these come from?
> 
> Not sure, but anyone can append stuff to your key on the keyservers.
> Maybe some faulty software reordered the packages and uploaded it?

Yeah could be. And while there's no way this can be fixed, it also
doesn't really harm, does it?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"getting a scsi chain working is perfectly simple if you remember that
 there must be exactly three terminations: one on one end of the
 cable, one on the far end, and the goat, terminated over the scsi
 chain with a silver-handled knife whilst burning *black* candles."
                                                     -- anthony deboer
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/27171a20/attachment.sig>

From madduck at madduck.net  Thu Jun 22 15:00:52 2017
From: madduck at madduck.net (martin f krafft)
Date: Thu, 22 Jun 2017 15:00:52 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <87k2451rfl.wl-neal@walfield.org>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
Message-ID: <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>

also sprach Neal H. Walfield <neal at walfield.org> [2017-06-21 14:00 +0200]:
> It starts with the set of ultimately trusted keys.  But let's say
> that you start with key X, which is not ultimately trusted.  What
> should GnuPG do with the result?  Or, let's say that X is
> ultimately trusted and it decides that key Y is only marginally
> trusted, but Y would have been fully trusted if you started with
> all ultimately trusted keys. How do you intelligently merge that?

As far as I understand, the parameters --marginals-needed and
--completes-needed can be used to define a maximum search depth D,
so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
envision it to

  1. enumerate all keys reachable within D steps

  2. iterate all these keys

  3. backpropagate the trust/validity level towards 0xdeadbeef

  4. update the nodes touched by this walk in trustdb

  5. do this for every key when it changes

  6. do this for every key upon use, such that missing information
     can be interactively provided, and expired keys pruned
     just-in-time.

  7. --check-trustdb could still be used to do overall cleaning at
     regular intervals.

Given how the keygraph is essentially a singly-linked graph with
keys containing pointers to other keys that signed them, while there
exists no such information implicitly about all the keys that have
been signed *by* a given key (e.g. one that's ultimately trusted),
the approach I've sketched actually seems more intuitive, don't you
think?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"here i was all convinced that if i sleep all day, bug counts go
 down, and if I work all day, they go up, so much for that theory."
                                                   -- lars wirzenius
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/9c385875/attachment-0001.sig>

From tlikonen at iki.fi  Thu Jun 22 15:30:27 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Thu, 22 Jun 2017 16:30:27 +0300
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <87y3slo59f.fsf@europa.jade-hamburg.de> (Justus Winter's message
 of "Wed, 21 Jun 2017 15:10:52 +0200")
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <87y3slo59f.fsf@europa.jade-hamburg.de>
Message-ID: <87wp849mks.fsf@mithlond.arda>

Justus Winter [2017-06-21 15:10:52+02] wrote:

> martin f krafft <madduck at madduck.net> writes:
>>     x-hkp://pool.sks-keyservers.net
>
> Here  ^ is the keyserver url.

>>   gpg> save
>>   Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: Preferred keyserver: %
>
> And these are the labels for these urls.  This was a cosmetic problem
> that I just fixed.

There is similar cosmetic problem with --update-trustdb:

    [...]
    No trust value assigned to:
    pub   rsa4096 XXXX-XX-XX [SC]
          [...]
     Primary key fingerprint: [...]

    Please decide how far you trust this user to correctly verify other
    users' keys (by looking at passports, checking fingerprints from
    different sources, etc.)

      1 = I don't know or won't say
      2 = I do NOT trust
      3 = I trust marginally
      4 = I trust fully
      s = skip this key
      q = quit

    Your decision? 4
    gpg: depth: 4  valid:  17  signed:  13  trust: 0-, 0q, 0n, 3m, 14f, 0u
    gpg: next trustdb check due at 2017-09-09

And when the whole session is over gpg prints fingerprints of _all_ keys
that got their ownertrust updated.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170622/75ec50dc/attachment.sig>

From madduck at madduck.net  Thu Jun 22 15:34:59 2017
From: madduck at madduck.net (martin f krafft)
Date: Thu, 22 Jun 2017 15:34:59 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <a9b0d3e3-9c4b-0e33-ec7a-6b7768d23da7@andrewg.com>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <a9b0d3e3-9c4b-0e33-ec7a-6b7768d23da7@andrewg.com>
Message-ID: <20170622133459.nulpbic7lulfhth6@albatross.lehel.madduck.net>

also sprach Andrew Gallagher <andrewg at andrewg.com> [2017-06-21 15:57 +0200]:
> I have a quick and dirty tool here:
> https://github.com/andrewgdotcom/synctrust

Yeah, that'll do the job, except it blindly overwrites changes made
locally. It's unlikely this happens, but say I declared your key
trustworthy last night at home, forgot to run sync, and
not-trustworthy this morning at the office (sorry, this is just
a silly example?), and then ran sync, your key would be trustworthy
again.

On the other hand, it'd be totally possible to export ownertrust
prior to the import, and then fire up vimdiff or the like on the two
versions. Not exactly a great UID at all.

It'd be better if trustdb would be journalled using a mergeable
approach.

And then again, something like jetring is far beyond overkill for
day-to-day usage?

#SyncIsHard

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"convictions are more dangerous enemies of truth than lies."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/fb72fdd1/attachment.sig>

From peter at digitalbrains.com  Thu Jun 22 15:46:43 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 22 Jun 2017 15:46:43 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
Message-ID: <176e12ef-d5db-d596-f4a3-5eda19e0be8e@digitalbrains.com>

On 22/06/17 15:00, martin f krafft wrote:
> As far as I understand, the parameters --marginals-needed and
> --completes-needed can be used to define a maximum search depth D,
> so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> envision it to

Don't you mean

>        --max-cert-depth n
>               Maximum depth of a certification chain (default is 5).

? I don't see how --*-needed would limit the search depth, other than
that for an actual keyset increasing them would effectively probably
decrease the actual depth.

While in general there are probably many avenues to be more efficient
about --check-trustdb, introducing too much complexity raises the
likelihood of bugs, especially if you start to intelligently update
trust by partial traversal.

Perhaps it would already be enough to split it into three phases:

1) Consider every key signature potentially valid. Construct the graph
of signatures. Discard anything that is not rooted in an ultimately
trusted key.

2) Still assuming correctness of key signatures, now consider
ownertrust. Remove any key that clearly does not have enough trust from
further computations (but leave in place all edges in the graph of the
remaining keys).

3) Start at the ultimately trusted keys and consider each signature that
corresponds to an edge going out of a valid key. Check signatures until
full validity of a key is reached (or all signatures on a key have been
checked). Stop checking then; it can't become more than fully valid by
more signatures. The fact that a key has been added to the valid keys
means you now have more edges going out from a valid key; keep repeating.

When a key fails to become valid in 3), you could consider the criteria
of 2) again and prune some keys from the graph, but it might be
over-optimizing. Without it it might already be plenty quick.

I don't know what the current algorithm is, but given its runtime, I'm
thinking it might be "check all signatures that can be checked" followed
by "now propagate validity through ownertrust". In my sketched proposal,
a *lot* of signatures would probably remain unchecked because they can't
further affect the validity of a key.

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/20170622/7519260e/attachment.sig>

From madduck at madduck.net  Thu Jun 22 16:06:03 2017
From: madduck at madduck.net (martin f krafft)
Date: Thu, 22 Jun 2017 16:06:03 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <176e12ef-d5db-d596-f4a3-5eda19e0be8e@digitalbrains.com>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <176e12ef-d5db-d596-f4a3-5eda19e0be8e@digitalbrains.com>
Message-ID: <20170622140603.qdbudgsal2yabh4w@albatross.lehel.madduck.net>

also sprach Peter Lebbing <peter at digitalbrains.com> [2017-06-22 15:46 +0200]:
> > As far as I understand, the parameters --marginals-needed and
> > --completes-needed can be used to define a maximum search depth D,
> > so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> > envision it to
> 
> Don't you mean
> 
> >        --max-cert-depth n
> >               Maximum depth of a certification chain (default is 5).
> 
> ? I don't see how --*-needed would limit the search depth, other than
> that for an actual keyset increasing them would effectively probably
> decrease the actual depth.

Yeah, that too.

> 1) Consider every key signature potentially valid. Construct the
>    graph of signatures. Discard anything that is not rooted in an
>    ultimately trusted key.

That sounds like a worthwhile optimisation, indeed.

> 3) Start at the ultimately trusted keys and consider each signature that
> corresponds to an edge going out of a valid key. Check signatures until
> full validity of a key is reached (or all signatures on a key have been
> checked). Stop checking then; it can't become more than fully valid by
> more signatures. The fact that a key has been added to the valid keys
> means you now have more edges going out from a valid key; keep repeating.

And so does this?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"durch frauen werden die h?hepunkte des lebens bereichert
 und die tiefpunkte vermehrt."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/0818f209/attachment.sig>

From neal at walfield.org  Thu Jun 22 16:15:46 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 22 Jun 2017 16:15:46 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
Message-ID: <877f04152l.wl-neal@walfield.org>

Hi,

I didn't say that it is not possible to have a better algorithm.  It
is possible.  But, it is not as easy as you suggest (and what you
suggest doesn't sound trivial).

For instance, adding or updating a key doesn't necessarily result in
equal or more trust.  An update could cause a key to be revoked.  In
that case, if 0xdeadbeef is marginally trusted, we now need to
identify keys that were considered valid because of 0xdeadbeef, but no
longer are.

:) Neal

At Thu, 22 Jun 2017 15:00:52 +0200,
martin f krafft wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> also sprach Neal H. Walfield <neal at walfield.org> [2017-06-21 14:00 +0200]:
> > It starts with the set of ultimately trusted keys.  But let's say
> > that you start with key X, which is not ultimately trusted.  What
> > should GnuPG do with the result?  Or, let's say that X is
> > ultimately trusted and it decides that key Y is only marginally
> > trusted, but Y would have been fully trusted if you started with
> > all ultimately trusted keys. How do you intelligently merge that?
> 
> As far as I understand, the parameters --marginals-needed and
> --completes-needed can be used to define a maximum search depth D,
> so when I ask GPG to update the trustdb WRT key 0xdeadbeef, then I'd
> envision it to
> 
>   1. enumerate all keys reachable within D steps
> 
>   2. iterate all these keys
> 
>   3. backpropagate the trust/validity level towards 0xdeadbeef
> 
>   4. update the nodes touched by this walk in trustdb
> 
>   5. do this for every key when it changes
> 
>   6. do this for every key upon use, such that missing information
>      can be interactively provided, and expired keys pruned
>      just-in-time.
> 
>   7. --check-trustdb could still be used to do overall cleaning at
>      regular intervals.
> 
> Given how the keygraph is essentially a singly-linked graph with
> keys containing pointers to other keys that signed them, while there
> exists no such information implicitly about all the keys that have
> been signed *by* a given key (e.g. one that's ultimately trusted),
> the approach I've sketched actually seems more intuitive, don't you
> think?
> 
> -- 
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/
>  
> "here i was all convinced that if i sleep all day, bug counts go
>  down, and if I work all day, they go up, so much for that theory."
>                                                    -- lars wirzenius
>  
> spamtraps: madduck.bogus at madduck.net
> [2 Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) <application/pgp-signature (7bit)>]
> No public key for 9C9D6979AE941637 created at 2017-06-22T15:00:47+0200 using RSA


From madduck at madduck.net  Thu Jun 22 16:29:30 2017
From: madduck at madduck.net (martin f krafft)
Date: Thu, 22 Jun 2017 16:29:30 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <877f04152l.wl-neal@walfield.org>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
Message-ID: <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>

also sprach Neal H. Walfield <neal at walfield.org> [2017-06-22 16:15 +0200]:
> I didn't say that it is not possible to have a better algorithm.  It
> is possible.  But, it is not as easy as you suggest (and what you
> suggest doesn't sound trivial).
> 
> For instance, adding or updating a key doesn't necessarily result in
> equal or more trust.  An update could cause a key to be revoked.  In
> that case, if 0xdeadbeef is marginally trusted, we now need to
> identify keys that were considered valid because of 0xdeadbeef, but no
> longer are.

This would be handled upon use of such keys. In fact, rather than
updating the trustdb on update of key material, wouldn't it make
much more sense to compute the information just-in-time? Provided
we'd have a data format allowing for fast access like this?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"the scientific paper in its orthodox form does embody a totally
 mistaken conception, even a travesty, of the nature of scientific
 thought."
                                                -- sir peter medawar
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170622/20b73a5c/attachment-0001.sig>

From justus at g10code.com  Thu Jun 22 17:00:03 2017
From: justus at g10code.com (Justus Winter)
Date: Thu, 22 Jun 2017 17:00:03 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <871sqdplzl.fsf@europa.jade-hamburg.de>
 <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
Message-ID: <87wp84jcek.fsf@thinkbox.jade-hamburg.de>

martin f krafft <madduck at madduck.net> writes:

> [ Unknown signature status ]
> Hey Justus, thanks for writing in. Here are the answers you wanted:
>
>> gpg --version please?
>
> 2.1.18
>
>> > So far, so good. Do note the [SC] usage flags.
>> 
>> What are the capabilities of your primary key supposed to be?
>
> There were [SC] when I created it, but I've recently changed to
> a signing subkey and removed the flag from the primary key.

Interesting.  Thanks for clarifying.

>> >   key 55C9882D999BBCC4:
>> >   24 duplicate signatures removed
>> >
>> > That's a bit weird. Where do these come from?
>> 
>> Not sure, but anyone can append stuff to your key on the keyservers.
>> Maybe some faulty software reordered the packages and uploaded it?
>
> Yeah could be. And while there's no way this can be fixed, it also
> doesn't really harm, does it?

No, it does (should) not harm.  Future versions of GnuPG will check and
clean keys automatically when (re-)fetching them from keyservers.

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/20170622/0db111b8/attachment.sig>

From wk at gnupg.org  Thu Jun 22 19:02:11 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 22 Jun 2017 19:02:11 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 (martin f. krafft's message of "Thu, 22 Jun 2017 16:29:30 +0200")
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
Message-ID: <87podwarcc.fsf@wheatstone.g10code.de>

On Thu, 22 Jun 2017 16:29, madduck at madduck.net said:

> updating the trustdb on update of key material, wouldn't it make
> much more sense to compute the information just-in-time? Provided

For a key listing this means computing it for every listed key.  And the
majority of frontends first do a key listing and show the validity of
the keys before you can encrypt something.

BTW, the algorithm posted here looked much like classic PGP without all
the extra steps necessary for the PGP 6 variant of the WoT we implement.
(I have not fully followed the thread, 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/20170622/f71cacfc/attachment.sig>

From tlikonen at iki.fi  Thu Jun 22 19:32:48 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Thu, 22 Jun 2017 20:32:48 +0300
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87bmpg1q1h.fsf@mithlond.arda> (Teemu Likonen's message of "Thu, 
 22 Jun 2017 09:42:50 +0300")
References: <87bmpg1q1h.fsf@mithlond.arda>
Message-ID: <87shis9bcv.fsf@mithlond.arda>

Teemu Likonen [2017-06-22 09:42:50+03] wrote:

> Does the SUMMARY field's value (0-4) have effect on how key's validity
> is calculated or how TOFU conflicts are resolved or presented to a
> user?

I didn't get answers yet but I'll speculate a bit on the subject. This
is all about "trust-model tofu" and assume that I have _not_ set
"--tofu-policy" manually.

Let's say that I have a key which has been used to verify a couple of
signatures. Then there comes another key with conflicting email address.
It seems that tofu goes to "ask" mode for _both_ keys (user ids). User
needs to decide and set the tofu policy for both.

Then let's say I have a key which has been used to verify hundred or so
signatures. In --status-fd's TOFU_STATS <summary> it gets higher value,
say 4. Then the keyring gets a new key with conflicting email address.
Does gpg again set both keys (user ids) to tofu's "ask" mode or does
this higher number of good verifications automatically keep the first
key in "auto" mode and only the new key is set to "ask" mode?

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170622/e08790bf/attachment.sig>

From neal at walfield.org  Thu Jun 22 20:31:41 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Thu, 22 Jun 2017 20:31:41 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87bmpg1q1h.fsf@mithlond.arda>
References: <87bmpg1q1h.fsf@mithlond.arda>
Message-ID: <874lv727si.wl-neal@walfield.org>

At Thu, 22 Jun 2017 09:42:50 +0300,
Teemu Likonen wrote:
> It _seems_ to me that 
> 
>     - Field 3 :: validity -  A number with validity code.
> 
> is the same thing as SUMMARY in TOFU_STATS. Am I right?
> 
> And here's my question again: Does the SUMMARY field's value (0-4) have
> effect on how key's validity is calculated or how TOFU conflicts are
> resolved or presented to a user?

TOFU influences validity.

By default, all known keys are marginally trusted in the TOFU model.
(This is more or less the "first use" bit of "trust on first use".)
In TOFU, the validity of a key is set to unknown if there is an
unresolved conflict.  The user can resolve a conflict either
positively (in which case the validity is full) or negatively (in
which case the validity is never).  Note: this means that it is
possible to make negative assertions when using TOFU, which is not
possible when using WoT.

The summary field in TOFU_STATS is a summary of the key's use.  The
basic idea is that in the absence of facts to the contrary, at the
limit (an infinite number of uses), a given key must have been the
right one (or is indistinguishable from the correct key, which is just
as good, because it means that nothing bad ever happened).  In other
words, a key that has been used for years is more likely to be the
correct one, then one that I've only used once.  In the former case,
I've had many more opportunities to detect a MitM attack.  The summary
field captures this using a simple scale that applications can then
somehow display to the user.  This is currently used by kmail and the
Outlook plug-in.

HTH,

:) Neal


From 2014-667rhzu3dc-lists-groups at riseup.net  Fri Jun 23 00:33:24 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 22 Jun 2017 23:33:24 +0100
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net> 
 <871sqdplzl.fsf@europa.jade-hamburg.de>
 <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
Message-ID: <943123696.20170622233324@riseup.net>

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



On Thursday 22 June 2017 at 12:22:46 PM, in
<mid:20170622112246.arbty4jkgcubelwf at albatross.lehel.madduck.net>,
martin f krafft wrote:-


> There were [SC] when I created it, but I've recently
> changed to
> a signing subkey and removed the flag from the
> primary key.

I didn't know you could remove a usage flag once the key was on the
keyservers. And I thought GnuPG would automatically sign with a valid
signing subkey if there was one.


- --
Best regards

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

INFLATION: Cutting money in half without damaging the paper.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWUxFtV8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5JFNAP0evo6Ziei4r/zDdVrIhCrZZkxFWvM316G41D4aDTiG4AEAlLS+jHSLczWO
U1blAUeOJgOu0GY0GPIrdRwGS6zF1gaJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWUxFw18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8NLGB/sHjV7fL4g8noTDAXxcYbCyfYAX
NJkdUdouonQYqvMR7Ax8AA2EPWbnt9AKb/GgLUlEG8dz44WwxzXeP2aShGu8VVW7
NX9EenA03pUp1DS6Xj3hj8GOQ6nPr6Wswn0e2pHnMUhRGvGwZXav6yu/Q074OIK3
CEAPwkSEmokYvNfwpSMfLbmKgTCf4Ty3Zmqa96huUnmukrBvgmd+v5UTANVVG9n6
jL8iD+JmsCrW+BZ2u6VR9mPU3hvyps91O/bktH96wSfRRWNTMD3UCXcKloK7K42Z
2ezwosg2DXwWTfEgwOFxkLXXAPpW5NhMEYiQtZlKtb8k09bzXBJN/8nqd+Tp
=aY7r
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Fri Jun 23 03:07:19 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Fri, 23 Jun 2017 02:07:19 +0100
Subject: TOFU
In-Reply-To: <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de> 
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
Message-ID: <1873229282.20170623020719@riseup.net>

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



On Wednesday 21 June 2017 at 7:49:42 PM, in
<mid:ffb9b23c-b01b-44d0-3a75-6e5e474de196 at digitalbrains.com>, Peter
Lebbing wrote:-

> I think it's a bad UX choice to
> name an invalid
> signature "UNTRUSTED Good" and a valid signature
> "Good". I think it
> suggests they both have some credibility, which is a
> false suggestion.

I thought "good signature" just meant the message has not been
altered in transit.

- --
Best regards

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

Experience is the name everyone gives to their mistakes
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWUxpyF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5HqLAP9+B3S80DDB9qpejz6V+MsFUOKZsUmNsRSLp8B8CNoenAEAsQn5DpDH0HSP
AE0qqxmrA988lDiWQsMoHHXL6cUSCQuJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWUxp2F8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8A/FB/sFVMYxnxp7eUhnXkRy1SKrdL2t
k74kp8a1Qg800q9acoa33HyaD4oz/W1XAN3e//rAH8DQYiiUSBHFlagyolI+5Hbs
invOu6VdGm8MNL7KDV7Qg7AtbqGd451Gyo8QzoDX6FpIY421E2iIq2xi+kZ/co4M
kO7oMJ57dy+RAr80k/my9StSIHvXlzwQ0fhY6/x96Pa0BWA5dfq6zUYcywejK8R2
VmDeN+sQ2Q3dcrixmZm76L743q1zx+5YV+oceGhv+O8LfWzGpGBMamo2+vCRtzDV
Gz8ZHpXKk5VUIAi3DOosVTfS6ZEx6I6o2dPcP2zAnVqGJ8MPEffRLKkC+C16
=7Vky
-----END PGP SIGNATURE-----



From madduck at madduck.net  Fri Jun 23 06:55:15 2017
From: madduck at madduck.net (martin f krafft)
Date: Fri, 23 Jun 2017 06:55:15 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <943123696.20170622233324@riseup.net>
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <871sqdplzl.fsf@europa.jade-hamburg.de>
 <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
 <943123696.20170622233324@riseup.net>
Message-ID: <20170623045515.wxkyyioyabtqkerv@fishbowl.rw.madduck.net>

also sprach MFPA <2014-667rhzu3dc-lists-groups at riseup.net> [2017-06-23 00:33 +0200]:
> I didn't know you could remove a usage flag once the key was on the
> keyservers.

Well, it somehow seems to work, apart from the fact that gnupg first
needs to clean up the key (using --edit-key) after downloading the
modified version from the keyservers.

> And I thought GnuPG would automatically sign with a valid signing
> subkey if there was one.

It does this independently, yes.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
                                                       -- mark twain
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170623/3be5eecc/attachment-0001.sig>

From wk at gnupg.org  Fri Jun 23 09:40:04 2017
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Jun 2017 09:40:04 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <943123696.20170622233324@riseup.net> (MFPA's message of "Thu, 22
 Jun 2017 23:33:24 +0100")
References: <20170621090340.2v3hksu3eshtow2d@albatross.lehel.madduck.net>
 <871sqdplzl.fsf@europa.jade-hamburg.de>
 <20170622112246.arbty4jkgcubelwf@albatross.lehel.madduck.net>
 <943123696.20170622233324@riseup.net>
Message-ID: <87tw379mp7.fsf@wheatstone.g10code.de>

On Fri, 23 Jun 2017 00:33, 2014-667rhzu3dc-lists-groups at riseup.net said:

> I didn't know you could remove a usage flag once the key was on the

Those flags are tracked in self-signatures.  When changing a flag a new
self-signature is used.  This will be uploaded to the keyserver.  gpg
uses the flags from the latest self-signature it has.

Note that revocations are also self-signatures (using a different class
and not "flags", 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/20170623/e22fe81b/attachment.sig>

From madduck at madduck.net  Fri Jun 23 10:02:44 2017
From: madduck at madduck.net (martin f krafft)
Date: Fri, 23 Jun 2017 10:02:44 +0200
Subject: Key corruption: duplicate signatures and usage flags
In-Reply-To: <87tw379mp7.fsf@wheatstone.g10code.de>
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>
Message-ID: <20170623080244.p75yzi4pw4x7gioz@albatross.lehel.madduck.net>

also sprach Werner Koch <wk at gnupg.org> [2017-06-23 09:40 +0200]:
> Those flags are tracked in self-signatures.  When changing a flag
> a new self-signature is used.  This will be uploaded to the
> keyserver.  gpg uses the flags from the latest self-signature it
> has.

So how does this explain

  % export GNUPGHOME=$(mktemp -d)
  % gpg --recv-key 55C9882D999BBCC4
  % gpg --list-key 55C9882D999BBCC4 | grep '^pub'   # [SC]
  % gpg --edit-key 55C9882D999BBCC4 save
  % gpg --list-key 55C9882D999BBCC4 | grep '^pub'   # [C]

Are you saying that gnupg 2.1.18 added the self-signature in the
wrong place?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i wish i hadn't slept all day, it's really lowered my productivity"
                                                   -- robert mcqueen
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170623/e2771661/attachment.sig>

From neal at walfield.org  Fri Jun 23 11:14:31 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 23 Jun 2017 11:14:31 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87shis9bcv.fsf@mithlond.arda>
References: <87bmpg1q1h.fsf@mithlond.arda>
	<87shis9bcv.fsf@mithlond.arda>
Message-ID: <87ziczysjs.wl-neal@walfield.org>

At Thu, 22 Jun 2017 20:32:48 +0300,
Teemu Likonen wrote:
> Teemu Likonen [2017-06-22 09:42:50+03] wrote:
> > Does the SUMMARY field's value (0-4) have effect on how key's validity
> > is calculated or how TOFU conflicts are resolved or presented to a
> > user?
> 
> I didn't get answers yet but I'll speculate a bit on the subject. This
> is all about "trust-model tofu" and assume that I have _not_ set
> "--tofu-policy" manually.
> 
> Let's say that I have a key which has been used to verify a couple of
> signatures. Then there comes another key with conflicting email address.
> It seems that tofu goes to "ask" mode for _both_ keys (user ids). User
> needs to decide and set the tofu policy for both.

Correct.

> Then let's say I have a key which has been used to verify hundred or so
> signatures. In --status-fd's TOFU_STATS <summary> it gets higher value,
> say 4. Then the keyring gets a new key with conflicting email address.
> Does gpg again set both keys (user ids) to tofu's "ask" mode or does
> this higher number of good verifications automatically keep the first
> key in "auto" mode and only the new key is set to "ask" mode?

No, both keys are set to ask.  The key with a lot of observed
signatures could be bad.  This could occur, if there is a MitM, but
the MitM has a small lapse, because, perhaps, you've used an
unintercepted network path to retreive the "new" signature & key.


From andrewg at andrewg.com  Fri Jun 23 11:49:38 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 23 Jun 2017 10:49:38 +0100
Subject: Managing the WoT with GPG
In-Reply-To: <20170622133459.nulpbic7lulfhth6@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <a9b0d3e3-9c4b-0e33-ec7a-6b7768d23da7@andrewg.com>
 <20170622133459.nulpbic7lulfhth6@albatross.lehel.madduck.net>
Message-ID: <15cc8b8e-8055-a82c-9ba9-3af1e6f5c1cc@andrewg.com>

On 2017/06/22 14:34, martin f krafft wrote:
> also sprach Andrew Gallagher <andrewg at andrewg.com> [2017-06-21 15:57 +0200]:
>> I have a quick and dirty tool here:
>> https://github.com/andrewgdotcom/synctrust
> 
> Yeah, that'll do the job, except it blindly overwrites changes made
> locally. It's unlikely this happens, but say I declared your key
> trustworthy last night at home, forgot to run sync, and
> not-trustworthy this morning at the office (sorry, this is just
> a silly example?), and then ran sync, your key would be trustworthy
> again.

Yes, this is a limitation. I did say it was dirty. ;-)

> On the other hand, it'd be totally possible to export ownertrust
> prior to the import, and then fire up vimdiff or the like on the two
> versions. Not exactly a great UID at all.

Not the raw diff, no. But it might be possible to run a diff on the
ownertrusts, ignore any "normal" changes (e.g. where the old/local trust
state was "unknown") and present the user with a list of potentially
dangerous conflicts, such as your unlikely scenario above.

> It'd be better if trustdb would be journalled using a mergeable
> approach.

Trust signatures could trivially implement this, iff it were possible to
ltsign a key without also certifying it. (Feature request?)

> #SyncIsHard

Amen.

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/20170623/1157bd60/attachment.sig>

From andrewg at andrewg.com  Fri Jun 23 12:33:21 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 23 Jun 2017 11:33:21 +0100
Subject: Using gpg for ssh (Maximum Portability)
In-Reply-To: <b3ed4af3-7bfc-f6e0-8b12-f63e64bd894a@digitalbrains.com>
References: <CADJBR=CpapYtoszWR2oNFqxpjRFXmsrYuVyLeYvxxhWqr12ccQ@mail.gmail.com>
 <b3ed4af3-7bfc-f6e0-8b12-f63e64bd894a@digitalbrains.com>
Message-ID: <a07577f9-f00a-8f3c-f53f-9d14ae4b3a0d@andrewg.com>

On 2017/06/21 18:17, Peter Lebbing wrote:
> On 18/06/17 03:48, Christopher Jones wrote:
>> It's a task to setup gpg on new boxes: Import pub key, ultimately trust
>> my key, and muck around with gpg and ssh agents.
> 
> Configuring gpg as an SSH agent for Linux in the easiest way is very,
> very distribution dependent. If you're lucky, it's a single switch
> somewhere. systemd, or Xsession, or something similar
For any linux distro that provides a recent gnupg 2.1, the easiest way
(not necessarily the Proper Way) is to put the following in your ~/.profile:

----
if [ -z "$SSH_CLIENT" ]; then
	export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh
	export GPG_AGENT_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent
	gpg-connect-agent /bye
fi
----

$XDG_RUNTIME_DIR normally expands to /run/user/<UID>. For v2.0, the
default socket location is under ~/.gnupg, but otherwise the trick is
the same. Note the vital <if> statement that prefers a forwarded
ssh-agent over a local gpg-agent.

This avoids having to mess around with distro/gui-specific session
configurations, and also has the advantage that you can cut and paste it
onto the command line of a logged-in system. There is no need to disable
the vanilla ssh-agent - just override $SSH_AUTH_SOCK and nothing will
talk to it.

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/20170623/b43d9a9e/attachment.sig>

From tlikonen at iki.fi  Fri Jun 23 12:45:39 2017
From: tlikonen at iki.fi (Teemu Likonen)
Date: Fri, 23 Jun 2017 13:45:39 +0300
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87ziczysjs.wl-neal@walfield.org> (Neal H. Walfield's message of
 "Fri, 23 Jun 2017 11:14:31 +0200")
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org>
Message-ID: <87efubkmng.fsf@mithlond.arda>

Neal H. Walfield [2017-06-23 11:14:31+02] wrote:

> At Thu, 22 Jun 2017 20:32:48 +0300, Teemu Likonen wrote:
>> Then let's say I have a key which has been used to verify hundred or
>> so signatures. In --status-fd's TOFU_STATS <summary> it gets higher
>> value, say 4. Then the keyring gets a new key with conflicting email
>> address. Does gpg again set both keys (user ids) to tofu's "ask" mode
>> or does this higher number of good verifications automatically keep
>> the first key in "auto" mode and only the new key is set to "ask"
>> mode?
>
> No, both keys are set to ask. The key with a lot of observed
> signatures could be bad. This could occur, if there is a MitM, but the
> MitM has a small lapse, because, perhaps, you've used an unintercepted
> network path to retreive the "new" signature & key.

Thanks. So here's how my thinking has been as a tofu newbie.

 1. I assumed that the first key with particular email address would be
    automatically valid forever. Only new keys would go to "ask" mode on
    conflicts. That was my interpretation of "trust of first use". Well,
    I was wrong.

 2. New hypothesis: There needs to be enough history on verifying or
    encryption before the key is assumed automatically valid on
    conflicts. Then only new keys would go to "ask" mode on conflicts. I
    was wrong again.

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:


       --trust-model pgp|classic|tofu|tofu+pgp|direct|always|auto

              [...]

              tofu

                     TOFU stands for Trust On First Use. In this trust
                     model, the first time a key is seen, it is
                     memorized. If later another key is seen with a user
                     id with the same email address, a warning is
                     displayed indicating that there is a conflict and
                     that the key might be a forgery and an attempt at a
                     man-in-the-middle attack.


From that part I got the idea of getting warning only from new
conflicting keys. The first one would be trusted. The man page doesn't
say so but it was my interpretation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170623/02886567/attachment-0001.sig>

From peter at digitalbrains.com  Fri Jun 23 12:52:48 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 23 Jun 2017 12:52:48 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87ziczysjs.wl-neal@walfield.org>
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org>
Message-ID: <4679d4c1-4f17-5d06-23aa-16eec262fdf0@digitalbrains.com>

On 23/06/17 11:14, Neal H. Walfield wrote:
> No, both keys are set to ask.  The key with a lot of observed
> signatures could be bad.  This could occur, if there is a MitM, but
> the MitM has a small lapse, because, perhaps, you've used an
> unintercepted network path to retreive the "new" signature & key.

So if I understand correctly, the "summary"/"validity" field merely
affects the text that is displayed to the user when displaying TOFU
statistics?

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/20170623/939d0725/attachment.sig>

From neal at walfield.org  Fri Jun 23 12:56:09 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 23 Jun 2017 12:56:09 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <4679d4c1-4f17-5d06-23aa-16eec262fdf0@digitalbrains.com>
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org>
 <4679d4c1-4f17-5d06-23aa-16eec262fdf0@digitalbrains.com>
Message-ID: <87y3sjynue.wl-neal@walfield.org>

At Fri, 23 Jun 2017 12:52:48 +0200,
Peter Lebbing wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> On 23/06/17 11:14, Neal H. Walfield wrote:
> > No, both keys are set to ask.  The key with a lot of observed
> > signatures could be bad.  This could occur, if there is a MitM, but
> > the MitM has a small lapse, because, perhaps, you've used an
> > unintercepted network path to retreive the "new" signature & key.
> 
> So if I understand correctly, the "summary"/"validity" field merely
> affects the text that is displayed to the user when displaying TOFU
> statistics?

It's up to the GPG client to interpret it.  This document (authored by
Andre and me) has some recommendations for MUAs:

  https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption

:) Neal


From peter at digitalbrains.com  Fri Jun 23 13:22:23 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 23 Jun 2017 13:22:23 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <87y3sjynue.wl-neal@walfield.org>
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org>
 <4679d4c1-4f17-5d06-23aa-16eec262fdf0@digitalbrains.com>
 <87y3sjynue.wl-neal@walfield.org>
Message-ID: <ac39efa4-13a7-6a88-92df-b96ec6605dd2@digitalbrains.com>

On 23/06/17 12:56, Neal H. Walfield wrote:
> It's up to the GPG client to interpret it.  This document (authored by
> Andre and me) has some recommendations for MUAs:

Ah! Thanks for the information.

I was thinking about how GnuPG handled it, i.e., on the gpg command line
or as a backend for some frontend. I got the impression the "validity"
field affected the text of the gpg command line but nothing else
(g10/tofu.c:show_statistics() returns "show_warning" asserted for
valdities below 3).

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/20170623/7926b510/attachment.sig>

From neal at walfield.org  Fri Jun 23 13:25:31 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 23 Jun 2017 13:25:31 +0200
Subject: Are TOFU statistics used for validity or conflict resolution?
In-Reply-To: <ac39efa4-13a7-6a88-92df-b96ec6605dd2@digitalbrains.com>
References: <87bmpg1q1h.fsf@mithlond.arda> <87shis9bcv.fsf@mithlond.arda>
 <87ziczysjs.wl-neal@walfield.org>
 <4679d4c1-4f17-5d06-23aa-16eec262fdf0@digitalbrains.com>
 <87y3sjynue.wl-neal@walfield.org>
 <ac39efa4-13a7-6a88-92df-b96ec6605dd2@digitalbrains.com>
Message-ID: <87vannymhg.wl-neal@walfield.org>

At Fri, 23 Jun 2017 13:22:23 +0200,
Peter Lebbing wrote:
> On 23/06/17 12:56, Neal H. Walfield wrote:
> > It's up to the GPG client to interpret it.  This document (authored by
> > Andre and me) has some recommendations for MUAs:
> 
> Ah! Thanks for the information.
> 
> I was thinking about how GnuPG handled it, i.e., on the gpg command line
> or as a backend for some frontend. I got the impression the "validity"
> field affected the text of the gpg command line but nothing else
> (g10/tofu.c:show_statistics() returns "show_warning" asserted for
> valdities below 3).

You're right: gpg also uses this information to display some
information.


From peter at digitalbrains.com  Fri Jun 23 13:49:28 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 23 Jun 2017 13:49:28 +0200
Subject: TOFU
In-Reply-To: <1873229282.20170623020719@riseup.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
Message-ID: <2460ac1a-55f7-79d9-af02-e6b1bde30394@digitalbrains.com>

On 23/06/17 03:07, MFPA wrote:
> I thought "good signature" just meant the message has not been
> altered in transit.

That's very well possible. In that case there is no verbal indication of
a valid signature, only a colour. The text I see for a signature by a
fully valid key is:

Good signature from First Name Last Name <mail at example.org>
Key ID: 0xXXXXXXXX / Signed 0n: DD/MM/YY HH:MM

And this is with a green background. There is no verbal indication that
the signing key is valid, unlike the version with the blue background,
where the text is:

UNTRUSTED Good signature from First Name Last Name <mail at example.org>
Key ID: 0xXXXXXXXX / Signed 0n: DD/MM/YY HH:MM

So this does verbally indicate invalidity.


Anyway, apart from what the developers /meant/ when they wrote it, it's
about how people interpret it. And I got the impression that Stefan
thought that "UNTRUSTED Good signature" had some positive conotation,
something saying this signature gave more validity to the message than
if it were not signed. But that's not what it means, it's a signature by
an invalid key. Anybody can make a signature by an invalid key. The only
thing "good" means here is that the message was not altered *after* it
was signed by that invalid key. But who made the signature...

When you say "not altered in transit", that would very much depend on
your definition of "in transit". If a Man in the Middle changes both the
text and the signature, I'd say it /was/ altered in transit. But it was
altered in such a way that it once again has an "UNTRUSTED Good"
signature, by a different (attacker-controlled) key.

So IMO, "good" doesn't even mean "not altered in transit", as you said.

Otherwise we could keep redefining "in transit" ad absurdum, and finally
claim that "in transit" means when the video card sent the signal to the
monitor, when the light hit my retinas, when the nerves excited my brain
cells... ;-P.

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/20170623/1c45f184/attachment.sig>

From christopher.donald.jones at gmail.com  Fri Jun 23 13:15:56 2017
From: christopher.donald.jones at gmail.com (Christopher Jones)
Date: Fri, 23 Jun 2017 11:15:56 +0000
Subject: Using gpg for ssh (Maximum Portability)
In-Reply-To: <a07577f9-f00a-8f3c-f53f-9d14ae4b3a0d@andrewg.com>
References: <CADJBR=CpapYtoszWR2oNFqxpjRFXmsrYuVyLeYvxxhWqr12ccQ@mail.gmail.com>
 <b3ed4af3-7bfc-f6e0-8b12-f63e64bd894a@digitalbrains.com>
 <a07577f9-f00a-8f3c-f53f-9d14ae4b3a0d@andrewg.com>
Message-ID: <CADJBR=B-81x3pCH6+Y9WBLmOJGBRT5RhcXObRTeVWdMRaOmAMg@mail.gmail.com>

Peter and Andrew,
   Thank you both for your responses. I'm going to see if I can't use your
advice to ease my frequent system hoteling woes.

-CJones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170623/584e07a2/attachment.html>

From madduck at madduck.net  Fri Jun 23 15:35:05 2017
From: madduck at madduck.net (martin f krafft)
Date: Fri, 23 Jun 2017 15:35:05 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <87podwarcc.fsf@wheatstone.g10code.de>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
Message-ID: <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>

also sprach Werner Koch <wk at gnupg.org> [2017-06-22 19:02 +0200]:
> For a key listing this means computing it for every listed key.  And the
> majority of frontends first do a key listing and show the validity of
> the keys before you can encrypt something.

Obviously, one could work with caching here?

Running --check-trustdb in the background once a day is doable, for
sure.

I guess what I'd really like is a way to run --update-trustdb just
for a specific key, and a way to do that automatically when using
a key, e.g. to verify or encrypt to?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"president thieu says he'll quit if he doesn't get more than 50% of
 the vote. in a democracy, that's not called quitting."
                                                -- the washington post
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170623/5df01c65/attachment.sig>

From neal at walfield.org  Fri Jun 23 15:50:27 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 23 Jun 2017 15:50:27 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
Message-ID: <87r2yazucc.wl-neal@walfield.org>

At Fri, 23 Jun 2017 15:35:05 +0200,
martin f krafft wrote:
> also sprach Werner Koch <wk at gnupg.org> [2017-06-22 19:02 +0200]:
> > For a key listing this means computing it for every listed key.  And the
> > majority of frontends first do a key listing and show the validity of
> > the keys before you can encrypt something.
> 
> Obviously, one could work with caching here?
> 
> Running --check-trustdb in the background once a day is doable, for
> sure.
> 
> I guess what I'd really like is a way to run --update-trustdb just
> for a specific key, and a way to do that automatically when using
> a key, e.g. to verify or encrypt to?

Ensuring that a cache is consistent is *hard*.  I don't think we want
to add complexity (nevermind a cache!) to this security-critical
functionality.


From peter at digitalbrains.com  Fri Jun 23 17:56:18 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 23 Jun 2017 17:56:18 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <87r2yazucc.wl-neal@walfield.org>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
 <87r2yazucc.wl-neal@walfield.org>
Message-ID: <a0ac90d6-a5bf-3105-bc55-0ee81c5b75c8@digitalbrains.com>

On 23/06/17 15:50, Neal H. Walfield wrote:
> Ensuring that a cache is consistent is *hard*.  I don't think we want
> to add complexity (nevermind a cache!) to this security-critical
> functionality.

There are two hard problems in computer science: Cache invalidation,
naming things, and off-by-one errors.

Martin, I think --no-auto-check-trustdb and a cron job will already make
it much more bearable, with the current state of things. That's what I'd
suggest.

Other than that, I don't think my outlined strategy is very complex, it
basically boils down to not actually checking a signature until it is
used to compute validity, and stop for a specific key when full validity
is reached. I could be wrong though. It just doesn't seem like it should
be high on a TODO list, which in practice probably means it won't be
done. If the cron job wasn't available as an option, the situation would
be different.

Peter.

PS: I didn't come up with "There are two..." but I can't be arsed to
look up proper attribution :-).

-- 
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/20170623/61fb1667/attachment.sig>

From neal at walfield.org  Fri Jun 23 20:04:13 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Fri, 23 Jun 2017 20:04:13 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170623170359.ospojv7h3gm7r5b4@brian.minton.name>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
 <87r2yazucc.wl-neal@walfield.org>
 <20170623170359.ospojv7h3gm7r5b4@brian.minton.name>
Message-ID: <87poduzile.wl-neal@walfield.org>

At Fri, 23 Jun 2017 13:04:02 -0400,
Brian Minton wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Fri, Jun 23, 2017 at 03:50:27PM +0200, Neal H. Walfield wrote:
> > 
> > Ensuring that a cache is consistent is *hard*.  I don't think we want
> > to add complexity (nevermind a cache!) to this security-critical
> > functionality.
> > 
> 
> Neal (or Werner), what executable is responsible for maintaining the trustdb?
> Is that handled by gpg itself?

gpg does it, yes.  See gnupg/g10/trustdb.c:validate_keys


From brian at minton.name  Fri Jun 23 19:04:02 2017
From: brian at minton.name (Brian Minton)
Date: Fri, 23 Jun 2017 13:04:02 -0400
Subject: Managing the WoT with GPG
In-Reply-To: <87r2yazucc.wl-neal@walfield.org>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
 <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
 <87r2yazucc.wl-neal@walfield.org>
Message-ID: <20170623170359.ospojv7h3gm7r5b4@brian.minton.name>

On Fri, Jun 23, 2017 at 03:50:27PM +0200, Neal H. Walfield wrote:
> 
> Ensuring that a cache is consistent is *hard*.  I don't think we want
> to add complexity (nevermind a cache!) to this security-critical
> functionality.
> 

Neal (or Werner), what executable is responsible for maintaining the trustdb?
Is that handled by gpg itself?

-- 
Brian Minton
brian at minton dot name http://brian.minton.name
Live long, and prosper longer!
OpenPGP fingerprint = 8213 71DD 4665 CF4F AE20  2206 0424 DC19 B678 A1A9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 390 bytes
Desc: not available
URL: </pipermail/attachments/20170623/c9aa91ae/attachment.sig>

From rexk99 at gmail.com  Sat Jun 24 07:56:20 2017
From: rexk99 at gmail.com (Rex Kneisley)
Date: Fri, 23 Jun 2017 22:56:20 -0700
Subject: Having trouble adding gpg key to apt keyring in Debian 9.0
 (Stretch)
In-Reply-To: <874lvaleza.fsf@fifthhorseman.net>
References: <CAEbDWPVWE78mO_Pu95tHBmcyKc4QFSUp-dPhuUTh1XWJOJ5Hgg@mail.gmail.com>
 <874lvaleza.fsf@fifthhorseman.net>
Message-ID: <CAEbDWPV5Oc0a_9wq8oByo_Fc8qT=DAg7+6om_rpU1BAYY2DBhg@mail.gmail.com>

Thank you Daniel. As it turns out my difficulties were mostly being caused
by the fact that I had some how "broken" my apt updates. I was playing
around with backports in Debian 9.0 Stretch in order to properly download
and install Tor-Browser-Launcher.
I suspect that because Debian 9.0 is so new, the back-ports are still a bit
flakey. Things are working now after a fresh re-install.

I appreciate your suggestion for setting up separate key repositories. I
will use this method moving forward.

Rex

On Tue, Jun 20, 2017 at 10:56 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net
> wrote:

> Hi Rex--
>
> On Tue 2017-06-20 08:43:16 -0700, Rex Kneisley wrote:
> > root at debian-rig:/home/rexk# wget -qO -
> > https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
> > gpg: WARNING: nothing exported
> > gpg: no valid OpenPGP data found.
> > gpg: Total number processed: 0
>
> While it's a common recommendation, "apt-key add -" is generally a bad
> idea, because it mixes the fetched keys in with all the other keys.
> It's a better idea to fetch the keys for a given repository separately
> and mark them as acceptable only for this specific repo.
>
> Since you're using debian stable (stretch), you might want to read:
>
>     https://wiki.debian.org/DebianRepository/UseThirdParty
>
> From its suggestions, if you want to add the sublime repo (which i have
> never vetted and am not personally recommending here), you might prefer
> to do the following on debian stretch:
>
>     wget -O /usr/share/keyring/sublimehq-pub.gpg.asc
> https://download.sublimetext.com/sublimehq-pub.gpg
>     gpg --dearmor < /usr/share/keyring/sublimehq-pub.gpg.asc >
> /usr/share/keyring/sublimehq-pub.gpg
>     echo 'deb [signed-by=/usr/share/keyring/sublimehq-pub.gpg]
> https://download.sublimetext.com/ apt/stable/' > /etc/apt/sources.list.d/
> sublime.list
>
> This makes it so the sublime repository key is not accepted for
> certifying the main debian repos (which it should not be doing).
>
> I suspect that the problem you were having may have to do with the
> ascii-armoring on the fetched file, which is why i've included the
> --dearmor line in the middle of the three steps above.
>
> hope this helps,
>
>      --dkg
>



-- 
Sincerely,


Rex Kneisley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170623/4459cc02/attachment.html>

From 2014-667rhzu3dc-lists-groups at riseup.net  Sun Jun 25 13:11:49 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sun, 25 Jun 2017 12:11:49 +0100
Subject: TOFU
In-Reply-To: <2460ac1a-55f7-79d9-af02-e6b1bde30394@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de> 
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <2460ac1a-55f7-79d9-af02-e6b1bde30394@digitalbrains.com>
Message-ID: <851686887.20170625121149@riseup.net>

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



On Friday 23 June 2017 at 12:49:28 PM, in
<mid:2460ac1a-55f7-79d9-af02-e6b1bde30394 at digitalbrains.com>, Peter
Lebbing wrote:-


> When you say "not altered in transit", that would
> very much depend on
> your definition of "in transit". If a Man in the
> Middle changes both the
> text and the signature, I'd say it /was/ altered in
> transit. But it was
> altered in such a way that it once again has an
> "UNTRUSTED Good"
> signature, by a different (attacker-controlled) key.

> So IMO, "good" doesn't even mean "not altered in
> transit", as you said.

Fair enough. "In transit" was not the best choice of words. But "good
signature" _does_ mean when the signature was verified the message had
not been altered since it was signed. Or maybe that the original
message data has been replaced with new message data that hashes to
the same value.


- --
Best regards

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

Keep them dry and don't feed them after midnight
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWU+adl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5IwTAQDSxCPcfubnikvHpm5Ss8OthAioYuXQrdrNCk88zGupzwEAm3/GwEZp3OSk
dltsW2rZFUbtuG/KsUfDO36M6sh3qQaJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWU+ag18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8IO3B/oC5FQW9De6mMK091ItFKvPIEOC
OoBM62xdGcyWYp+mBAWNsrS5ZUN3RlWlxdJuJ14KtYy+MXHLHJWxr9JcEeUXs8+A
oIIJ0pabMRcpPj3FTFGIeserkBPnZToPIiFqQwVL4VDpPVQ/IbHDMvLdPgBxC7SX
pS381XyFYw2Y69zzVChuFwXICqgw0gAGR9HY021UG9BZR9uxPPxntj446gznDCkR
2HMR2l0MKoiU6+jU3yZfl3B8YWRBg1Yoy6S5p0E5UDQZ0hIPUp4mQ+RrrNwEvokU
mQKuOX0eegC00SljveMIZTLwe9zgDfXSre5wox/E7U94qdeNoTNiGdueir2K
=Mgyw
-----END PGP SIGNATURE-----



From peter at digitalbrains.com  Sun Jun 25 14:20:51 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jun 2017 14:20:51 +0200
Subject: Enigmail signature status indications (was: TOFU)
In-Reply-To: <851686887.20170625121149@riseup.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <2460ac1a-55f7-79d9-af02-e6b1bde30394@digitalbrains.com>
 <851686887.20170625121149@riseup.net>
Message-ID: <1b4492e4-2169-b5ae-7d48-af1cfbb633bf@digitalbrains.com>

On 25/06/17 13:11, MFPA wrote:
> But "good signature" _does_ mean when the signature was verified the
> message had not been altered since it was signed.

However, I don't think that this information is in any way relevant to a
user if the key that signed it was not valid. I'm afraid the current
formulation doesn't do enough to discourage people to attach value to a
signature by an invalid key. The word "good" is weakening the message of
the word "UNTRUSTED", IMO.

The gpg command line also uses the word "good". But it is much more
verbose about it being made by an invalid key:

> gpg: Good signature from "First Name Last Name <email>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the owner.

I am aware that changing the formulation doesn't make people use it
correctly; using it correctly is hard. But I think it would be much
better if it just said "UNTRUSTED signature". And if the signature is
not "good", it'll simply say "Error - signature verification failed".

> Or maybe that the original message data has been replaced with new
> message data that hashes to the same value.

Well, let's assume that this is not possible. When weak hashes are
disabled, this should not be possible. If we start to include this kind
of things in our assumptions, we should also add "or that somebody
managed to compute the private key for the key that signed this message".

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/20170625/109aa3f1/attachment-0001.sig>

From neal at walfield.org  Sun Jun 25 20:09:13 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Sun, 25 Jun 2017 20:09:13 +0200
Subject: TOFU
In-Reply-To: <1873229282.20170623020719@riseup.net>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
Message-ID: <87o9tcym5y.wl-neal@walfield.org>

At Fri, 23 Jun 2017 02:07:19 +0100,
MFPA wrote:
> On Wednesday 21 June 2017 at 7:49:42 PM, in
> <mid:ffb9b23c-b01b-44d0-3a75-6e5e474de196 at digitalbrains.com>, Peter
> Lebbing wrote:-
> 
> > I think it's a bad UX choice to
> > name an invalid
> > signature "UNTRUSTED Good" and a valid signature
> > "Good". I think it
> > suggests they both have some credibility, which is a
> > false suggestion.
> 
> I thought "good signature" just meant the message has not been
> altered in transit.

Nope.  A MitM could have intercepted the message and replaced the body
with some other signed text (text that it possibly signed with a
"fake" key).

HTH,

:) Neal


From support at koramgame.mail.helpshift.com  Sun Jun 25 21:08:26 2017
From: support at koramgame.mail.helpshift.com (Goddess: Primal Chaos)
Date: Sun, 25 Jun 2017 19:08:26 +0000
Subject: TOFU
Message-ID: <20170625181241.32810.53452FEC4264F9E0@mail.helpshift.com>

### Do not reply below this line ###

---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 25, 2017 | 20:12 +0200
---------------------------------------------------------------------------------

Dear player, 
Thank you very much for contacting us by mail. As the language or region of your email can?t be automatically identified, we have to manually sort through each and every issue then send these on to the relevant GM. 
- If you are able to log in to the game, we recommend you send a message to us in-game via Settings-Account-Help. 
- If you can?t find your account, usually it means you?re using the wrong login method or server. Please confirm you?re using the same login method as before and have selected the correct server.
Please note that even if have bound to your Facebook or Google account, if you are using "Sign In" to login, please login exactly as previously since data is not exchanged between the three different login methods.
Please leave your correct server and character name (if you?re using any special symbols in your name, please ensure you?re continuing to do so) and we?ll check your login method as soon as possible for you to.
Thanks for your support and cooperation!


---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 25, 2017 | 20:12 +0200
---------------------------------------------------------------------------------

Hi, thanks for contacting Customer Service. This is an automated reply, hope to help you solve common problems. Please tell me your server and character's name. Manual service will contact you as soon as possible! Thank you very much for the support and patience.  

If you have a problem with recharge, please leave us the necessary information.
  1. the name of the character(IGN)
  2. the server
  3. the number of your order
        # via Google, we need the GPA.XXXX-XXXX-XXXX-XXXXX
        #via Apple, we need the number from the receipt and also a screenshot that you take from the Itunes of your computer.
       #other ways, please let us know the exact way of recharging and the number of it
  4. the UID of this character (which you can see in the game, but if you cannot find it that will be fine )
We are really hope that we could help!

If you want to report a BUG, please try to tell us more details, such as related character names and servers. The most important is the exact time (better with hour and minute), so that we locate and check the problem more quickly. Thank you in advance.


---------------------------------------------------------------------------------
Neal H. Walfield | June 25, 2017 | 20:12 +0200
---------------------------------------------------------------------------------

<strong>TOFU</strong><br/><br/>At Fri, 23 Jun 2017 02:07:19 +0100,
MFPA wrote:
> On Wednesday 21 June 2017 at 7:49:42 PM, in
> <mid:ffb9b23c-b01b-44d0-3a75-6e5e474de196 at digitalbrains.com>, Peter
> Lebbing wrote:-
> 
> > I think it's a bad UX choice to
> > name an invalid
> > signature "UNTRUSTED Good" and a valid signature
> > "Good". I think it
> > suggests they both have some credibility, which is a
> > false suggestion.
> 
> I thought "good signature" just meant the message has not been
> altered in transit.

Nope.  A MitM could have intercepted the message and replaced the body
with some other signed text (text that it possibly signed with a
"fake" key).

HTH,

:) Neal

_______________________________________________
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/20170625/0cb5822f/attachment-0001.html>

From stefan.claas at posteo.de  Sun Jun 25 21:42:47 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Sun, 25 Jun 2017 21:42:47 +0200
Subject: TOFU
In-Reply-To: <87o9tcym5y.wl-neal@walfield.org>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <87o9tcym5y.wl-neal@walfield.org>
Message-ID: <3wwjJw5ZNqzyth@submission01.posteo.de>

On Sun, 25 Jun 2017 20:09:13 +0200, Neal H. Walfield wrote:
> At Fri, 23 Jun 2017 02:07:19 +0100,
> MFPA wrote:
> > On Wednesday 21 June 2017 at 7:49:42 PM, in
> > <mid:ffb9b23c-b01b-44d0-3a75-6e5e474de196 at digitalbrains.com>, Peter
> > Lebbing wrote:-
> >   
> > > I think it's a bad UX choice to
> > > name an invalid
> > > signature "UNTRUSTED Good" and a valid signature
> > > "Good". I think it
> > > suggests they both have some credibility, which is a
> > > false suggestion.  
> > 
> > I thought "good signature" just meant the message has not been
> > altered in transit.  
> 
> Nope.  A MitM could have intercepted the message and replaced the body
> with some other signed text (text that it possibly signed with a
> "fake" key).

I asked this already in this thread, do you know what TOFU does
when a man in the middle would replace (theoretically) one of
my pub keys, modify the TOFU database , set's the Trust Level
to Ultimate and then sends a message to me. Am i correct that
even with a modified database TOFU would tell me, wait there
is already one key (the original one) on a key server and this
one is not the correct one.

Regards
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170625/755c156f/attachment.sig>

From madduck at madduck.net  Mon Jun 26 11:27:30 2017
From: madduck at madduck.net (martin f krafft)
Date: Mon, 26 Jun 2017 11:27:30 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <a0ac90d6-a5bf-3105-bc55-0ee81c5b75c8@digitalbrains.com>
References: <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
 <87r2yazucc.wl-neal@walfield.org>
 <a0ac90d6-a5bf-3105-bc55-0ee81c5b75c8@digitalbrains.com>
Message-ID: <20170626092729.toa6p6bajj3e4uvm@albatross.lehel.madduck.net>

also sprach Peter Lebbing <peter at digitalbrains.com> [2017-06-23 17:56 +0200]:
> There are two hard problems in computer science: Cache invalidation,
> naming things, and off-by-one errors.

I haven't heard that one in years. Lol. ;)

> Martin, I think --no-auto-check-trustdb and a cron job will
> already make it much more bearable, with the current state of
> things. That's what I'd suggest.

I've been doing that for a long time already, and yes, it mitigates
the issue a little bit. I still think that the interface doesn't
exactly invite people to invest time into the WoT, which directly
translates into lesser quality.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich wei?."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: </pipermail/attachments/20170626/413d875f/attachment.sig>

From support at koramgame.mail.helpshift.com  Mon Jun 26 11:31:04 2017
From: support at koramgame.mail.helpshift.com (Goddess: Primal Chaos)
Date: Mon, 26 Jun 2017 09:31:04 +0000
Subject: Managing the WoT with GPG
Message-ID: <20170626093103.68781.BE50A6CB9AC487CA@mail.helpshift.com>

### Do not reply below this line ###

---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 26, 2017 | 11:31 +0200
---------------------------------------------------------------------------------

Dear player, 
Thank you very much for contacting us by mail. As the language or region of your email can?t be automatically identified, we have to manually sort through each and every issue then send these on to the relevant GM. 
- If you are able to log in to the game, we recommend you send a message to us in-game via Settings-Account-Help. 
- If you can?t find your account, usually it means you?re using the wrong login method or server. Please confirm you?re using the same login method as before and have selected the correct server.
Please note that even if have bound to your Facebook or Google account, if you are using "Sign In" to login, please login exactly as previously since data is not exchanged between the three different login methods.
Please leave your correct server and character name (if you?re using any special symbols in your name, please ensure you?re continuing to do so) and we?ll check your login method as soon as possible for you to.
Thanks for your support and cooperation!


---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 26, 2017 | 11:31 +0200
---------------------------------------------------------------------------------

Hi, thanks for contacting Customer Service. This is an automated reply, hope to help you solve common problems. Please tell me your server and character's name. Manual service will contact you as soon as possible! Thank you very much for the support and patience.  

If you have a problem with recharge, please leave us the necessary information.
  1. the name of the character(IGN)
  2. the server
  3. the number of your order
        # via Google, we need the GPA.XXXX-XXXX-XXXX-XXXXX
        #via Apple, we need the number from the receipt and also a screenshot that you take from the Itunes of your computer.
       #other ways, please let us know the exact way of recharging and the number of it
  4. the UID of this character (which you can see in the game, but if you cannot find it that will be fine )
We are really hope that we could help!

If you want to report a BUG, please try to tell us more details, such as related character names and servers. The most important is the exact time (better with hour and minute), so that we locate and check the problem more quickly. Thank you in advance.


---------------------------------------------------------------------------------
martin f krafft | June 26, 2017 | 11:31 +0200
---------------------------------------------------------------------------------

<strong>Managing the WoT with GPG</strong><br/><br/>also sprach Peter Lebbing <peter at digitalbrains.com> [2017-06-23 17:56 +0200]:
> There are two hard problems in computer science: Cache invalidation,
> naming things, and off-by-one errors.

I haven't heard that one in years. Lol. ;)

> Martin, I think --no-auto-check-trustdb and a cron job will
> already make it much more bearable, with the current state of
> things. That's what I'd suggest.

I've been doing that for a long time already, and yes, it mitigates
the issue a little bit. I still think that the interface doesn't
exactly invite people to invest time into the WoT, which directly
translates into lesser quality.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich wei?."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus at madduck.net
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

---------------------------------------------------------------------------------
Attachments :

attachment [ https://d2duuy9yo5pldo.cloudfront.net/koramgame/b7df0b8dfdda84806641a62a835dc160d31c7861.asc ]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170626/95fbde35/attachment-0001.html>

From neal at walfield.org  Mon Jun 26 11:53:16 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Mon, 26 Jun 2017 11:53:16 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170626092729.toa6p6bajj3e4uvm@albatross.lehel.madduck.net>
References: <87mv911xaq.wl-neal@walfield.org>
 <20170621115552.vyjrttnww2cwvo3x@albatross.lehel.madduck.net>
 <87k2451rfl.wl-neal@walfield.org>
 <20170622130052.w3p5bthw57bjg4mm@albatross.lehel.madduck.net>
 <877f04152l.wl-neal@walfield.org>
 <20170622142930.bdn5b2rvszezmq2n@albatross.lehel.madduck.net>
 <87podwarcc.fsf@wheatstone.g10code.de>
 <20170623133505.rr43uqzh5lcduetz@albatross.lehel.madduck.net>
 <87r2yazucc.wl-neal@walfield.org>
 <a0ac90d6-a5bf-3105-bc55-0ee81c5b75c8@digitalbrains.com>
 <20170626092729.toa6p6bajj3e4uvm@albatross.lehel.madduck.net>
Message-ID: <87lgofyt0z.wl-neal@walfield.org>

At Mon, 26 Jun 2017 11:27:30 +0200,
martin f krafft wrote:
> > Martin, I think --no-auto-check-trustdb and a cron job will
> > already make it much more bearable, with the current state of
> > things. That's what I'd suggest.
> 
> I've been doing that for a long time already, and yes, it mitigates
> the issue a little bit. I still think that the interface doesn't
> exactly invite people to invest time into the WoT, which directly
> translates into lesser quality.

I disagree that this is the bottleneck.  Two very strong arguments
against the WoT, IMO are:

  1. Key signing is too hard to do right.

  2. Key signing exposes the social graph.

1 means that people primarily interested in protecting their privacy
don't bother.

2 means that organizations like the Organized Crime and Corruption
Reporting Project (OCCRP) can't use the WoT, because it places their
reporters and sources in danger.

We could perhaps fix 1 by doing more red teaming (i.e., fake attacks
so that people see the actual utility of checking keys), but I'm not
sure that's the best way forward.

:) Neal


From support at koramgame.mail.helpshift.com  Mon Jun 26 11:55:35 2017
From: support at koramgame.mail.helpshift.com (Goddess: Primal Chaos)
Date: Mon, 26 Jun 2017 09:55:35 +0000
Subject: Managing the WoT with GPG
Message-ID: <20170626095535.101301.A6CAA3A15EBDEE70@mail.helpshift.com>

### Do not reply below this line ###

---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 26, 2017 | 11:55 +0200
---------------------------------------------------------------------------------

Dear player, 
Thank you very much for contacting us by mail. As the language or region of your email can?t be automatically identified, we have to manually sort through each and every issue then send these on to the relevant GM. 
- If you are able to log in to the game, we recommend you send a message to us in-game via Settings-Account-Help. 
- If you can?t find your account, usually it means you?re using the wrong login method or server. Please confirm you?re using the same login method as before and have selected the correct server.
Please note that even if have bound to your Facebook or Google account, if you are using "Sign In" to login, please login exactly as previously since data is not exchanged between the three different login methods.
Please leave your correct server and character name (if you?re using any special symbols in your name, please ensure you?re continuing to do so) and we?ll check your login method as soon as possible for you to.
Thanks for your support and cooperation!


---------------------------------------------------------------------------------
Goddess: Primal Chaos | June 26, 2017 | 11:55 +0200
---------------------------------------------------------------------------------

Hi, thanks for contacting Customer Service. This is an automated reply, hope to help you solve common problems. Please tell me your server and character's name. Manual service will contact you as soon as possible! Thank you very much for the support and patience.  

If you have a problem with recharge, please leave us the necessary information.
  1. the name of the character(IGN)
  2. the server
  3. the number of your order
        # via Google, we need the GPA.XXXX-XXXX-XXXX-XXXXX
        #via Apple, we need the number from the receipt and also a screenshot that you take from the Itunes of your computer.
       #other ways, please let us know the exact way of recharging and the number of it
  4. the UID of this character (which you can see in the game, but if you cannot find it that will be fine )
We are really hope that we could help!

If you want to report a BUG, please try to tell us more details, such as related character names and servers. The most important is the exact time (better with hour and minute), so that we locate and check the problem more quickly. Thank you in advance.


---------------------------------------------------------------------------------
Neal H. Walfield | June 26, 2017 | 11:55 +0200
---------------------------------------------------------------------------------

<strong>Managing the WoT with GPG</strong><br/><br/>At Mon, 26 Jun 2017 11:27:30 +0200,
martin f krafft wrote:
> > Martin, I think --no-auto-check-trustdb and a cron job will
> > already make it much more bearable, with the current state of
> > things. That's what I'd suggest.
> 
> I've been doing that for a long time already, and yes, it mitigates
> the issue a little bit. I still think that the interface doesn't
> exactly invite people to invest time into the WoT, which directly
> translates into lesser quality.

I disagree that this is the bottleneck.  Two very strong arguments
against the WoT, IMO are:

  1. Key signing is too hard to do right.

  2. Key signing exposes the social graph.

1 means that people primarily interested in protecting their privacy
don't bother.

2 means that organizations like the Organized Crime and Corruption
Reporting Project (OCCRP) can't use the WoT, because it places their
reporters and sources in danger.

We could perhaps fix 1 by doing more red teaming (i.e., fake attacks
so that people see the actual utility of checking keys), but I'm not
sure that's the best way forward.

:) Neal

_______________________________________________
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/20170626/658d4d3a/attachment-0001.html>

From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jun 27 10:27:57 2017
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 27 Jun 2017 09:27:57 +0100
Subject: Managing the WoT with GPG
In-Reply-To: <20170626093103.68781.BE50A6CB9AC487CA@mail.helpshift.com>
References: <20170626093103.68781.BE50A6CB9AC487CA@mail.helpshift.com>
Message-ID: <1615202689.20170627092757@riseup.net>

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



On Monday 26 June 2017 at 10:31:04 AM, in
<mid:20170626093103.68781.BE50A6CB9AC487CA at mail.helpshift.com>,
Goddess: Primal Chaos wrote:-


> Dear player,  Thank you very much for contacting us
> by mail.


I've seen several of these messages on this list lately. It looks like
somebody has subscribed a customer helpline email address
<support at koramgame.mail.helpshift.com> to the list.


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

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWVIXD18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5DCvAQCD8h9jPeaQfKdyvHfEELIomGjOHTP0Vl8IUnd9J5Fy8QD+N7Orx529dAUi
uK+WQTmJbSTSvGGie4vDrBAjQcf6jQSJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWVIXIV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8FfEB/4vnirYHMmwq1UnjBe5BYJRlxXu
dUXP1Rrg+dw2/m/OhbSARuwsiT+av3dpHV7z3dtS+QVhpPNtgBWxrjwoAw0fdjEI
3zuUk6tyZ0tRIuEGwE7bTuOvMFUvWzS3gUappmAegSWrLdGXOZLvm7cc+oWTZz6v
NZGqboD5Nkk4kWP+aX+1saoRWmBLwkuPy1DbklBJMP68haDdPp9v/JVcipRnVGBY
agnsJ2eiaAXRKwXHplBElmLnHdkkmlIIuIk4LP/AnXdIcKbO6dtjplh4guqeAeEW
ns9QP9HGpFKa4Fd5O86WynS3L5OFWuXB41WI07otbxGDUr+grH1Sw8AzQ6FW
=Mf4A
-----END PGP SIGNATURE-----



From neal at walfield.org  Tue Jun 27 10:36:38 2017
From: neal at walfield.org (Neal H. Walfield)
Date: Tue, 27 Jun 2017 10:36:38 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <1615202689.20170627092757@riseup.net>
References: <20170626093103.68781.BE50A6CB9AC487CA@mail.helpshift.com>
 <1615202689.20170627092757@riseup.net>
Message-ID: <874lv1zv1l.wl-neal@walfield.org>

At Tue, 27 Jun 2017 09:27:57 +0100,
MFPA wrote:
> On Monday 26 June 2017 at 10:31:04 AM, in
> <mid:20170626093103.68781.BE50A6CB9AC487CA at mail.helpshift.com>,
> Goddess: Primal Chaos wrote:-
> 
> 
> > Dear player,  Thank you very much for contacting us
> > by mail.
> 
> 
> I've seen several of these messages on this list lately. It looks like
> somebody has subscribed a customer helpline email address
> <support at koramgame.mail.helpshift.com> to the list.

These should now be disabled.

Thanks,

:) Neal


From pete at heypete.com  Wed Jun 28 22:47:54 2017
From: pete at heypete.com (Pete Stephenson)
Date: Wed, 28 Jun 2017 22:47:54 +0200
Subject: Creating Unique Fingerprint
In-Reply-To: <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>
References: <CAFfRHj2S_8Y-bSNj1f5WwX+zdzvbFb3=Qh80OBNLDqfgwZOU_g@mail.gmail.com>
 <bf3cfaa2-1c9e-2aa4-85b8-5da6f8f1a65d@gmail.com>
Message-ID: <1498682874.2126799.1024556128.596C7A31@webmail.messagingengine.com>

It's not as hard as you might think, at least in terms of 32-bit
fingerprints: https://evil32.com/
--
Pete Stephenson


On Mon, Jun 19, 2017, at 08:00 AM, Lou Wynn wrote:
> According to my understanding of crypto theory, your only way is to
> generate keys and compare their fingerprints and with the value you
> want. I would be surprised that you can find one in your lifetime. Or
> it'd be a breakthrough in cryptography if you managed to do it
> somehow.


> Thanks, Lou
>> On 06/18/2017 07:23 PM, Long Si wrote:
>> Hi  I am on Linux, and would like to generate a key with "unique 40"
>> fingerprint.  eg 1: Starts with ABCD XXXX ... XXXX  eg 2: Starts with
>> AXXX XXXX ... XXXA ends with A  eg 3: XXXX ... XXXX without any '0'
>> character at all  How would I go about writing such a script? Don't
>> mind running for months to get these sets.  Regards
>> _______________________________________________ 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/20170628/c97e2782/attachment.html>

From pete at heypete.com  Thu Jun 29 00:50:49 2017
From: pete at heypete.com (Pete Stephenson)
Date: Thu, 29 Jun 2017 00:50:49 +0200
Subject: Technical contact for mailing list?
Message-ID: <1498690249.2156270.1024662160.58E85280@webmail.messagingengine.com>

Hi all,

Who is the appropriate person to contact regarding technical issues with
the mailing list?

Specifically, it appears that the list doesn't play nice with anti-spam
measures like DMARC, SPF, and DKIM and so messages sent from domains
with restrictive DMARC and SPF rules get flagged as spam as mail servers
think the mailing list server is forging messages for those domains.

I'd be happy to provide more information but don't want to needlessly
add noise to the list.

Cheers!
-Pete

-- 
Pete Stephenson


From wk at gnupg.org  Thu Jun 29 09:28:20 2017
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jun 2017 09:28:20 +0200
Subject: [Announce] Libgcrypt 1.7.8 released to fix CVE-2017-7526
Message-ID: <87r2y35k2z.fsf@wheatstone.g10code.de>

Hi!

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

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 in version 1.7.8 (2017-06-29)  [C21/A1/R8]
===================================

 * Bug fixes:

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


Note that this side-channel attack requires that the attacker can run
arbitrary software on the hardware where the private RSA key is used.
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.
However, on boxes with virtual machines this attack may be used by one
VM to steal private keys from another VM.



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.7.8.tar.bz2 (2830k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz (3398k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.bz2 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.tar.gz 
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.8.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.7.8.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.7.8.tar.bz2.sig libgcrypt-1.7.8.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.7.8.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.7.8.tar.bz2

   and check that the output matches the first line from the
   this list:

65a4a495aa858483e66868199eaa8238572ca6cd  libgcrypt-1.7.8.tar.bz2
b1290e278170c638955de430699a425c2121750b  libgcrypt-1.7.8.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].

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


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/20170629/307372b6/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From w at uter.be  Thu Jun 29 09:52:02 2017
From: w at uter.be (Wouter Verhelst)
Date: Thu, 29 Jun 2017 09:52:02 +0200
Subject: Managing the WoT with GPG
In-Reply-To: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
References: <20170620133444.x3s2lfjlxbht3dya@albatross.lehel.madduck.net>
Message-ID: <20170629075202.q37jemkb6ltvx2mk@grep.be>

On Tue, Jun 20, 2017 at 03:34:44PM +0200, martin f krafft wrote:
> 2. I've also tried running --update-trustdb, but it seems that this
>    process is *endless*. I have no idea how many keys remain, and
>    I also got the impression that I keep seeing keys I already
>    processed. How do you approach this? Or does everyone just use
>    tofu these days?

This is only true the first time around. GnuPG will store the answers
you enter, and retain them for future use.

I did so on my keyring, and now it asks me to run update-trustdb once
every few months. When I do, I need to answer on only a handful of keys

> 3. Is there a way to run --check-trustdb or --update-trustdb not
>    over the entire key graph, but only traversing to a certain depth
>    starting from a specific key?

--update-trustdb only asks about keys that are already trusted. It
starts with keys that you yourself signed, then checks which keys are
signed by those and therefore trusted, and asks about them. Etc, etc,
until you've got everything.

[...]
> 5. Has anyone come up with a smart way to keep pubring/trustdb
>    synchronised between multiple workstations?

You can export the values you've input into --update-trustdb with
--export-ownertrust (and then import them into another machine with
--import-ownertrust).

This is, in fact, a good idea to do for backup purposes every once in a
while.

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

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


From kristian.fiskerstrand at sumptuouscapital.com  Thu Jun 29 10:32:24 2017
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 29 Jun 2017 10:32:24 +0200
Subject: Technical contact for mailing list?
In-Reply-To: <1498690249.2156270.1024662160.58E85280@webmail.messagingengine.com>
References: <1498690249.2156270.1024662160.58E85280@webmail.messagingengine.com>
Message-ID: <8b7255d7-4eb4-a253-1079-9f8092b7d734@sumptuouscapital.com>

On 06/29/2017 12:50 AM, Pete Stephenson wrote:
> Hi all,

Hi,

> 
> Who is the appropriate person to contact regarding technical issues with
> the mailing list?
> 
> Specifically, it appears that the list doesn't play nice with anti-spam
> measures like DMARC, SPF, and DKIM and so messages sent from domains
> with restrictive DMARC and SPF rules get flagged as spam as mail servers
> think the mailing list server is forging messages for those domains.

This is likely a a continuation of
https://lists.gnupg.org/pipermail/gnupg-users/2017-March/057877.html
-- 
----------------------------
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
----------------------------
"Better to keep your mouth shut and be thought a fool than to open it
and remove all doubt"
(Mark Twain)

-------------- 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/20170629/42ae2170/attachment.sig>

From jhudson at cedaron.com  Wed Jun 28 19:35:21 2017
From: jhudson at cedaron.com (Joshua Hudson)
Date: Wed, 28 Jun 2017 17:35:21 +0000
Subject: SHA1 depreciation ??
Message-ID: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>

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

SHA1 got broken some months ago, but I see no useful move to get rid of using it for even new stuff.

I found some email chains awhile back showing the web of trust collapsing if SHA1 were not used.

I found ubuntu trying to go at removing it alone: https://wiki.ubuntu.com/SecurityTeam/GPGMigration
(mainly talks about changing keys but they are testing SHA2 signatures extensively)

I found out it's really hard to make a key that doesn't say "Digest: ... SHA1" in its attributes.

I found out why the web of trust collapses; public signing defaults to SHA1 unless a command line
option is passed to change it. Editing key preferences on your signing key won't do it.

I'm pretty sure enigmail will sign this message with SHA1 because it doesn't have an option to
select digest and setting whatever on preferences doesn't work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAllT6MMACgkQE8ihdI6XWvTX1AD/T8oFAb2/TNGkt3Ke8sYSTO9H
wQXh6MqsRajuqF542NUA/2PEajHFahVohQBxQLeUwAZr5G8Kk4q77Nq3mOpwzbfa
=kwi5
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8E975AF4.asc
Type: application/pgp-keys
Size: 2427 bytes
Desc: 0x8E975AF4.asc
URL: </pipermail/attachments/20170628/9349e140/attachment.key>

From rjh at sixdemonbag.org  Thu Jun 29 23:31:35 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 29 Jun 2017 17:31:35 -0400
Subject: SHA1 depreciation ??
In-Reply-To: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>
References: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>
Message-ID: <ead53bf3-9e19-55b4-1c9b-17e96bed0076@sixdemonbag.org>

> SHA1 got broken some months ago, but I see no useful move to get rid
> of using it for even new stuff.

(a) Not for OpenPGP's uses.  For our uses it's still safe, although we
recommend moving to other, better, hashes as soon as possible.

(b) It's pretty easy to avoid using SHA-1.  There are still a small
number of places where it's mandatory, and this will not change until
the IETF OpenPGP Working Group publishes the v5 key specification.

(c) The IETF OpenPGP WG is working on a new key specification ("v5")
which completely gets rid of SHA-1.

> I found out it's really hard to make a key that doesn't say "Digest:
> ... SHA1" in its attributes.

You found out it's *impossible*.  SHA-1 is a MUST algorithm according to
the RFC.  You cannot get rid of SHA-1 from your key preferences.  Even
if you were to do it, every RFC-conformant OpenPGP application on the
planet would say, "that's odd: let me just append SHA-1 to that", as
they are required to do by the RFC.

> I found out why the web of trust collapses; public signing defaults
> to SHA1 unless a command line option is passed to change it. Editing
> key preferences on your signing key won't do it.

You didn't read the manual.  The preferences attached to your key tell
the world what algorithms you're capable of interoperating with.  GnuPG
never uses them to decide which algorithms to apply to your own traffic.

> I'm pretty sure enigmail will sign this message with SHA1 because it
> doesn't have an option to select digest and setting whatever on
> preferences doesn't work.

Enigmail doesn't sign anything.  GnuPG is what signs things.  Enigmail
just hands your documents to GnuPG for processing.

Check what digest was used to sign this message.  Hint: I'm using Enigmail.

Try adding this lines to your gpg.conf file:

personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160

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

From kloecker at kde.org  Thu Jun 29 22:20:40 2017
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 29 Jun 2017 22:20:40 +0200
Subject: Technical contact for mailing list?
In-Reply-To: <1498690249.2156270.1024662160.58E85280@webmail.messagingengine.com>
References: <1498690249.2156270.1024662160.58E85280@webmail.messagingengine.com>
Message-ID: <2021137.tlDX6SQQqr@thufir>

On Thursday 29 June 2017 00:50:49 Pete Stephenson wrote:
> Hi all,
> 
> Who is the appropriate person to contact regarding technical issues
> with the mailing list?

I'd start with the people who run this list. See
https://lists.gnupg.org/mailman/listinfo/gnupg-users

They can be reached at gnupg-users-owner at gnupg.org.


Regards,
Ingo



From lewisurn at gmail.com  Fri Jun 30 02:33:32 2017
From: lewisurn at gmail.com (Lou Wynn)
Date: Thu, 29 Jun 2017 17:33:32 -0700
Subject: SHA1 depreciation ??
In-Reply-To: <ead53bf3-9e19-55b4-1c9b-17e96bed0076@sixdemonbag.org>
References: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>
 <ead53bf3-9e19-55b4-1c9b-17e96bed0076@sixdemonbag.org>
Message-ID: <c33a36ed-d967-2521-690d-3161ca4cd73b@gmail.com>

On 06/29/2017 02:31 PM, Robert J. Hansen wrote:
>> SHA1 got broken some months ago, but I see no useful move to get rid
>> of using it for even new stuff.
> (a) Not for OpenPGP's uses.  For our uses it's still safe, although we
> recommend moving to other, better, hashes as soon as possible.
>
> (b) It's pretty easy to avoid using SHA-1.  There are still a small
> number of places where it's mandatory, and this will not change until
> the IETF OpenPGP Working Group publishes the v5 key specification.
>
> (c) The IETF OpenPGP WG is working on a new key specification ("v5")
> which completely gets rid of SHA-1.

As for the current version v4, SHA1 is used to compute the fingerprint.
Are there other mandatory places?

Others such as signature hash and password hash do not depend on SHA1.

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


Thanks,

Lou

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170629/c5e19ad3/attachment-0001.html>

From rjh at sixdemonbag.org  Fri Jun 30 05:26:06 2017
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 29 Jun 2017 23:26:06 -0400
Subject: SHA1 depreciation ??
In-Reply-To: <c33a36ed-d967-2521-690d-3161ca4cd73b@gmail.com>
References: <1b3f8b29-7838-a6ea-67bf-df9797060f03@cedaron.com>
 <ead53bf3-9e19-55b4-1c9b-17e96bed0076@sixdemonbag.org>
 <c33a36ed-d967-2521-690d-3161ca4cd73b@gmail.com>
Message-ID: <62e832de-7c5e-e3c4-5eba-58286d61b27f@sixdemonbag.org>

> As for the current version v4, SHA1 is used to compute the fingerprint.
> Are there other mandatory places?

Yes.  Search the RFC for the term "SHA-1" and you'll find them.  It's
hardwired into several of the packet formats, for instance.

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

No.  The WG is being annoyingly slow.



From hello at ryanlue.com  Fri Jun 30 05:54:46 2017
From: hello at ryanlue.com (Ryan Lue)
Date: Fri, 30 Jun 2017 11:54:46 +0800
Subject: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?
Message-ID: <20170630035446.lfjxtbmbqpdwohah@liberte>

Hello,

I have struggled with getting GPG keys to work for SSH authentication
for the better part of two days. I'm almost completely there, and would
like to ask gnupg-users' help in understanding this one last quirk.

To be brief, I have gpg-agent set up with ssh support enabled. I'm using an authentication-only subkey for SSH authentication.

If I _don't_ set a password on this subkey, I can log into my SSH
servers no problem. This is what I'm doing right now, because my
security needs are not very strict. It's when I _do_ set a password that
I run into problems. 

Basically, there are two ways that I have figured out to get it to work:
I can use the `pinentry-mac` GUI pinentry program, and everything works
fine. Or, I can set `allow-preset-passphrase` and then manually cache
the passphrase up front with `gpg-preset-passphrase`. (Only, that's
problematic because it can't be automated without storing the passphrase
in cleartext.)

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

So, why can't I use `pinentry-curses` for SSH authentication? Does it
have something to do with the `$GPG_TTY` environment variable not being
set on the SSH server? Any insight or clues on how to troubleshoot this
problem would be deeply appreciated. 

(FWIW, I'm on Mac OS 10.11 El Capitan with GnuPG 2.1.21 and pinentry
1.0.0, both installed via Homebrew. And yes, I'm making the necessary
changes to the `pinentry-program` setting in `~/.gnupg/gpg-agent.conf`
when testing these alternatives.)

?Ryan

P.S. I've posted a guide on my blog with a comprehensive rundown of the
steps I took to get it all set up ? that might be able to clarify any
questions you might have about my configuration:

http://ryanlue.com/posts/2017-06-29-gpg-for-ssh-auth

If Werner is interested, I think the official website could really use
some friendlier Getting Started guides, and I'd be happy to contribute.
I posted my guide on /r/linux, and you'd be surprised at how many people
thought ssh authentication via gpg was an ?unconventional hack?.



From peter at digitalbrains.com  Fri Jun 30 18:29:41 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 30 Jun 2017 18:29:41 +0200
Subject: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works
 fine?
In-Reply-To: <20170630035446.lfjxtbmbqpdwohah@liberte>
References: <20170630035446.lfjxtbmbqpdwohah@liberte>
Message-ID: <f07b1d5d-e8b4-024f-2e53-5bcfd8a61789@digitalbrains.com>

On 30/06/17 05:54, Ryan Lue wrote:
> Does it have something to do with the `$GPG_TTY` environment variable
> not being set on the SSH server?

Almost; it has to do with the GPG_TTY variable not being communicated to
the agent.  The agent does not know on which tty the request for a
pinentry is made. To use a text mode pinentry with SSH, you need to invoke:

$ gpg-connect-agent updatestartuptty /bye

on the tty where you'll be SSH'ing (or some variation, this one is
pretty succinct). Otherwise the pinentry will pop up on the tty where
you did that last, or the tty that started the agent if you never did
it. That tty might not exist, not exist anymore, or be in a surprising
location.

It would be really good if the SSH agent protocol would be extended to
communicate on which tty a request comes in. Without updates to the SSH
protocol, there is simply no way to know where it comes from.

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

> I posted my guide on /r/linux, and you'd be surprised at how many
> people thought ssh authentication via gpg was an ?unconventional
> hack?.

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

I'd wager that this problem also occurs with the GNOME and KDE SSH
agents, if you for instance share a "screen" session with a Linux
virtual terminal (which would take care of sharing SSH_AGENT). My guess
is if you SSH from the virtual terminal, it'll freeze while your
"swapped out" graphical session invisibly prompts you to enter your
passphrase. But I haven't tried it.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

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

From peter at digitalbrains.com  Fri Jun 30 18:38:45 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 30 Jun 2017 18:38:45 +0200
Subject: TOFU
In-Reply-To: <3wwjJw5ZNqzyth@submission01.posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net> <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
Message-ID: <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>

On 25/06/17 21:42, Stefan Claas wrote:
> I asked this already in this thread, do you know what TOFU does
> when a man in the middle would replace (theoretically) one of
> my pub keys, modify the TOFU database , set's the Trust Level
> to Ultimate and then sends a message to me.

That's not what a MitM is. A Man in the Middle has no access to the
endpoints, he's in between them, hence middle.

And as I said earlier, if your endpoint isn't secure (last time, I
phrased it as "if someone gets your user privileges"), it's game over.

Also, in regard to your earlier mention of "shouldn't 'Ultimate' be
differently coloured to recognize this scenario", note that your
scenario of ultimately trusting a key used for data signatures isn't the
only way.

Somebody could put their own public key in your keyring, assign that
Ultimate trust, and then certify another public key they wish to pop up
as valid. Ultimately trusted keys make other keys valid by their
certification. There is no way to see any difference between a key that
is fully valid because your own ultimately trusted key signed it or
because the attackers ultimately trusted key signed it. And since the
ultimately trusted key of the attacker isn't the one doing data
signatures, your "alternative colour" will not trigger.

There is *no* *way* to mitigate an attacker having your user privileges.

> Am i correct that
> even with a modified database TOFU would tell me, wait there
> is already one key (the original one) on a key server and this
> one is not the correct one.

No, the attacker could simply modify your database so it sees what it
expects to see, or put a little shell wrapper around the gpg binary that
filters out anything suspicious. Or do any of an infinite number of
nasty things.

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/20170630/4c4b6f49/attachment.sig>

From guilhem at fripost.org  Fri Jun 30 19:03:18 2017
From: guilhem at fripost.org (Guilhem Moulin)
Date: Fri, 30 Jun 2017 19:03:18 +0200
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: <20170630170318.vlt4me6wshfjehkh@localhost.localdomain>

On Fri, 30 Jun 2017 at 18:29:41 +0200, Peter Lebbing wrote:
> It would be really good if the SSH agent protocol would be extended to
> communicate on which tty a request comes in. Without updates to the SSH
> protocol, there is simply no way to know where it comes from.

I also hope some day this will happen :-)
 
> 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 :-).

Another other (somewhat ugly) hack is to define a ProxyCommand in your
ssh_config(5) file.

    ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && nc "$0" "$1"' %h %p

That one is particularly ugly as children are kept alive during the whole
time of the SSH session (and file descriptors are wasted for the pipe
and the socket):

    ssh example.net
      ??sh -c gpg-connect-agent updatestartuptty /bye >/dev/null && nc "$0" "$1" example.net 22
          ??nc odin.guilhem.org 22

With recent OpenSSH and OpenBSD's implementation of nc(1)
(netcat-openbsd package on Debian) it's possible to have the
ProxyCommand pass the connected socket back to ssh and exit, so there is
no wasted ressource during the session:

    ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && nc -F "$0" "$1"' %h %p
    ProxyUseFDpass yes

Still, it's unfortunate to have to fork a shell just for that.  I wrote
a little C wrapper (to call the Assuan command, connect to the remote
host, pass the descriptor, and exit) some time ago, but clearly the
proper fix is to extend the SSH agent protocol.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </pipermail/attachments/20170630/028ec1f5/attachment.sig>

From stefan.claas at posteo.de  Fri Jun 30 20:01:50 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Fri, 30 Jun 2017 20:01:50 +0200
Subject: TOFU
In-Reply-To: <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
Message-ID: <3wzkr84Kfjz10HC@submission01.posteo.de>

On Fri, 30 Jun 2017 18:38:45 +0200, Peter Lebbing wrote:

> Somebody could put their own public key in your keyring, assign that
> Ultimate trust, and then certify another public key they wish to pop
> up as valid. Ultimately trusted keys make other keys valid by their
> certification. There is no way to see any difference between a key
> that is fully valid because your own ultimately trusted key signed it
> or because the attackers ultimately trusted key signed it. And since
> the ultimately trusted key of the attacker isn't the one doing data
> signatures, your "alternative colour" will not trigger.

Correct. But what i mean was an attacker would replace on of my pub
keys (which i signed) with one he/she only replaced with one that
has only the Trust Level set to Ultimate, resulting in both keys
showing up with a green bar.

According to (i'm no programmer) RFC 4880 OpenPGP Message Format:

https://tools.ietf.org/html/rfc4880

5.2.3.13.  Trust Signature      	Page 30

5.10.      Trust Packet (Tag 12)	Page 47

Those are imho two different things and therefore should not be
handled with the same color output.

Regards
Stefan




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170630/9399fbd0/attachment-0001.sig>

From peter at digitalbrains.com  Fri Jun 30 20:35:48 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 30 Jun 2017 20:35:48 +0200
Subject: TOFU
In-Reply-To: <3wzkr84KMCzyqC@submission01.posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net> <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
 <3wzkr84KMCzyqC@submission01.posteo.de>
Message-ID: <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>

On 30/06/17 20:01, Stefan Claas wrote:
> Correct. But what i mean was an attacker would replace on of my pub
> keys (which i signed) with one he/she only replaced with one that
> has only the Trust Level set to Ultimate, resulting in both keys
> showing up with a green bar.

And to mitigate this situation, you proposed to colour ultimately trusted keys
differently when they are used to sign a message. You proposed this several
times in different messages.

So let's say your key is A, it's ultimately trusted. And you verified someone's
key and signed it; this is key B. Data signatures by key B show up as valid with
a green background.

Now consider the attacker. You say: he could inject key C, assign ultimate trust
to key C and send me messages signed by key C. They would show up as valid. You
want them to have a different colour.

But instead of that, the attacker could also inject key C into your public
keyring and assign ultimate trust to it, and use this key C to certify another
key D. The attacker then sends messages signed by key D, and since this key is
certified by an ultimately trusted key (C), they will show up as valid with a
green background.

As key A made data signatures by key B valid and green, key C makes data
signatures by D valid and green. The situation is the same.

> 5.2.3.13.  Trust Signature      	Page 30

Let's not get into trust signatures, they are a different beast entirely and not
pertinent to this discussion. It would just make it even more complicated, and
we're having some communication hurdles already. Trust signatures are used to
delegate what you normally do by ownertrust to another person, which is
sometimes used inside organizations.

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/20170630/c522aab7/attachment.sig>

From stefan.claas at posteo.de  Fri Jun 30 20:54:32 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Fri, 30 Jun 2017 20:54:32 +0200
Subject: TOFU
In-Reply-To: <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
 <3wzkr84KMCzyqC@submission01.posteo.de>
 <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>
Message-ID: <3wzm0w6GRHz10HG@submission01.posteo.de>

On Fri, 30 Jun 2017 20:35:48 +0200, Peter Lebbing wrote:
> On 30/06/17 20:01, Stefan Claas wrote:
> > Correct. But what i mean was an attacker would replace on of my pub
> > keys (which i signed) with one he/she only replaced with one that
> > has only the Trust Level set to Ultimate, resulting in both keys
> > showing up with a green bar.  
> 
> And to mitigate this situation, you proposed to colour ultimately
> trusted keys differently when they are used to sign a message. You
> proposed this several times in different messages.
> 
> So let's say your key is A, it's ultimately trusted. And you verified
> someone's key and signed it; this is key B. Data signatures by key B
> show up as valid with a green background.
> 
> Now consider the attacker. You say: he could inject key C, assign
> ultimate trust to key C and send me messages signed by key C. They
> would show up as valid. You want them to have a different colour.
> 
> But instead of that, the attacker could also inject key C into your
> public keyring and assign ultimate trust to it, and use this key C to
> certify another key D. The attacker then sends messages signed by key
> D, and since this key is certified by an ultimately trusted key (C),
> they will show up as valid with a green background.
> 
> As key A made data signatures by key B valid and green, key C makes
> data signatures by D valid and green. The situation is the same.

Good point! And what would be your proposal against this kind of
attack? :-) For me it is a) bad software design, with the same colors
for two different functions and b) also not good that Trust Levels can
be assigned (via third party apps) without entering my passphrase.

Regards
Stefan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170630/069e3aed/attachment.sig>

From peter at digitalbrains.com  Fri Jun 30 21:02:38 2017
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 30 Jun 2017 21:02:38 +0200
Subject: TOFU
In-Reply-To: <3wzm0w6GTWz10HJ@submission01.posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net> <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
 <3wzkr84KMCzyqC@submission01.posteo.de>
 <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>
 <3wzm0w6GTWz10HJ@submission01.posteo.de>
Message-ID: <e26b82b6-6ddf-e543-b18e-e3d2206ce1be@digitalbrains.com>

On 30/06/17 20:54, Stefan Claas wrote:
> Good point! And what would be your proposal against this kind of
> attack?

On 30/06/17 18:38, Peter Lebbing wrote:
> There is *no* *way* to mitigate an attacker having your user privileges.


> :-) For me it is a) bad software design, with the same colors
> for two different functions

There is no difference between your ultimately trusted key and someone else's
ultimately trusted key. It's the same function.

> and b) also not good that Trust Levels can
> be assigned (via third party apps) without entering my passphrase.

There is nothing to protect here. Trust has to start somewhere, there has to be
a root of it all where you say "this is where it all starts". Your passphrase
allows you to make signatures. What's the difference between your signature and
the attacker's signature? They're both signatures, on your disk. On a system
which is, in your scenario, compromised. Please, there is *no* *way* to mitigate
an attacker having your user privileges. As far as your computer is concerned,
they *are* you. You're asking your computer to tell the difference between you
and you. The problem is that we started out with the premise that your computer
thinks your attacker is you. And then you're trying to think of solutions to
have your computer tell the difference. That's begging the question.

Peter.

PS: As a final note, what prevents your attacker from grabbing your passphrase
when you enter it? They control your computer! If you could use your passphrase
to verify it was really you, they would immediately also have that passphrase,
since you just gave it to them.

-- 
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/20170630/01d4c17b/attachment.sig>

From stefan.claas at posteo.de  Fri Jun 30 21:27:18 2017
From: stefan.claas at posteo.de (Stefan Claas)
Date: Fri, 30 Jun 2017 21:27:18 +0200
Subject: TOFU
In-Reply-To: <e26b82b6-6ddf-e543-b18e-e3d2206ce1be@digitalbrains.com>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net>
 <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
 <3wzkr84KMCzyqC@submission01.posteo.de>
 <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>
 <3wzm0w6GTWz10HJ@submission01.posteo.de>
 <e26b82b6-6ddf-e543-b18e-e3d2206ce1be@digitalbrains.com>
Message-ID: <3wzmkm00fTz10Hd@submission01.posteo.de>

On Fri, 30 Jun 2017 21:02:38 +0200, Peter Lebbing wrote:

> PS: As a final note, what prevents your attacker from grabbing your
> passphrase when you enter it? They control your computer! If you
> could use your passphrase to verify it was really you, they would
> immediately also have that passphrase, since you just gave it to them.

The idea with this scenario is that it can be carried out by people
with no skills in hacking or compromising a computer, in small shops,
companies for example, when one of the co-workers leaves his/her
work place for a minute, or two etc.

P.S. Maybe it was not such a bad idea to propose identicons, for
third party apps using GnuPG, along with showing the fingerprint.

Regards
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: </pipermail/attachments/20170630/3def11dd/attachment.sig>

From andrewg at andrewg.com  Fri Jun 30 22:29:21 2017
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 30 Jun 2017 21:29:21 +0100
Subject: TOFU
In-Reply-To: <3wzmkm00fTz10Hd@submission01.posteo.de>
References: <f134094f-a69c-2d84-f706-2f3b09a875ab@posteo.de>
 <bb36f6b8-9242-6490-4bc2-218f0c29c723@posteo.de>
 <57f4fb3a-d939-602b-4462-1891409b8c41@digitalbrains.com>
 <3186a30f-e7fd-d0b7-9fc1-c4f88d7193a8@digitalbrains.com>
 <0aaa9014-c44b-26ea-b7ee-405adc74f001@posteo.de>
 <e0fee1c5-55f1-5250-275b-ad88e11d5490@digitalbrains.com>
 <60cd494d-c528-1f1c-4f19-2b1065219d98@posteo.de>
 <9ed29262-3e55-296d-068a-143210f64ac4@digitalbrains.com>
 <3wtCvm4n8Kz10HD@submission01.posteo.de>
 <ffb9b23c-b01b-44d0-3a75-6e5e474de196@digitalbrains.com>
 <1873229282.20170623020719@riseup.net> <87o9tcym5y.wl-neal@walfield.org>
 <3wwjJw5ZNqzyth@submission01.posteo.de>
 <e907b241-df87-bc45-a517-f64bc247bdb8@digitalbrains.com>
 <3wzkr84KMCzyqC@submission01.posteo.de>
 <64cd4d9a-78cb-03a8-3530-8afd7bc48a5c@digitalbrains.com>
 <3wzm0w6GTWz10HJ@submission01.posteo.de>
 <e26b82b6-6ddf-e543-b18e-e3d2206ce1be@digitalbrains.com>
 <3wzmkm00fTz10Hd@submission01.posteo.de>
Message-ID: <9e5ac5d0-3f8c-abe2-4979-c40ae847d2f6@andrewg.com>

On 2017/06/30 20:27, Stefan Claas wrote:
> The idea with this scenario is that it can be carried out by people
> with no skills in hacking or compromising a computer, in small shops,
> companies for example, when one of the co-workers leaves his/her
> work place for a minute, or two etc.

Anybody who knows enough about computers to poison your local GPG
keyring already knows more than enough about computers to be able to
download H at ck0rT00l.exe from a website and install it on your machine.
In the scenario above, it is in fact *easier* to do this without getting
caught than it is to do it by hand - perhaps as easy as inserting a
flash drive when your computer is locked.

If you want to protect yourself against an Evil Maid (or an Evil
Coworker) then you are *way* outside the scope. Encrypt your drive, lock
your screen, disable your USB ports and store your laptop in a safe. If
you can't trust the data on your computer, you can't trust a single
thing it says.

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/20170630/3c94cf9c/attachment.sig>

From dkg at fifthhorseman.net  Fri Jun 30 23:26:27 2017
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 30 Jun 2017 14:26:27 -0700
Subject: [HELP] pinentry-curses breaks SSH auth,
 but pinentry-mac works fine?
In-Reply-To: <20170630035446.lfjxtbmbqpdwohah@liberte>
References: <20170630035446.lfjxtbmbqpdwohah@liberte>
Message-ID: <87bmp59ngc.fsf@fifthhorseman.net>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170630/8b742b13/attachment-0001.sig>