From dougb at dougbarton.email  Thu Jan  1 00:19:07 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Wed, 31 Dec 2014 15:19:07 -0800
Subject: The praise of GnuPG @31C3
In-Reply-To: <54A41C5B.3050507@josuttis.de>
References: <54A41C5B.3050507@josuttis.de>
Message-ID: <54A4846B.9030102@dougbarton.email>

The death of IPsec has been greatly exaggerated:

https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/


From dougb at dougbarton.email  Thu Jan  1 00:33:46 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Wed, 31 Dec 2014 15:33:46 -0800
Subject: The praise of GnuPG @31C3
In-Reply-To: <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
 <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
Message-ID: <54A487DA.9000708@dougbarton.email>

On 12/31/2014 3:25 PM, mark hellewell wrote:
> And the ?ssh is broken? remark strikes me as a little dramatic, too.

Well I've seen vague references to some of the "less secure" settings 
being vulnerable, but I've yet to see, "everything below this line is 
vulnerable, everything above this line is thought to be safe."

If anyone has a reference ...

Doug



From mark.hellewell at gmail.com  Thu Jan  1 00:25:18 2015
From: mark.hellewell at gmail.com (mark hellewell)
Date: Thu, 1 Jan 2015 10:25:18 +1100
Subject: The praise of GnuPG @31C3
In-Reply-To: <54A4846B.9030102@dougbarton.email>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
Message-ID: <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>

On 1 January 2015 at 10:19, Doug Barton <dougb at dougbarton.email> wrote:
> The death of IPsec has been greatly exaggerated:
>
> https://nohats.ca/wordpress/blog/2014/12/29/dont-stop-using-ipsec-just-yet/


And the ?ssh is broken? remark strikes me as a little dramatic, too.


From s.murthy at mykolab.com  Thu Jan  1 02:26:29 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Thu, 1 Jan 2015 01:26:29 +0000
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <PYKPceAr7BhQ6z2ucqxrTZ59wNaChsgT1sBTkO9PhVQ@local>
References: <PYKPceAr7BhQ6z2ucqxrTZ59wNaChsgT1sBTkO9PhVQ@local>
Message-ID: <7436F0C5-61A9-46DA-85FF-F78401BD5D71@mykolab.com>

I agree, this output is not user friendly at all, but did you try instead

   `$ gpg ?edit-key <key ID>

which should start the `gpg` program (interactive environment
with the `gpg>` prompt, and then you do

   `gpg> fpr`

to display the fingerprint.

The problem with commands of this type

    `gpg ?<option> <key file>`,

is that it is calling on the key file on your computer, and this
is a static reference which could cause problems with file
permissions or if the file has been moved, renamed, corrupted,
damaged, or deleted.  It is better to use the <key ID> because
that doesn?t change whatever happens to your local key file
copy.

I reproduce the `gpg` session with my public key for my keybase.io
email below:

[srm@~]$gpg --edit-key 9EAB92B4
gpg (GnuPG/MacGPG2) 2.0.26; Copyright (C) 2013 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.


pub  4096R/9EAB92B4  created: 2014-12-30  expires: never       usage: SCEA
                     trust: ultimate      validity: ultimate
sub  2048R/238026C5  created: 2014-12-30  expires: 2022-12-28  usage: S
sub  2048R/66C9185A  created: 2014-12-30  expires: 2022-12-28  usage: E
[ultimate] (1). keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>

gpg> fpr
pub   4096R/9EAB92B4 2014-12-30 keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>
 Primary key fingerprint: AE7B 5571 64AF 1025 AF89  4180 6EA7 1DBC 9EAB 92B4

Sandeep Murthy
s.murthy at mykolab.com


> On 30 Dec 2014, at 09:49, Kelly Dean <kelly at prtime.org> wrote:
> 
> # gpg key.gpg
> pub  2048D/7FBDEF9B 2014-09-24 GNU ELPA Signing Agent <elpasign at elpa.gnu.org>
> # gpg key.gpg --fingerprint
> usage: gpg [options] [filename]
> # gpg --fingerprint key.gpg
> gpg: error reading key: public key not found
> # man gpg
> # mkdir tmp
> # cp key.gpg tmp/pubring.gpg
> # gpg --fingerprint --homedir tmp/
> gpg: WARNING: unsafe permissions on homedir `tmp/'
> gpg: tmp//trustdb.gpg: trustdb created
> tmp//pubring.gpg
> ----------------
> pub   2048D/7FBDEF9B 2014-09-24 [expires: 2019-09-23]
>      Key fingerprint = CA44 2C00 F917 74F1 7F59  D9B0 474F 0583 7FBD EF9B
> uid                  GNU ELPA Signing Agent <elpasign at elpa.gnu.org>
> 
> # rm tmp/ -r
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150101/87683949/attachment.sig>

From rjh at sixdemonbag.org  Thu Jan  1 03:30:05 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 31 Dec 2014 21:30:05 -0500
Subject: photo-ID
In-Reply-To: <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
Message-ID: <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>

> I don?t agree.

With what?

> Why isn?t the photo ID feature not useful?

I never said it wasn?t.

I said the photo ID feature, *as used within OpenPGP certificates*, isn?t.  There?s a big difference there.

Frankly, the possibility of allowing arbitrarily-sized binary blobs to be attached to OpenPGP certificates scares the ever-living bloody f*ck out of me.  (I try to avoid vulgarity, but I?m using it here to underline just how critical this problem is.)  The keyserver network, as currently configured, is susceptible to a total worldwide denial-of-service attack that can be conducted by just one malicious individual who figures out how to turn the photo ID feature into an attack vector.

I?ve discussed this attack vector on the keyserver mailing list.  The general consensus is that the attack that I?m concerned about is real, and would result in serious disruption to the global keyserver network for an extended period until we developed countermeasures ? but those countermeasures would fundamentally transform the keyserver network and force us to radically redefine our expectations of service.

So, yeah.  Photo IDs on OpenPGP certificates is really another way of saying ?OpenPGP supports putting arbitrarily-sized binary blobs on certificates that will be replicated worldwide and, depending on local jurisdictions, will immediately convert keyserver operators into felons.?  That?s enough for me to declare the entire OpenPGP implementation of photo IDs a staggering clusterf*ck of failure, and something that I really wish would get dropped from the OpenPGP spec.

(I?m not going into specifics about the attack because I don?t want to give anyone ideas, not in any expectation that it really matters a damn.  My write-up is available, but I?m not going to help you find it.)


> Surely any piece of
> information that would help another person, with whom you
> are proposing to communicate, to identify you first, is a good
> thing.

Sure, but it would be nice if it didn?t expose people to phenomenal risk while we?re at it.

We have better ways of doing photo IDs ? e.g., keybase.io.  I think we should use them.

You?re arguing against something I never said and don?t believe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20141231/42103fdc/attachment.bin>

From rjh at sixdemonbag.org  Thu Jan  1 03:40:01 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 31 Dec 2014 21:40:01 -0500
Subject: The praise of GnuPG @31C3
In-Reply-To: <54A487DA.9000708@dougbarton.email>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
 <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
 <54A487DA.9000708@dougbarton.email>
Message-ID: <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>

> If anyone has a reference ...

Not a reference, but some history ?

Microsoft?s point-to-point tunneling protocol version 1.0 was a miserable failure.  Version 2.0 closed up many of those holes and was widely regarded as secure, except for a configuration option which was on by default: ?Enable backwards compatibility.?  So to exploit a PPTP 2.0 connection, you just had to connect and give it a 1.0 handshake, at which point it would fall back into an insecure mode.

The protocol was secure: you just had to configure it correctly.  The server was correctly implemented.  It?s just that it was shipped in a completely broken state, most system administrators didn?t know it and/or didn?t check it, and as a result it was pretty much useless.

A secure protocol must be used correctly in order to provide communications security.  Too often people completely lose sight of that and don?t even introduce it into their discussions.  So ? discuss.  If you use ssh and trust it, how do you know that you?re using it correctly?  How do you know the people who connect to your system are?  Etc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20141231/a925c15f/attachment.bin>

From rjh at sixdemonbag.org  Thu Jan  1 03:46:53 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 31 Dec 2014 21:46:53 -0500
Subject: The praise of GnuPG @31C3
In-Reply-To: <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
 <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
 <54A487DA.9000708@dougbarton.email>
 <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>
Message-ID: <36ABA742-57E1-49C5-A4F5-FDA8FF222F2E@sixdemonbag.org>

> Microsoft?s point-to-point tunneling protocol version 1.0 was a miserable failure.  Version 2.0 closed up many of those holes and was widely regarded as secure, except for a configuration option which was on by default: ?Enable backwards compatibility.?  So to exploit a PPTP 2.0 connection, you just had to connect and give it a 1.0 handshake, at which point it would fall back into an insecure mode.

https://www.schneier.com/paper-pptpv2.html

Check section 5.1, ?Version rollback attacks?.  Full details there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20141231/4b925773/attachment-0001.bin>

From rjh at sixdemonbag.org  Thu Jan  1 03:58:59 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 31 Dec 2014 21:58:59 -0500
Subject: photo-ID
In-Reply-To: <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
 <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
Message-ID: <204FC881-22C5-4B87-B927-3EAB85A69B1D@sixdemonbag.org>

> I?ve discussed this attack vector on the keyserver mailing list.  The general consensus is that the attack that I?m concerned about is real, and would result in serious disruption to the global keyserver network for an extended period until we developed countermeasures ? but those countermeasures would fundamentally transform the keyserver network and force us to radically redefine our expectations of service.

Before people think I?m overreacting ?

A few years ago we lost an Austrian keyserver to, of all things, EU data privacy laws.  Think about the irony of that: a tool meant to help safeguard individual privacy got shut down by a single individual who invoked EU data privacy laws to get rid of a tool that helps data privacy.

A user uploaded their certificate to a keyserver, and that certificate soon propagated around the net.  The user then decided they didn?t want their email address published like that, and invoked a right under EU law to require the keyserver operator to delete his email address.  The keyserver operator was unable to do this due to the way the keyserver network works ? if he?d complied, the certificate just would have resynced a minute later.  The only way to support this EU data privacy provision was to allow the global network to drop certificates, and the global network has as a design goal that certificates *cannot* be dropped, in order to protect the integrity of the database against deliberate attack.

The keyserver operator received legal advice saying that continuing to operate his keyserver exposed him to significant legal risk.  So, without any real other alternatives, he did the only thing he could under the EU data privacy law and took his keyserver offline.

It is cheap and easy to take down any keyserver in the EU; just do what this user did.

The keyserver network is an important part of the OpenPGP ecosystem, and it?s nowhere near as robust as we like to imagine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20141231/0fe3e80e/attachment.bin>

From nicholas.cole at gmail.com  Thu Jan  1 13:01:02 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Thu, 1 Jan 2015 12:01:02 +0000
Subject: photo-ID
In-Reply-To: <204FC881-22C5-4B87-B927-3EAB85A69B1D@sixdemonbag.org>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
 <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
 <204FC881-22C5-4B87-B927-3EAB85A69B1D@sixdemonbag.org>
Message-ID: <CAAu18heFGjMnZQmTRx8a_vLZW373gYL8V_+UHcxqkpHDoYWLrQ@mail.gmail.com>

On Thursday, 1 January 2015, Robert J. Hansen <rjh at sixdemonbag.org> wrote:

> > I?ve discussed this attack vector on the keyserver mailing list.  The
> general consensus is that the attack that I?m concerned about is real, and
> would result in serious disruption to the global keyserver network for an
> extended period until we developed countermeasures ? but those
> countermeasures would fundamentally transform the keyserver network and
> force us to radically redefine our expectations of service.
>
> Before people think I?m overreacting ?
>

No. It is a realistic attack. Key servers might legitimately strip photo
ids if it were ever a problem, IMHO.

But in fact, a UID packet can contain arbitrary data anyway, can't it?
Isn't that just the same problem.

N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150101/9bc8c1bb/attachment.html>

From s.murthy at mykolab.com  Thu Jan  1 14:33:38 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Thu, 1 Jan 2015 13:33:38 +0000
Subject: photo-ID
In-Reply-To: <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
 <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
Message-ID: <702A2B4C-3A96-49EC-8A1B-C9B65CF4C956@mykolab.com>

Hi

Sorry if I misunderstood, but I didn?t say that the photo ID should
be allowed to be as large as possible, and this is not allowed anyway
by, for example, apps like GPG Keychain.

But I was wondering ? instead of attaching a photo to a public key,
why not attach a hash of the photo using an image hashing
algorithm?  I don?t know much about image hashing (but this
discussion has now made me more curious to learn) but such an
algorithm is supposed to calculate a hash value for an image that
could be compared against **perceptually similar** images.  Since this will
be a string it would not lead to the blob attack scenario described before.

I found some interesting resources including a paper describing some
algorithms

http://www.phash.org/docs/pubs/thesis_zauner.pdf

and there are also several API implementations

    http://www.phash.org/ (C++)
    https://pypi.python.org/pypi/ImageHash (Python).

Would it not be possible for gpg to incorporate these so that a user
can attach a set of hash values for their photo(s) to their public key that
recipients could check against some other source?

Sandeep Murthy
s.murthy at mykolab.com





> On 1 Jan 2015, at 02:30, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> I don?t agree.
> 
> With what?
> 
>> Why isn?t the photo ID feature not useful?
> 
> I never said it wasn?t.
> 
> I said the photo ID feature, *as used within OpenPGP certificates*, isn?t.  There?s a big difference there.
> 
> Frankly, the possibility of allowing arbitrarily-sized binary blobs to be attached to OpenPGP certificates scares the ever-living bloody f*ck out of me.  (I try to avoid vulgarity, but I?m using it here to underline just how critical this problem is.)  The keyserver network, as currently configured, is susceptible to a total worldwide denial-of-service attack that can be conducted by just one malicious individual who figures out how to turn the photo ID feature into an attack vector.
> 
> I?ve discussed this attack vector on the keyserver mailing list.  The general consensus is that the attack that I?m concerned about is real, and would result in serious disruption to the global keyserver network for an extended period until we developed countermeasures ? but those countermeasures would fundamentally transform the keyserver network and force us to radically redefine our expectations of service.
> 
> So, yeah.  Photo IDs on OpenPGP certificates is really another way of saying ?OpenPGP supports putting arbitrarily-sized binary blobs on certificates that will be replicated worldwide and, depending on local jurisdictions, will immediately convert keyserver operators into felons.?  That?s enough for me to declare the entire OpenPGP implementation of photo IDs a staggering clusterf*ck of failure, and something that I really wish would get dropped from the OpenPGP spec.
> 
> (I?m not going into specifics about the attack because I don?t want to give anyone ideas, not in any expectation that it really matters a damn.  My write-up is available, but I?m not going to help you find it.)
> 
> 
>> Surely any piece of
>> information that would help another person, with whom you
>> are proposing to communicate, to identify you first, is a good
>> thing.
> 
> Sure, but it would be nice if it didn?t expose people to phenomenal risk while we?re at it.
> 
> We have better ways of doing photo IDs ? e.g., keybase.io.  I think we should use them.
> 
> You?re arguing against something I never said and don?t believe.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150101/9d8e89cc/attachment.sig>

From johanw at vulcan.xs4all.nl  Thu Jan  1 16:33:38 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Thu, 01 Jan 2015 16:33:38 +0100
Subject: photo-ID
In-Reply-To: <702A2B4C-3A96-49EC-8A1B-C9B65CF4C956@mykolab.com>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
 <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
 <702A2B4C-3A96-49EC-8A1B-C9B65CF4C956@mykolab.com>
Message-ID: <54A568D2.10603@vulcan.xs4all.nl>

On 01-01-2015 14:33, Sandeep Murthy wrote:

> Sorry if I misunderstood, but I didn?t say that the photo ID should
> be allowed to be as large as possible, and this is not allowed anyway
> by, for example, apps like GPG Keychain.

Huge size would not be the only problem. Wait until the first person
uploads a key with a child porn image as photo-id, and then wildly posts
"to download this child porn image, get GnuPG and download key
0x12345678. It might even be done by someone who deliberately wishes to
get all keyservers offline.

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



From linuxdebian at zoho.com  Thu Jan  1 18:10:48 2015
From: linuxdebian at zoho.com (Linux Debian)
Date: Thu, 01 Jan 2015 17:10:48 +0000
Subject: Updating public key problem
In-Reply-To: <mailman.18499.1420080307.28939.gnupg-users@gnupg.org>
References: <mailman.18499.1420080307.28939.gnupg-users@gnupg.org>
Message-ID: <54A57F98.3070503@zoho.com>

Hi guys,


  I've updated my GnuPG key and send to keyservers.
What I updated ?
I've just deleted 2 expired subkeys and added one with a longer (in
2015) expiration.
But as I can see in a keyserver -
http://pgpkey.org/pks/lookup?op=vindex&search=0x5935a6bfb301c1aa2218e0e57d58bae0dbeb2b6a&fingerprint=on

those 2 expired subkeys still appear and that's why, in my opinion, why
the sending an encrypted message doesn't work by the free service like -
https://encrypt.to/linuxdebian at zoho.com
Before the expirationd date of those 2 keys, the encrypt.to service worked.

Try to send me an e-mail via encrypt.to
or compare the publick key information with the attached (updated).
If the attachment is not included, I add the the ASCII format below.

Thanks for any tip how to correctly update or what to do, so my public
key would be possible to be used by encrypt.to for those who wanna send
me a private message.

Btw, I use Debian Wheezy, KDE, 32b., mostly Kgpg app or CLI gpg commands.


My updated public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

mQSuBFJqGJkRDACUayLdZH0RMZI/sFAqW4w9pjR8FEtkhEZ2RUzfPjxhDGLk2VvA
WiIk5hEJ7KL0BSCaBFrB319xl4LH0/QeBTzyaG4AnH2D1jlDbO8pM5OsL8T+ukF5
jb63nn3GOls8H7Rm2dLWdEB0e/UDVhzORment1yTYzeGsN1nL5+oh1KOmFBJoD2A
rKyE58Yw642SFEc/vO0S9+gKvytB8YFnpFuvaeDil2l0/z0sELQ2JHb/Li0I58NZ
Wduw8Se6WDVMILjPdffV8amspVuwids/1nRGN4yQMkh0lNszfVw3Y+uyKvHbAy32
6vyl/xnppv3cfS9onk5Eoo+aUVj10i9g2tsl2RpdZQ7lsdlwZkYtdXcIdgE7cmtV
RohwEwZA7AN8yVsi04Ka8H3zQAxcYyGvY3LlqmgRi5gt6Lh3hjpk0gyuSgKS690a
C1A8sfbhIwzoUIHc6YaHxnY6HgxGoP/0rOrrX3lt1QWgp2gqeiLff6SQ2InsdBNS
08X3mdOjwD+yX18BANRVgY3JuF8BhcCvdgS06upQDjAIRtzZnnyKUiQYAIDjC/4k
qy/lrRT2m0ZaXU6L2PWJaqESS0pNviy2izASwgslHOhEzagdMCnoWmJiGS3/8JZr
yv04mTueSsEjoX58uWMIhQBzlyH+t/16lI/t9MHkXxllG8rwsAhU/4AWAr2zeSrX
G8qxLpWLMD6rSk3tLy84SnLoFRCtvSNTtC6pNYelanUOcJDD6QYhSbIn9E2sqqbn
OON59Do0dRvoX1oIoDLwcaAOP4RH4Tcy/fsqlxy6BPBchp/S4KqejvFo1RuCGF0T
c52sbJGkWuxHfcdn4uufYHKWN106G2F9nKmjbSXj12qtJZKwM1ZZ8IbKfkW/5/SO
axxbzL7sl96cZRAXc7YGmgCZ0rcWBMtNFcIDqrG8VJzVFXqCb+LCr9eWfbNlRK1v
ATRGIGi/768mSNOh4Nwxdo0KL06Rp4BKM/huVkrtHurxbcjTtfa7V5ZECn7pJMvU
kaJcV4J0czVJpZEVng/z1Thl6Jbf9QthY+hBXm/Sx7TGDQUpToWVvZ1ay7Z5B4YL
/0/8DFRb/FpPee7bfTaqJvUeiH8lcCiPyHcst14vu3rcGLwfPhGHT/QNtHhUHlGy
faNnCyUuu1D6WEXF9Ta/zj8HDsj4u/z9za6Hzhb/JfSu9qnhDwQ3M4zOBl9ECWNn
KTxK8jUMWbe+f7Euqd3k5rFehipFmCzSqYkZfZZM5qSC7PBW9RuA7uPrFNreGwiZ
x+/nV/1sFL7dzwp2uVtigdGtTbyCfRkb0zEtezOOAq3vSeuj2SuFRkkGsXG49jZ2
s4eHWolfZEXanUne4eqo8P2IIt4dwc5MMz2aSYjE1KX4Ie7OUTlsSsTyLqe1UX+h
6xaUjG7+6FLX9i+dA46lsI3DOcorRcLRuSGDvDV+i/EeoSrViwZfAEYU68QNTG2W
9RSeR85KhVacRWyY7icDMaN1raDVmvevqDrSzEfzu1fj34nIdF76gLTSTOh9LXLC
c1HlZYDcwq0bmNCDMmMjxnHUYZse/tcI1Q1B+YUpt5NLwm3x0fh4S+AhejcLl28H
urQ7TGludXggREVCSUFOIChodHRwOi8vd3d3LmRlYmlhbi5vcmcpIDxsaW51eGRl
YmlhbkB6b2hvLmNvbT6IgAQTEQgAKAIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC
F4AFAlOu2qoFCQI5+REACgkQfVi64NvrK2rZKwEAiJmTIhVk9wYhcJwJ6PmrW1wx
Yt56ojizFYxA4Ik5/PkBAIxCjFCSyDfg8oRPNrPAY0I0/wRu19EMu1kOoRjYtZmA
iIAEExEIACgFAlJqGJkCGyMFCQHanAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA
AAoJEH1YuuDb6ytq9QMA/2fGHFWy5Fhr0Lbccot8LtNjJTVfveJLLul353p6Or3K
AQCCntbctT8OLKbDu1dsGRbYTuU3hI5JGMzNf24qgZuZaYiABBMRCAAoAhsjBgsJ
CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVJSDdgUJAsie3QAKCRB9WLrg2+srahhl
AQCZ1G3cbpboy034FE7dx4bMtqeUFokI+a68Ms3IQ+M6zwD7Bd7FxOeFt7pviwPV
Z1biodx39oBX646Cnaom4IJNANzR1eHV3wEQAAEBAAAAAAAAAAAAAAAA/9j/4AAQ
SkZJRgABAQEASABIAAD/4QkZRXhpZgAATU0AKgAAAAgAAAAAAA4AAgIBAAQAAAAB
AAAALAICAAQAAAABAAAI5QAAAAD/2P/gABBKRklGAAEBAAABAAEAAP/bAEMADwoL
DQsJDw0MDREQDxEWJRgWFBQWLSAiGyU1Lzg3NC80MztCVUg7P1A/MzRKZEtQV1pf
YF85R2hvZ1xuVV1fW//bAEMBEBERFhMWKxgYK1s9ND1bW1tbW1tbW1tbW1tbW1tb
W1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW//AABEIAGQAUQMBIgAC
EQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMD
AgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKC
CQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK
0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAA
AAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR
B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RF
RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1
9vf4+fr/2gAMAwEAAhEDEQA/APRKKKKACuV1zxnBZSPb2CCeZTgyE/Iv+NJ401w2
9gLO2ZknnJV+zKoOP17e1Z3h3wY0wiu9TwsZ+YW+OWH+16fSok23aJ3UKNOMPa1t
ui7mP9v1zWrhjFJdSkdViJVR+A4q6sfi2Jdyi8GOeua9AtbS3tIvLtoUiTOdqLip
6XI+5UsctowVjz+38banZusN7bJIVPz7lKPj+X6V1+j6zaaxbebbNhh9+NvvKfem
63ottrNqY5lCygHy5R1U/wCFedWkt7oGt4RG86F9rov8Y7j6YovKD11RUadLFQbg
uWSPWKKjgmWe3jmjzskUMufQjNSVoeba2gUUUUAFMlz5T4badpw3p70+o5ziCQ+i
k/pQNbnB+HYX13xbPqE6h4YmL4YceiD+v4V6BXI/DxP9CvHI6ygD8q62ohtc6cZK
9Xl6LQy9Z1GaB4bGwUNe3Odm77sajq59hUMOg3HElxrN+8/UlJdqD/gPSobeTHju
6jl6m0Tys9hnnH410Bq9zOTdNJLtchtY5o4tlxKJWB4fGCR7j1rivHEf2PxBZXkR
2s6gkjrlW/wIFdosiS3jIC+6AfN1C8/zrj/GCjU/EdlZRneI0JlC/wAAJyf0FRPY
2wbarXfZ3O0gQRwIgxtUYXHTHb9KfQowoGMYHT0pas4wooooAKa6hkKnoRg06igD
jfAEjRTahZScNG4O09QckH+VdlXnfieG40PxN9utnaJLg+YGX143A+vr+NegQSrN
BHKpBV1DAjvmoh/L2OvFRu1VW0jl/E9rf2+pJq9quWt8bWXoFxyGHpnPPv7VPbeK
NI1K2UXkptpAcsjEgZHoR1FdIeRis+bQ9PmbcbdVJOTs4B/Cqt2JVWEoqM1qtmjL
vPFiSn7Podu99cNwCFIVfc1PoGhPZtNeag6zXtyQXYD7vsK2YLeK2jCQoqKOyjFS
0W7kOqlFxgrJ/ewooopmIUUUUAFFFIaAM7XtJj1jTntnIV/vRvj7rVg+FtXk06U6
Jq2IZIjiFmPUE9P8K6+s3WtEtNZh2XCYkX7kq/eWk1rdG9OquX2c/h/I0qK52z/t
zR5BFcJ/aFkowrxY81R7g9a3LW6FypYRSx47SoVP600Zzhy7O6JqKWiggKKKKACi
iigAoorA8WeJh4chgb7K05nLBSGwARjr+dAG/RTY23Rqx4yAao69qg0XSZb9oGmW
LG5VODgkDP60AaFJWd4d1Q61osGoGLyvOL4TOcAMR/SoPE+p3el6estnb+azOAWI
yE+oHrRexUIOclFGxS1BYzS3FlFLNCYZHUFoz/CanoE1Z2CiiigQUUUUAcv4z8R3
OkG1stNVGvrs4UsM7BnAOPc/yNcr4yg12AaYNav4blZJcqscYXYRjPIAz1rU8aSr
beO9EnlH7sKoyeB98/4in/E9hu0YZH+vY/8AoNAFu/1rVdR8RnQ9Dmhtjbxb5p3Q
N2HAz9RWPqOtak9jruhaw8c1xbw71mRQu4ZU9B7EVX02wmuPiHqdr9vmsZH3urxE
bmBIIHPsc/hWnr3hRNM0vVNUk1Ce6uJLfYxlA55Xn9BQBl6Pf+JU8Ixy6MscNnYq
+9mCs8h3FiQCOgz/ADrTn8Y6hN4HXVIBDHcpcfZ5cpkE4zkDPHatLwfJHD8OYpZc
BFimZifTe9cZHA8fwxllYECXUAVz0IC4yPxyPwoA7i8k8S3Vlp39kywL50AeeeRR
lW47dOc+nasyLW/EGj+KrTTNXuIbuK6xhkjC4BJGRgDuKg1G/vbzVNE8P2909pBN
axtK8fDHKk4z9B+tU9T0uDSfHWj20N1c3LEqzNcSByPmOB046UAaeq+INej8ZtpN
i0LKw/dqU4GV6sevHWjStb12y8ZJo2sXEdykq8FEAxkZBGAPSjAPxdH/AFw/9kqP
U/8AkrNn/wBc1/kaAO+ooooA5nx/pdtf+HpZ5lPm2oLxMpwR6j6GvO3tjdeHYL+4
uJ5Z/OMYLyFgqgZwM0UUAdh480yCPTodbhaSG+jVQJI2xnp1rnNI1G/1u21OPUL6
eVEtMBS3H317fhRRQBS0K7u9QmttClvJl093IMSEDjOfT1rtPH9pDZeFLWxtkEcC
yqAo9gaKKAMXxdbgeHNF1ZXkS7WFYg6tjgcj8etQNZJbXvh+8WWWS4nKyySSPuLH
cBj6YoooA2QxPxY3HqF2/hspmrkr8VbJgef3a/gQaKKAPQaKKKAP/9n//gAVTGlu
dXggREVCSUFOICYgR0lNUP/bAEMADwoLDQsJDw0MDREQDxEWJRgWFBQWLSAiGyU1
Lzg3NC80MztCVUg7P1A/MzRKZEtQV1pfYF85R2hvZ1xuVV1fW//bAEMBEBERFhMW
KxgYK1s9ND1bW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tb
W1tbW1tbW1tbW//CABEIAHsAZAMBEQACEQEDEQH/xAAaAAACAwEBAAAAAAAAAAAA
AAAABQEDBAYC/8QAGQEBAAMBAQAAAAAAAAAAAAAAAAECAwQF/9oADAMBAAIQAxAA
AAHogIJFdehPXpFr2TC2DS3PKQAABFTqxV2e6ceyc6YtztO7VOb+/GAAGKNFNOno
tOIMEaXzWxHLZ+j1unmiJSAIqdbS3Ppmi2Nd05+kBzmfd0mnCIlIAhp1vr8kCuN2
s4VplCCnb0V+IAAEdOpxfmsQmjqvZ3zRdXZnOOmaAABgjXDXZ7fkBfG0I3zlJIAA
EI5rPv6LThsAgEBKQAAgpSmp1Pb8vpWUgAAABBJ4F0bbJzvUlIAAAAAABBIAAAeD
OazOej2nHGm+cgAArEx4NBUeRmZot4musrKBwc+MDnRgKR4Yyw0mAktH4lLxMNiS
8wGQ2FBYeh6SciMxcSLztxEYjceC8cH/xAArEAACAgEDAwIEBwAAAAAAAAACAwEE
BQAREhATIBQhMDEzNBUiIzI1QEX/2gAIAQEAAQUC8HXQDR2GnMWGxpd1o6VeAp87
tj3RWJ0prLV0YoGas15TNKxsXjZZC11Ed4uk2w3BwnLAhgLDdvz8clPuhfbTqxux
giIDMROonfR/lyHjkfdnTfjktHPEf2imO7b8clGgLkvVwC5JtgUc0qg3MtSlUKX4
3Q516LikuhVFFIU1xqIgY82hNWyBQY/DasWgJMpGJQcfDIYKPScDGW/1SKBFNhb5
01wJhTIcsigRr2YcXiZisWZFJBitoAskiJvMB1GvbXXqKsLcuq2vuWSRE17S7Gpu
qhsZJMlrLFPHtwuis+NCpYrrqr+0oV1lVx8du7ifn6qojVGYnIGEHlsqMRpf0ssM
8PVLKioOdDHEo0ZDhFaiUDQx0Sdinv6fGsUCaZ9zJf7OX0r6RgLBqAJPxkbTkFgt
9cYmmuOTOMKRjY/V7QfiAREZOP5XK6r/AG//xAAmEQACAgEDAwQDAQAAAAAAAAAB
AgADERASMRMgMAQhIkEyQEJQ/9oACAEDAQE/AexKGPMFSCdND9RqFPEagjwUV/0Z
ZaEj2s2gdl4lVm8S+r+h3VruOJbZsGF16R+4UIinacxm+O7u9P8Acsbc2iey7oST
zqvvV3en4OvNWijJnMf417T3em+4wwdKSPxj0leJhnMCCv3aO+857qWw0vrGN2q3
MIbm8KHqpiEY8isVMIW4ZhUqcHyAkcTrZGGEO39oDJxHqKDPlZy3P+b/AP/EACIR
AAEEAQQCAwAAAAAAAAAAAAEAAhEgEBIwMUEhMkBCUP/aAAgBAgEBPwGhctS1Fa0H
bDig1ARkiE02KaO7Dmz0Lfazs90HkzZ+SpxM8XPCaeswoGyfBne9d6PmAz+1/8QA
MRAAAQMCAwYFAwQDAAAAAAAAAQACEQMhEjFREBMgIkFxMDJhcoFCUmIEQIKRscHw
/9oACAEBAAY/AuCGcxV3kdrKzyr8wUPGDwN0w2+paN1VrnU7OdoK1Yeq3TsjlxT9
QyRqPuJ/s7YYHP8AaFF2nRwhFpyKwHzZDvxMCa3Y2gDE3d2UNEBXVl/IcTB6bfc3
ZMT2Um2qdUHlB4mHumu1GzH9uRHRRU5XeuS8zR8rd0RDerig3TrxHVt1ujcRbbIE
LmaCoAgeAHN8syEHNyPiYXLC4TTJUtMjxIcJCx0H4Toclztb8H9qXHIJ27vh2TUM
IPbkUXHIIiIPEXOMAJzcL7iMlUKjmPqAsbDIxKm10k6Dui5vTMJ+5BEXJVsR7Bck
zoVuzNpkqIcPXZTb0N05gH0Kr+TgEGPNz5rKt3asT2hxdqns9CFV+FgY2faES0Q0
zAWE5T/pUyAOqb2VN3QGEZeMWCIm8qrGbSHIMOHG3VODYmRMJhcYAn/Kq1+hX6mP
tTsTmtdPVOdrK/7RUvlN7ItcJBTw4TAMKp8KGCJCqzqmg5SiGCAAnDoWrdxyYohW
1U/kqXyqftC//8QAKRABAAIBAgQGAwEBAQAAAAAAAQARITFBUWFxgRAgkbHR8DCh
wfFA4f/aAAgBAQABPyHyeoPsS8ckdJVaHHGI5nCcPrNRBo3Z+Br0BqPaXWnl5kR6
p4D9039Zah2HByYxLetdnh5nWLWnm2fMszTkQ0MeFu3Nc8xzzsTQPKlpeZIbCCCz
R8qcBS9YRGtW9fB0GG01INHDYlBS6bIBtWTWA8I5wKKNPKObL38d1wz728FUtm2p
liUALjjKPrg82TlD2nKifB+F0PvksWb+53hjyOd0UJ0eEg6y5NKvzYZwMMcVOHi4
sXY0+9IjfY35ZWEGwfgIb2Hci8WFj+RUeHfhHGXFn8h0ibn5E4E2Za4daUuYJxX2
r/lZmgtYQJFLarXwL0a0YWX1ZqvrERoLWW7lkvc824WTLJlmh8y58ZLYjAZyEFUA
dmWSkWm6yj7NHMZO0QImTMShg+PyRZEDmjNR+gcgYKhRCXUFe/gTeCu3+xOAp3jV
rWMYg0xrKXbv/wAiwbfNLYZcjQ0mR7r0LP1P6lnk7k/brMmodCiOztBTjqj5BaNH
Sfq/aM3IXf8AyKqysewqVXKmcvtwSLDYC3MxKipqOsBJYK9UpdVh3W/vWVPrr/Y2
642pqoAel50h750fTafo/aAW1QweIcHjAGGE/qGxmxCL4278BhZEtETOboIWNuTj
mHqcHSY0CmY6TuLENtvvEyd+xP/aAAwDAQACAAMAAAAQAggFtAAA/s1gAAHk5sFA
Ew8FooAIhAMAABABNwAAFAxkAAF9AloAAlIoAAAEBsoAAAAAEAAAkEEAAAkEAvgE
EkkEgEAEEgAAkEEAAEgA/8QAJhEAAgEDAwQBBQAAAAAAAAAAAAERICExEFHwMEFh
0ZFAULHB4f/aAAgBAwEBPxCi62COIubEbOF8q5HatI+Uex4UyZhAmLuhDVRHtgUj
MMh4RCpZIUzlDUIRql9JoWzEi9FTn5z2PZCbGmskru360ihZRztra129/wB0TE3A
k2SWWNvDXOeapNKIYlo+pvIym8tkX+De7mB0qqD8lo65a4zh/j0TNfkTI5zKGPDo
Q3Fc6RAFmRA6jGWhnEuP4Nj6pikFrqLq6IP7a//EAB4RAQABBAMBAQAAAAAAAAAA
AAERACAhMRAwQUBQ/9oACAECAQE/ELAKVwi9oHohwUzug04Qd1vFS4blBNSZcyec
gEXLAUII49ixxd3LwkuYQ8iaPDShUsKBBBcZhTvJDQXnSO2JNE4Ou6Jr7B07QDX5
v//EACcQAQABAwQBBQADAQEAAAAAAAERACExQVFhgZEQIHGhwTCx8EDx/9oACAEB
AAE/EPYomFIhhvnXrzXDjMDxnuiJYEFbDa9GTX4kHA/ZqTdKEm/LBFWT3vSAjKV3
7b+N6CKHVdjwb1OtbTEcG1ABB9UlEIiRA+BcoOhkNlf2c61IpEO/8jpz7hioorgB
TW0+qKeSmb5meL90AAAAgDSlglYCuLHhO7ViQZnKbg56o+5lHUdE5G9SpOpQ0Uzp
aKItISO57YbAa3cRHiXzUWUJO6u+j+lsUdO21YwjBVlMCTRMNR2SJIySMP2Uh1ga
AlQTnloDCAQG3tQmLAPkHq2MQ/c/fpCriCm5FMuJMWDVf7pD4wijdWH79ypTUPkf
tdULyD6QQXwEiTgIs8nNQu4gqLOTCH/TS8XmBMvlWmPqdQ/E7ZeKcMQwCd7vTHuZ
ZVADjP0tQ2CnWjeOT1MHnAL6cdipvIxAnYlQXGgQHR/BLh/AeF8UAcwHtX3zGLwM
rROaDtBCzbOxxI7d0BAZEmu/4wCZc5GrWBMik2zMeaaDWjz5fv8A5ZN3xlgCVgvV
1vBYboib6bel2exeO1ho5StjDZH5RcltgFDmQipvxPDfHuImSV0omCmrDInKKKcW
aMAAv61ps8EviUfqtTEEhiZE0Yfuk9jUkGBZQpXVjKlDkTMg4maJydoovYvMF7RS
gu0oPkP1QDFlG5LKJ3SaLETHV5cWgZqHpCzOWJR16A9sZyAP7VdZRnJr5ab1GUNB
JfIR3QtcCiZzBfApdSEOGam5YoFBYDphZL3p10WtlG74fNZ1JUWCUMPyh9mlHTAC
QyEFiNqDHChIAQeGL0U9FAKFh1L5pqrn8VC48qAT+1SZRASwIzd12vSSWBBoEfBL
qkOgIQKRNy8dVEm1uJJiB3E0UQmUAUMiWITMpDwF/hTTLfBE3xNI6qUaRRE5JmkT
VpZDdb6imF26qs81/wCLsoibxrv9vU5A+IBh57qPVImZrKhZDEq4NPgtT41lsjQY
eWiPQhklqbmjpGG/Ly1bs3FcsFztpc+b9ImZ+6kMaQIAIxGMU1SVvnERHi1AUTal
qBVdXW2v/9mIgAQTEQgAKAIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlOu
2qsFCQI5+REACgkQfVi64NvrK2rZHAD8CD2+ouuRipAyev3GPpLMnPQ/uLUFQtDX
3ymMdJIFXmkBAIHrsxba2HEfQBozGJim70FwKV0wKDnfrXSpfmh8sYXXiIAEExEI
ACgFAlJqH30CGyMFCQHanAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEH1Y
uuDb6ytqzosBAJFSUcvZsV/7zYOXSAdJQVmAp2oehWfK+zaT9kLkjqJRAP9UwHpa
zma3ymyzf83klXMdkKXaGQ8364IShJhyRuu1BIiABBMRCAAoBQJSah/DAhsjBQkB
2pwABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRB9WLrg2+sratfwAP0b41Yn
hIeP/nJuqYDEjE0+F8qb3uvRJMo8mDjNGqZYVQEAoC2gKKP46y8NmMo2Y+u266/a
QjRIpwJMYZV9tKWTvDCIgAQTEQgAKAUCUmoxwgIbIwUJAdqcAAYLCQgHAwIGFQgC
CQoLBBYCAwECHgECF4AACgkQfVi64NvrK2rPJwEAsAoJYzNhVGwQ1EiD6VRTffTP
U8WkhSAf22juQr9t6aIA/RUKiN1lrAbG2wdIrg14aYOtLYxtDxE+36VTC9x3s3U1
iIAEExEIACgCGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUlIOOBQkCyJ7d
AAoJEH1YuuDb6ytqKLABAJ5BcrxCO/V4h5MyeFHA08CRtRafrL+fNSoBzr2aWIzw
AQCeE3DHYpsTemKLh9PoiEKRZc37pE8L6dBg4HtcDEHSeLkEDARSahiZEBAA3bqx
ZpSU2h+SVt/a6Y0no/T8NMwGVS4qHYtzDN96zm/zmc+2b0IagBR+hRuOCP5nCwWJ
0gkva6RJuqXLaCoqQagJv2PD4kVdMdDULmlSkdS9xsdqoGVmgYyo/Dww4urNBWru
RA73z9MyESrsvqCw/tf+NrOeS/4E8NmvfqvKss2rulIFB5CD1bh3lmb6zqiAzj32
/WVP8Fx7tuwxaA2pNtf1WsrZprVseplpid+bFApxtsEH1spOh3ZFYCnMz5P2YKqN
SFZYRXfs7Rj1WOwJT7ZecNvi9PLCbhkpDp3Xien1ZdZ05RjluovEfKzKRzRlSzyK
spW0QBJygWP/Jc6mAPs1UON0MqeD54qgCh0XF8wFqC7xcV8tbSLTht1EwSh0P08n
IcUtbYrk+gjI/c/d7josEi9ib2FinG5qcodc+XjxX6Cjlxa5N1UM6ImqSvNuuix2
Lh9ea+rywaUkFINnhpJ008UgXwbMXU4q1GOPUKzQhKtwd1O67KOAZ7wTtbvWoprK
iV2YbXQQLiHGCtj58lmxkG6kkTkuPg9vrVCXTU2hBeU+H/XhEgyD66U4fz8Iwlnc
EgXcQUsSg1xXa13DdFcIF1knj79XZbg2gGNWLVKzczE4UVr5VK4vdztk2PTh5Fmo
oKWJp5PJc9eMuwNRUTswNnV+6VLTK49P/M70j1sAAwUP+NMQq6z3PLXTybBx6PBJ
FL/YTee60aAzBl+DHAtWMy29kyrUl5dx4UrrbCwfSCNTqtUTorkn7+NE3DoHnYDi
onFfWYMN/P/58JGRNTScrSPPgJHnq41FCZGCPgNYcz16woqG+xaS92b8ZOebedjY
HwuVQ3jKXqbWnd4lmexoZTcKlt7nbsfIoDzpiOJnz6cwzqWXzSZghk8oWz17FtRJ
ygSkmKkSe+sda0yyzxWbNk5YcvNAsKhTaMadikGEyXZo/bTebmHw1FPT6EsdNF5M
8IpVMXxTIDZ9Fs2mdJUGku2KnExsIU5QvHfbrju0ughOfFqqr3+RIfwjTaeJ/hNr
bs2/rSuWtGMv9k75EX/9nRs04ya//jAbJ6LFMtrI0qZEV61um10v+hlm8+UgLyDf
eex1YqosZ/EtkAWXj6bWG0YRf5LwwurAjl7iQ5+3nIexqeE3G8Mf7VcafJgGmBZc
nv36oe1ML1va0INWXqNieaon2Ei0rCJIpwn9GQ45K5nX/LApq+VNVKFDHdNCTxQg
Rp4wICTyJkBsCXQCBKU4YOuhsyAHULCM8+8rawtdj3qG78iRKw2LC3SAey289TJi
5tTI4E2/T/voFwN6X7ymh1gTVzGDLRpU9rpbn82gsVmwtnPQUsTkeituQzZbAi1C
+ZouYObLA4Ho0cbFV/hTfsiIZwQYEQgADwIbDAUCVJS03AUJA2cEIgAKCRB9WLrg
2+sratS2AQCVYDsdlxom4vgBvJipQvEIttVFoTvzVBXYL6G4Tqp77AEAn8YfayCg
s64JIi5gJ3o3DtpOrLjrvOJdRtwlUqK2lUc=
=/XnV
-----END PGP PUBLIC KEY BLOCK-----

-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

mQSuBFJqGJkRDACUayLdZH0RMZI/sFAqW4w9pjR8FEtkhEZ2RUzfPjxhDGLk2VvA
WiIk5hEJ7KL0BSCaBFrB319xl4LH0/QeBTzyaG4AnH2D1jlDbO8pM5OsL8T+ukF5
jb63nn3GOls8H7Rm2dLWdEB0e/UDVhzORment1yTYzeGsN1nL5+oh1KOmFBJoD2A
rKyE58Yw642SFEc/vO0S9+gKvytB8YFnpFuvaeDil2l0/z0sELQ2JHb/Li0I58NZ
Wduw8Se6WDVMILjPdffV8amspVuwids/1nRGN4yQMkh0lNszfVw3Y+uyKvHbAy32
6vyl/xnppv3cfS9onk5Eoo+aUVj10i9g2tsl2RpdZQ7lsdlwZkYtdXcIdgE7cmtV
RohwEwZA7AN8yVsi04Ka8H3zQAxcYyGvY3LlqmgRi5gt6Lh3hjpk0gyuSgKS690a
C1A8sfbhIwzoUIHc6YaHxnY6HgxGoP/0rOrrX3lt1QWgp2gqeiLff6SQ2InsdBNS
08X3mdOjwD+yX18BANRVgY3JuF8BhcCvdgS06upQDjAIRtzZnnyKUiQYAIDjC/4k
qy/lrRT2m0ZaXU6L2PWJaqESS0pNviy2izASwgslHOhEzagdMCnoWmJiGS3/8JZr
yv04mTueSsEjoX58uWMIhQBzlyH+t/16lI/t9MHkXxllG8rwsAhU/4AWAr2zeSrX
G8qxLpWLMD6rSk3tLy84SnLoFRCtvSNTtC6pNYelanUOcJDD6QYhSbIn9E2sqqbn
OON59Do0dRvoX1oIoDLwcaAOP4RH4Tcy/fsqlxy6BPBchp/S4KqejvFo1RuCGF0T
c52sbJGkWuxHfcdn4uufYHKWN106G2F9nKmjbSXj12qtJZKwM1ZZ8IbKfkW/5/SO
axxbzL7sl96cZRAXc7YGmgCZ0rcWBMtNFcIDqrG8VJzVFXqCb+LCr9eWfbNlRK1v
ATRGIGi/768mSNOh4Nwxdo0KL06Rp4BKM/huVkrtHurxbcjTtfa7V5ZECn7pJMvU
kaJcV4J0czVJpZEVng/z1Thl6Jbf9QthY+hBXm/Sx7TGDQUpToWVvZ1ay7Z5B4YL
/0/8DFRb/FpPee7bfTaqJvUeiH8lcCiPyHcst14vu3rcGLwfPhGHT/QNtHhUHlGy
faNnCyUuu1D6WEXF9Ta/zj8HDsj4u/z9za6Hzhb/JfSu9qnhDwQ3M4zOBl9ECWNn
KTxK8jUMWbe+f7Euqd3k5rFehipFmCzSqYkZfZZM5qSC7PBW9RuA7uPrFNreGwiZ
x+/nV/1sFL7dzwp2uVtigdGtTbyCfRkb0zEtezOOAq3vSeuj2SuFRkkGsXG49jZ2
s4eHWolfZEXanUne4eqo8P2IIt4dwc5MMz2aSYjE1KX4Ie7OUTlsSsTyLqe1UX+h
6xaUjG7+6FLX9i+dA46lsI3DOcorRcLRuSGDvDV+i/EeoSrViwZfAEYU68QNTG2W
9RSeR85KhVacRWyY7icDMaN1raDVmvevqDrSzEfzu1fj34nIdF76gLTSTOh9LXLC
c1HlZYDcwq0bmNCDMmMjxnHUYZse/tcI1Q1B+YUpt5NLwm3x0fh4S+AhejcLl28H
urQ7TGludXggREVCSUFOIChodHRwOi8vd3d3LmRlYmlhbi5vcmcpIDxsaW51eGRl
YmlhbkB6b2hvLmNvbT6IgAQTEQgAKAIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC
F4AFAlOu2qoFCQI5+REACgkQfVi64NvrK2rZKwEAiJmTIhVk9wYhcJwJ6PmrW1wx
Yt56ojizFYxA4Ik5/PkBAIxCjFCSyDfg8oRPNrPAY0I0/wRu19EMu1kOoRjYtZmA
iIAEExEIACgFAlJqGJkCGyMFCQHanAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA
AAoJEH1YuuDb6ytq9QMA/2fGHFWy5Fhr0Lbccot8LtNjJTVfveJLLul353p6Or3K
AQCCntbctT8OLKbDu1dsGRbYTuU3hI5JGMzNf24qgZuZaYiABBMRCAAoAhsjBgsJ
CAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVJSDdgUJAsie3QAKCRB9WLrg2+srahhl
AQCZ1G3cbpboy034FE7dx4bMtqeUFokI+a68Ms3IQ+M6zwD7Bd7FxOeFt7pviwPV
Z1biodx39oBX646Cnaom4IJNANzR1eHV3wEQAAEBAAAAAAAAAAAAAAAA/9j/4AAQ
SkZJRgABAQEASABIAAD/4QkZRXhpZgAATU0AKgAAAAgAAAAAAA4AAgIBAAQAAAAB
AAAALAICAAQAAAABAAAI5QAAAAD/2P/gABBKRklGAAEBAAABAAEAAP/bAEMADwoL
DQsJDw0MDREQDxEWJRgWFBQWLSAiGyU1Lzg3NC80MztCVUg7P1A/MzRKZEtQV1pf
YF85R2hvZ1xuVV1fW//bAEMBEBERFhMWKxgYK1s9ND1bW1tbW1tbW1tbW1tbW1tb
W1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW//AABEIAGQAUQMBIgAC
EQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMD
AgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKC
CQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2
d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK
0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAA
AAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR
B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RF
RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1
9vf4+fr/2gAMAwEAAhEDEQA/APRKKKKACuV1zxnBZSPb2CCeZTgyE/Iv+NJ401w2
9gLO2ZknnJV+zKoOP17e1Z3h3wY0wiu9TwsZ+YW+OWH+16fSok23aJ3UKNOMPa1t
ui7mP9v1zWrhjFJdSkdViJVR+A4q6sfi2Jdyi8GOeua9AtbS3tIvLtoUiTOdqLip
6XI+5UsctowVjz+38banZusN7bJIVPz7lKPj+X6V1+j6zaaxbebbNhh9+NvvKfem
63ottrNqY5lCygHy5R1U/wCFedWkt7oGt4RG86F9rov8Y7j6YovKD11RUadLFQbg
uWSPWKKjgmWe3jmjzskUMufQjNSVoeba2gUUUUAFMlz5T4badpw3p70+o5ziCQ+i
k/pQNbnB+HYX13xbPqE6h4YmL4YceiD+v4V6BXI/DxP9CvHI6ygD8q62ohtc6cZK
9Xl6LQy9Z1GaB4bGwUNe3Odm77sajq59hUMOg3HElxrN+8/UlJdqD/gPSobeTHju
6jl6m0Tys9hnnH410Bq9zOTdNJLtchtY5o4tlxKJWB4fGCR7j1rivHEf2PxBZXkR
2s6gkjrlW/wIFdosiS3jIC+6AfN1C8/zrj/GCjU/EdlZRneI0JlC/wAAJyf0FRPY
2wbarXfZ3O0gQRwIgxtUYXHTHb9KfQowoGMYHT0pas4wooooAKa6hkKnoRg06igD
jfAEjRTahZScNG4O09QckH+VdlXnfieG40PxN9utnaJLg+YGX143A+vr+NegQSrN
BHKpBV1DAjvmoh/L2OvFRu1VW0jl/E9rf2+pJq9quWt8bWXoFxyGHpnPPv7VPbeK
NI1K2UXkptpAcsjEgZHoR1FdIeRis+bQ9PmbcbdVJOTs4B/Cqt2JVWEoqM1qtmjL
vPFiSn7Podu99cNwCFIVfc1PoGhPZtNeag6zXtyQXYD7vsK2YLeK2jCQoqKOyjFS
0W7kOqlFxgrJ/ewooopmIUUUUAFFFIaAM7XtJj1jTntnIV/vRvj7rVg+FtXk06U6
Jq2IZIjiFmPUE9P8K6+s3WtEtNZh2XCYkX7kq/eWk1rdG9OquX2c/h/I0qK52z/t
zR5BFcJ/aFkowrxY81R7g9a3LW6FypYRSx47SoVP600Zzhy7O6JqKWiggKKKKACi
iigAoorA8WeJh4chgb7K05nLBSGwARjr+dAG/RTY23Rqx4yAao69qg0XSZb9oGmW
LG5VODgkDP60AaFJWd4d1Q61osGoGLyvOL4TOcAMR/SoPE+p3el6estnb+azOAWI
yE+oHrRexUIOclFGxS1BYzS3FlFLNCYZHUFoz/CanoE1Z2CiiigQUUUUAcv4z8R3
OkG1stNVGvrs4UsM7BnAOPc/yNcr4yg12AaYNav4blZJcqscYXYRjPIAz1rU8aSr
beO9EnlH7sKoyeB98/4in/E9hu0YZH+vY/8AoNAFu/1rVdR8RnQ9Dmhtjbxb5p3Q
N2HAz9RWPqOtak9jruhaw8c1xbw71mRQu4ZU9B7EVX02wmuPiHqdr9vmsZH3urxE
bmBIIHPsc/hWnr3hRNM0vVNUk1Ce6uJLfYxlA55Xn9BQBl6Pf+JU8Ixy6MscNnYq
+9mCs8h3FiQCOgz/ADrTn8Y6hN4HXVIBDHcpcfZ5cpkE4zkDPHatLwfJHD8OYpZc
BFimZifTe9cZHA8fwxllYECXUAVz0IC4yPxyPwoA7i8k8S3Vlp39kywL50AeeeRR
lW47dOc+nasyLW/EGj+KrTTNXuIbuK6xhkjC4BJGRgDuKg1G/vbzVNE8P2909pBN
axtK8fDHKk4z9B+tU9T0uDSfHWj20N1c3LEqzNcSByPmOB046UAaeq+INej8ZtpN
i0LKw/dqU4GV6sevHWjStb12y8ZJo2sXEdykq8FEAxkZBGAPSjAPxdH/AFw/9kqP
U/8AkrNn/wBc1/kaAO+ooooA5nx/pdtf+HpZ5lPm2oLxMpwR6j6GvO3tjdeHYL+4
uJ5Z/OMYLyFgqgZwM0UUAdh480yCPTodbhaSG+jVQJI2xnp1rnNI1G/1u21OPUL6
eVEtMBS3H317fhRRQBS0K7u9QmttClvJl093IMSEDjOfT1rtPH9pDZeFLWxtkEcC
yqAo9gaKKAMXxdbgeHNF1ZXkS7WFYg6tjgcj8etQNZJbXvh+8WWWS4nKyySSPuLH
cBj6YoooA2QxPxY3HqF2/hspmrkr8VbJgef3a/gQaKKAPQaKKKAP/9n//gAVTGlu
dXggREVCSUFOICYgR0lNUP/bAEMADwoLDQsJDw0MDREQDxEWJRgWFBQWLSAiGyU1
Lzg3NC80MztCVUg7P1A/MzRKZEtQV1pfYF85R2hvZ1xuVV1fW//bAEMBEBERFhMW
KxgYK1s9ND1bW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tbW1tb
W1tbW1tbW1tbW//CABEIAHsAZAMBEQACEQEDEQH/xAAaAAACAwEBAAAAAAAAAAAA
AAAABQEDBAYC/8QAGQEBAAMBAQAAAAAAAAAAAAAAAAECAwQF/9oADAMBAAIQAxAA
AAHogIJFdehPXpFr2TC2DS3PKQAABFTqxV2e6ceyc6YtztO7VOb+/GAAGKNFNOno
tOIMEaXzWxHLZ+j1unmiJSAIqdbS3Ppmi2Nd05+kBzmfd0mnCIlIAhp1vr8kCuN2
s4VplCCnb0V+IAAEdOpxfmsQmjqvZ3zRdXZnOOmaAABgjXDXZ7fkBfG0I3zlJIAA
EI5rPv6LThsAgEBKQAAgpSmp1Pb8vpWUgAAABBJ4F0bbJzvUlIAAAAAABBIAAAeD
OazOej2nHGm+cgAArEx4NBUeRmZot4musrKBwc+MDnRgKR4Yyw0mAktH4lLxMNiS
8wGQ2FBYeh6SciMxcSLztxEYjceC8cH/xAArEAACAgEDAwIEBwAAAAAAAAACAwEE
BQAREhATIBQhMDEzNBUiIzI1QEX/2gAIAQEAAQUC8HXQDR2GnMWGxpd1o6VeAp87
tj3RWJ0prLV0YoGas15TNKxsXjZZC11Ed4uk2w3BwnLAhgLDdvz8clPuhfbTqxux
giIDMROonfR/lyHjkfdnTfjktHPEf2imO7b8clGgLkvVwC5JtgUc0qg3MtSlUKX4
3Q516LikuhVFFIU1xqIgY82hNWyBQY/DasWgJMpGJQcfDIYKPScDGW/1SKBFNhb5
01wJhTIcsigRr2YcXiZisWZFJBitoAskiJvMB1GvbXXqKsLcuq2vuWSRE17S7Gpu
qhsZJMlrLFPHtwuis+NCpYrrqr+0oV1lVx8du7ifn6qojVGYnIGEHlsqMRpf0ssM
8PVLKioOdDHEo0ZDhFaiUDQx0Sdinv6fGsUCaZ9zJf7OX0r6RgLBqAJPxkbTkFgt
9cYmmuOTOMKRjY/V7QfiAREZOP5XK6r/AG//xAAmEQACAgEDAwQDAQAAAAAAAAAB
AgADERASMRMgMAQhIkEyQEJQ/9oACAEDAQE/AexKGPMFSCdND9RqFPEagjwUV/0Z
ZaEj2s2gdl4lVm8S+r+h3VruOJbZsGF16R+4UIinacxm+O7u9P8Acsbc2iey7oST
zqvvV3en4OvNWijJnMf417T3em+4wwdKSPxj0leJhnMCCv3aO+857qWw0vrGN2q3
MIbm8KHqpiEY8isVMIW4ZhUqcHyAkcTrZGGEO39oDJxHqKDPlZy3P+b/AP/EACIR
AAEEAQQCAwAAAAAAAAAAAAEAAhEgEBIwMUEhMkBCUP/aAAgBAgEBPwGhctS1Fa0H
bDig1ARkiE02KaO7Dmz0Lfazs90HkzZ+SpxM8XPCaeswoGyfBne9d6PmAz+1/8QA
MRAAAQMCAwYFAwQDAAAAAAAAAQACEQMhEjFREBMgIkFxMDJhcoFCUmIEQIKRscHw
/9oACAEBAAY/AuCGcxV3kdrKzyr8wUPGDwN0w2+paN1VrnU7OdoK1Yeq3TsjlxT9
QyRqPuJ/s7YYHP8AaFF2nRwhFpyKwHzZDvxMCa3Y2gDE3d2UNEBXVl/IcTB6bfc3
ZMT2Um2qdUHlB4mHumu1GzH9uRHRRU5XeuS8zR8rd0RDerig3TrxHVt1ujcRbbIE
LmaCoAgeAHN8syEHNyPiYXLC4TTJUtMjxIcJCx0H4Toclztb8H9qXHIJ27vh2TUM
IPbkUXHIIiIPEXOMAJzcL7iMlUKjmPqAsbDIxKm10k6Dui5vTMJ+5BEXJVsR7Bck
zoVuzNpkqIcPXZTb0N05gH0Kr+TgEGPNz5rKt3asT2hxdqns9CFV+FgY2faES0Q0
zAWE5T/pUyAOqb2VN3QGEZeMWCIm8qrGbSHIMOHG3VODYmRMJhcYAn/Kq1+hX6mP
tTsTmtdPVOdrK/7RUvlN7ItcJBTw4TAMKp8KGCJCqzqmg5SiGCAAnDoWrdxyYohW
1U/kqXyqftC//8QAKRABAAIBAgQGAwEBAQAAAAAAAQARITFBUWFxgRAgkbHR8DCh
wfFA4f/aAAgBAQABPyHyeoPsS8ckdJVaHHGI5nCcPrNRBo3Z+Br0BqPaXWnl5kR6
p4D9039Zah2HByYxLetdnh5nWLWnm2fMszTkQ0MeFu3Nc8xzzsTQPKlpeZIbCCCz
R8qcBS9YRGtW9fB0GG01INHDYlBS6bIBtWTWA8I5wKKNPKObL38d1wz728FUtm2p
liUALjjKPrg82TlD2nKifB+F0PvksWb+53hjyOd0UJ0eEg6y5NKvzYZwMMcVOHi4
sXY0+9IjfY35ZWEGwfgIb2Hci8WFj+RUeHfhHGXFn8h0ibn5E4E2Za4daUuYJxX2
r/lZmgtYQJFLarXwL0a0YWX1ZqvrERoLWW7lkvc824WTLJlmh8y58ZLYjAZyEFUA
dmWSkWm6yj7NHMZO0QImTMShg+PyRZEDmjNR+gcgYKhRCXUFe/gTeCu3+xOAp3jV
rWMYg0xrKXbv/wAiwbfNLYZcjQ0mR7r0LP1P6lnk7k/brMmodCiOztBTjqj5BaNH
Sfq/aM3IXf8AyKqysewqVXKmcvtwSLDYC3MxKipqOsBJYK9UpdVh3W/vWVPrr/Y2
642pqoAel50h750fTafo/aAW1QweIcHjAGGE/qGxmxCL4278BhZEtETOboIWNuTj
mHqcHSY0CmY6TuLENtvvEyd+xP/aAAwDAQACAAMAAAAQAggFtAAA/s1gAAHk5sFA
Ew8FooAIhAMAABABNwAAFAxkAAF9AloAAlIoAAAEBsoAAAAAEAAAkEEAAAkEAvgE
EkkEgEAEEgAAkEEAAEgA/8QAJhEAAgEDAwQBBQAAAAAAAAAAAAERICExEFHwMEFh
0ZFAULHB4f/aAAgBAwEBPxCi62COIubEbOF8q5HatI+Uex4UyZhAmLuhDVRHtgUj
MMh4RCpZIUzlDUIRql9JoWzEi9FTn5z2PZCbGmskru360ihZRztra129/wB0TE3A
k2SWWNvDXOeapNKIYlo+pvIym8tkX+De7mB0qqD8lo65a4zh/j0TNfkTI5zKGPDo
Q3Fc6RAFmRA6jGWhnEuP4Nj6pikFrqLq6IP7a//EAB4RAQABBAMBAQAAAAAAAAAA
AAERACAhMRAwQUBQ/9oACAECAQE/ELAKVwi9oHohwUzug04Qd1vFS4blBNSZcyec
gEXLAUII49ixxd3LwkuYQ8iaPDShUsKBBBcZhTvJDQXnSO2JNE4Ou6Jr7B07QDX5
v//EACcQAQABAwQBBQADAQEAAAAAAAERACExQVFhgZEQIHGhwTCx8EDx/9oACAEB
AAE/EPYomFIhhvnXrzXDjMDxnuiJYEFbDa9GTX4kHA/ZqTdKEm/LBFWT3vSAjKV3
7b+N6CKHVdjwb1OtbTEcG1ABB9UlEIiRA+BcoOhkNlf2c61IpEO/8jpz7hioorgB
TW0+qKeSmb5meL90AAAAgDSlglYCuLHhO7ViQZnKbg56o+5lHUdE5G9SpOpQ0Uzp
aKItISO57YbAa3cRHiXzUWUJO6u+j+lsUdO21YwjBVlMCTRMNR2SJIySMP2Uh1ga
AlQTnloDCAQG3tQmLAPkHq2MQ/c/fpCriCm5FMuJMWDVf7pD4wijdWH79ypTUPkf
tdULyD6QQXwEiTgIs8nNQu4gqLOTCH/TS8XmBMvlWmPqdQ/E7ZeKcMQwCd7vTHuZ
ZVADjP0tQ2CnWjeOT1MHnAL6cdipvIxAnYlQXGgQHR/BLh/AeF8UAcwHtX3zGLwM
rROaDtBCzbOxxI7d0BAZEmu/4wCZc5GrWBMik2zMeaaDWjz5fv8A5ZN3xlgCVgvV
1vBYboib6bel2exeO1ho5StjDZH5RcltgFDmQipvxPDfHuImSV0omCmrDInKKKcW
aMAAv61ps8EviUfqtTEEhiZE0Yfuk9jUkGBZQpXVjKlDkTMg4maJydoovYvMF7RS
gu0oPkP1QDFlG5LKJ3SaLETHV5cWgZqHpCzOWJR16A9sZyAP7VdZRnJr5ab1GUNB
JfIR3QtcCiZzBfApdSEOGam5YoFBYDphZL3p10WtlG74fNZ1JUWCUMPyh9mlHTAC
QyEFiNqDHChIAQeGL0U9FAKFh1L5pqrn8VC48qAT+1SZRASwIzd12vSSWBBoEfBL
qkOgIQKRNy8dVEm1uJJiB3E0UQmUAUMiWITMpDwF/hTTLfBE3xNI6qUaRRE5JmkT
VpZDdb6imF26qs81/wCLsoibxrv9vU5A+IBh57qPVImZrKhZDEq4NPgtT41lsjQY
eWiPQhklqbmjpGG/Ly1bs3FcsFztpc+b9ImZ+6kMaQIAIxGMU1SVvnERHi1AUTal
qBVdXW2v/9mIgAQTEQgAKAIbIwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlOu
2qsFCQI5+REACgkQfVi64NvrK2rZHAD8CD2+ouuRipAyev3GPpLMnPQ/uLUFQtDX
3ymMdJIFXmkBAIHrsxba2HEfQBozGJim70FwKV0wKDnfrXSpfmh8sYXXiIAEExEI
ACgFAlJqH30CGyMFCQHanAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEH1Y
uuDb6ytqzosBAJFSUcvZsV/7zYOXSAdJQVmAp2oehWfK+zaT9kLkjqJRAP9UwHpa
zma3ymyzf83klXMdkKXaGQ8364IShJhyRuu1BIiABBMRCAAoBQJSah/DAhsjBQkB
2pwABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRB9WLrg2+sratfwAP0b41Yn
hIeP/nJuqYDEjE0+F8qb3uvRJMo8mDjNGqZYVQEAoC2gKKP46y8NmMo2Y+u266/a
QjRIpwJMYZV9tKWTvDCIgAQTEQgAKAUCUmoxwgIbIwUJAdqcAAYLCQgHAwIGFQgC
CQoLBBYCAwECHgECF4AACgkQfVi64NvrK2rPJwEAsAoJYzNhVGwQ1EiD6VRTffTP
U8WkhSAf22juQr9t6aIA/RUKiN1lrAbG2wdIrg14aYOtLYxtDxE+36VTC9x3s3U1
iIAEExEIACgCGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUlIOOBQkCyJ7d
AAoJEH1YuuDb6ytqKLABAJ5BcrxCO/V4h5MyeFHA08CRtRafrL+fNSoBzr2aWIzw
AQCeE3DHYpsTemKLh9PoiEKRZc37pE8L6dBg4HtcDEHSeLkEDARSahiZEBAA3bqx
ZpSU2h+SVt/a6Y0no/T8NMwGVS4qHYtzDN96zm/zmc+2b0IagBR+hRuOCP5nCwWJ
0gkva6RJuqXLaCoqQagJv2PD4kVdMdDULmlSkdS9xsdqoGVmgYyo/Dww4urNBWru
RA73z9MyESrsvqCw/tf+NrOeS/4E8NmvfqvKss2rulIFB5CD1bh3lmb6zqiAzj32
/WVP8Fx7tuwxaA2pNtf1WsrZprVseplpid+bFApxtsEH1spOh3ZFYCnMz5P2YKqN
SFZYRXfs7Rj1WOwJT7ZecNvi9PLCbhkpDp3Xien1ZdZ05RjluovEfKzKRzRlSzyK
spW0QBJygWP/Jc6mAPs1UON0MqeD54qgCh0XF8wFqC7xcV8tbSLTht1EwSh0P08n
IcUtbYrk+gjI/c/d7josEi9ib2FinG5qcodc+XjxX6Cjlxa5N1UM6ImqSvNuuix2
Lh9ea+rywaUkFINnhpJ008UgXwbMXU4q1GOPUKzQhKtwd1O67KOAZ7wTtbvWoprK
iV2YbXQQLiHGCtj58lmxkG6kkTkuPg9vrVCXTU2hBeU+H/XhEgyD66U4fz8Iwlnc
EgXcQUsSg1xXa13DdFcIF1knj79XZbg2gGNWLVKzczE4UVr5VK4vdztk2PTh5Fmo
oKWJp5PJc9eMuwNRUTswNnV+6VLTK49P/M70j1sAAwUP+NMQq6z3PLXTybBx6PBJ
FL/YTee60aAzBl+DHAtWMy29kyrUl5dx4UrrbCwfSCNTqtUTorkn7+NE3DoHnYDi
onFfWYMN/P/58JGRNTScrSPPgJHnq41FCZGCPgNYcz16woqG+xaS92b8ZOebedjY
HwuVQ3jKXqbWnd4lmexoZTcKlt7nbsfIoDzpiOJnz6cwzqWXzSZghk8oWz17FtRJ
ygSkmKkSe+sda0yyzxWbNk5YcvNAsKhTaMadikGEyXZo/bTebmHw1FPT6EsdNF5M
8IpVMXxTIDZ9Fs2mdJUGku2KnExsIU5QvHfbrju0ughOfFqqr3+RIfwjTaeJ/hNr
bs2/rSuWtGMv9k75EX/9nRs04ya//jAbJ6LFMtrI0qZEV61um10v+hlm8+UgLyDf
eex1YqosZ/EtkAWXj6bWG0YRf5LwwurAjl7iQ5+3nIexqeE3G8Mf7VcafJgGmBZc
nv36oe1ML1va0INWXqNieaon2Ei0rCJIpwn9GQ45K5nX/LApq+VNVKFDHdNCTxQg
Rp4wICTyJkBsCXQCBKU4YOuhsyAHULCM8+8rawtdj3qG78iRKw2LC3SAey289TJi
5tTI4E2/T/voFwN6X7ymh1gTVzGDLRpU9rpbn82gsVmwtnPQUsTkeituQzZbAi1C
+ZouYObLA4Ho0cbFV/hTfsiIZwQYEQgADwIbDAUCVJS03AUJA2cEIgAKCRB9WLrg
2+sratS2AQCVYDsdlxom4vgBvJipQvEIttVFoTvzVBXYL6G4Tqp77AEAn8YfayCg
s64JIi5gJ3o3DtpOrLjrvOJdRtwlUqK2lUc=
=/XnV
-----END PGP PUBLIC KEY BLOCK-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150101/67a50843/attachment-0001.sig>

From oub at mat.ucm.es  Thu Jan  1 19:19:58 2015
From: oub at mat.ucm.es (Uwe Brauer)
Date: Thu, 01 Jan 2015 19:19:58 +0100
Subject: gpg vs smime, snowden etc
Message-ID: <87ppay5po1.fsf@mat.ucm.es>

Hello

I am sorry if this is a little off-topic but I am not sure where to ask.
I use both, gpg and smime (the later either with gpgsm or with
thunderbird)

Recently the German news magazine ?Der Spiegel? [1] published more of
the ?Snowden files?, which reveal that gpg is NSA safe[2].

Does anybody know whether smime has the same level of security? There
are at least two possible weak spots. 

    -  the generation and sign of the certificate, ideally the
       generation of the keypair should be done by the crypto module of
       the browser, but that could be hacked...

    -  the length of the key for the symmetric encryption.

Maybe there are others. 

Any comments?

Thanks

Uwe Brauer  

Footnotes:
[1]  and I presume the Guardian and the New York Times as well.

[2]  although the documents do not provide any information concerning
     the key length and the gpg version

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6007 bytes
Desc: not available
URL: </pipermail/attachments/20150101/419f0977/attachment.bin>

From htd+ml at fritha.org  Thu Jan  1 19:45:58 2015
From: htd+ml at fritha.org (Heinz Diehl)
Date: Thu, 1 Jan 2015 19:45:58 +0100
Subject: gpg vs smime, snowden etc
In-Reply-To: <87ppay5po1.fsf@mat.ucm.es>
References: <87ppay5po1.fsf@mat.ucm.es>
Message-ID: <20150101184558.GA18042@fritha.org>

On 01.01.2015, Uwe Brauer wrote: 

> Recently the German news magazine ?Der Spiegel? [1] published more of
> the ?Snowden files?, which reveal that gpg is NSA safe[2].
> 
> Does anybody know whether smime has the same level of security? There
> are at least two possible weak spots. 

Nobody really knows, unless there is transparent and reviewable
evidence which supports either direction.




From wk at gnupg.org  Thu Jan  1 21:59:34 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 01 Jan 2015 21:59:34 +0100
Subject: [blog] Happy gnu year
Message-ID: <87wq56gqtl.fsf@vigenere.g10code.de>

Hi,

find below a plain text copy of a blurb i wrote today:

  https://gnupg.org/blog/20150101-happy-gnu-year.html

if you like to comment, please group reply to this mail.


Salam-Shalom,

   Werner

====

Happy gnu year
????????????????

  to everyone and a big *thank you* to all supporters of GnuPG.  It is
  awesome to see that GnuPG and its makers received a lot of attention
  in the last weeks of 2014.  This is really appreciated by all of us.
  Speaking of me, the donations allow me to keep on working on free
  software and GnuPG in particular ? at least for the next months.

  Early December friends reminded me that it is the time to kick off a
  donation campaign to secure the future of GnuPG.  They supported me
  with a [press release] which was republished by others (e.g.  [Cory
  Doctorow]) and soon many small and larger donations started to fill up
  the donation status bar with a bit of green.  I was not just amazed by
  the financial support but also by the many encouraging messages to us
  developers like /Keep the excellent work! Please!/, /Thanks for
  keeping us safe an protecting our basic human rights./, /You guys are
  great! Safe communication should be a right./, /Thank you so much for
  this hard work.  You're truly directing us toward a better world/,
  /GPG is important software for our society's future/, /Thanks for
  doing great work. I know it's under appreciated, but it's absolutely
  necessary/, /Please keep it up, guys, and run further donation rounds
  if you need money. If GPG goes down, we'll all be at a loss/, or
  /freedom of thought, freedom of speech, freedom of information/.  Up
  until today we received more than a quarter of the campaign?s goal and
  donations are still coming in.  Let me add that my work on GnuPG would
  have not been possible without the incredible support of my family who
  deserve all my thanks.

  At the 31C3 the [Reconstructing narratives] lecture ([video]) told us
  again about the depressingly sad state of our world regarding to
  freedom and humanity.  It was also reported that most of our secure
  electronic communication methods don?t do what we expected from them ?
  with the exception of a very few tools, GPG (i.e. GnuPG) being one of
  them.

  With the raised attention towards securing our communication and to
  help preserving us from a world nobody wants to have, we need to
  improve GnuPG and its frontends.  They need to be easy usable by
  everyone and be a standard part of every communication device much
  like the ubiquitous web browser. It will take time and a lot of effort
  to do that.  I am confident that with enough support we can achieve
  that goal.  Now let us look forward and see what is on the list.

  As a prerequisite we need to establish a solid organizational
  framework to free developers of tasks they are not best in, like
  looking for money, running funding campaigns, preparing paperwork for
  donation programs, and talking to ties and non-techies.

  We need better and streamlined documentation. For example, there are
  lots of different HOWTOs and other documents explaining the use of
  GnuPG and frontend applications.  Many of them are outdated and some
  documents contradicts each other.  Thus the goal is to prepare a
  canonical set of documentation to support all kind of users.  See and
  use the [Wiki] if you are interested to help.

  [Enigmail] is one of the most used mailer frontends for GnuPG and thus
  should be a primary target for improvements.  There are currently only
  two spare time developers for it ? despite that some smaller bugs make
  it sometimes hard to use for a beginner.  This needs to be changed by
  improving the communication between the developers and finding the
  resources to assign a paid developer to it.

  The network of OpenPGP keyservers works quite well for the relatively
  small active user base.  For a mass use of it we need to add a few
  things or start to deploy an easier method for retrieving keys.  This
  is essential for making mail encryption the default on the net.

  Although the use or proprietary platforms supports the spook?s
  surveillance programs, it is a pipe dream to believe that free
  operating systems like Linux or FreeBSD can completely replace
  Windows, Mac OS, and Android any time soon.  Improving our crypto
  tools on those platforms is thus essential to help those users and to
  trigger a network effect to make encrypted communication the default.
  For GnuPG this means to make the core components available on these
  platforms using a standard unattended installer, so that frontend
  applications (like Enigmail) can easily install it if not yet
  available.  Separating the GnuPG core from the frontend applications
  also allows for an automatic update procedure to be prepared for
  possible security relevant bugs and to be able to easily deploy new
  algorithms as soon as the needs arises.

  As stated in the press release a second full time developer for GnuPG
  is required to avoid relying mostly on me.  Keep in mind that even
  after having secured enough funds it will take some time to find a
  developer and it will also takes some months until s/he is up to my
  maintenance experience.  Thus is at all costs required nevertheless.

  In general we need to simplify the the user interfaces of most
  frontends and make it easier start with and keep on using encryption.
  A dedicated developers meeting will be the first step towards this.

  Okay, let?s take up our part for a new dawn.


  [press release] http://fsfe.org/news/2014/news-20141217-01.en.html

  [Cory Doctorow]
  http://boingboing.net/2014/12/21/gnupg-needs-your-support.html

  [Reconstructing narratives]
  http://events.ccc.de/congress/2014/Fahrplan/events/6258.html

  [video]
  http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video

  [Wiki] https://wiki.gnupg.org

  [Enigmail] https://enigmail.net


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



From kelly at prtime.org  Thu Jan  1 05:59:37 2015
From: kelly at prtime.org (Kelly Dean)
Date: Thu, 01 Jan 2015 04:59:37 +0000
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
References: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
Message-ID: <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>

Ryan Sawhill wrote:
> I disagree with your subject, and propose that you google for a tutorial
> since the man page clearly didn't work for you.

The man page did work for me, and I was able to accomplish my goal.

> (As far as I can tell, you were trying to import someone's pubkey, in which
> case you should simply have used: gpg --import FILE)

No, I was trying to get the key's fingerprint, _without_ importing it. I thought my original message made clear that I was trying to get the fingerprint. The point of my message was that GPG apparently requires pointless circumlocution for this simple function.

Now I'm afraid you'll just ask, ?why not just import it??, even though that misses the point. The answer is: I don't want it on my keyring, if it's the wrong key. How do I know whether it's the right key? By checking the fingerprint! And to check it, I have to get it.

Then you might answer that I should import the key, get the fingerprint, check that it's the right one, and remove the key if it's the wrong one. But it's more straightforward to simply check the fingerprint first, and not import the key in the first place if it's the wrong one. Which was my goal.

Getting the fingerprint should not require importing the key. Getting the fingerprint should not require writing to any file at all. It should only require reading.


From gabriel.rosseel at telenet.be  Thu Jan  1 17:25:51 2015
From: gabriel.rosseel at telenet.be (gabriel rosseel)
Date: Thu, 01 Jan 2015 17:25:51 +0100
Subject: PGP and BeID
Message-ID: <54A5750F.9000308@telenet.be>

Besides Mozilla Thunderbird (v31.3.0) en Enigmail (1.7.2) I installed
GpG4Win (2.2.3) in order to encrypt/sign emails.
Works like a charm (no pun intended).
The only problem I have is that, when I try to open the "Manage Smartcard"
option in Enigmail, I receive an error saying that the smartcard is not
supported (gpg: OpenPGP card not available: Not supported).

As smartcard I use my Belgian EiD card with the the ACR38U as cardreader.
Additional software installed:
1. middleware (4.0.7 7453)
2. OpenPGP Smartcard Minidriver (OpenPGPmdrv-1.0.0.0)
Works also a like a charm.

As OS I use Windows 8.1 64bit

I suspect that the OpenPGP software is the culprit and doesn't support
my smartcard.

Is this correct and can I do something to make it work?



From kristian.fiskerstrand at sumptuouscapital.com  Thu Jan  1 22:48:28 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Thu, 01 Jan 2015 22:48:28 +0100
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
References: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
 <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
Message-ID: <54A5C0AC.6050201@sumptuouscapital.com>

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

On 01/01/2015 05:59 AM, Kelly Dean wrote:
> Ryan Sawhill wrote:
>> I disagree with your subject, and propose that you google for a 
>> tutorial since the man page clearly didn't work for you.
> 
> The man page did work for me, and I was able to accomplish my 
> goal.
> 


...

> 
> Now I'm afraid you'll just ask, ?why not just import it??, even 
> though that misses the point. The answer is: I don't want it on my
>  keyring, if it's the wrong key.

At this point I would just like to point out that nobody should rely
on the existence of a key in the keyring for security. After a proper
key validation the key should be signed, either locally or as an
exportable signature to form part of the WoT. As such the existence of
the key on the keyring really does not pose any issue (maybe except
for aesthetically)

> 
> Getting the fingerprint should not require importing the key. 
> Getting the fingerprint should not require writing to any file at 
> all. It should only require reading.

Just looking at the file in question the fingerprint is not stored
along with the data, but you can get the long keyid using

$ gpg --list-packets Tmp/kf.asc
...
:public key packet:
        version 4, algo 1, created 1197735934, expires 0
...
        keyid: 0B7F8B60E3EDFAE3

For the fingerprint the key will have to be parsed and the fingerprint
calculated. This doesn't have to be done in the primary user keyring
however, but you can easily use a temporary keyring - see "--keyring file"

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 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)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUpcCrAAoJEPw7F94F4TaghTEQAKX1odInTX1bewigLfrhTX7t
inVyTS7oxdA/AsiRayx3jo2lj+tGoe+eYcRphhPmeclQ5hk8pL8bgpRrjJWfpuwL
GIRj1Pr7Z6ArnxdotrVlNQ9pl28K/RlcXE4Ogoq9cfaAvoMfY6TGU5T7gqO7vywN
gyGFTE0C+ol4qf3PzlSUmIojn1KFsgzJhufHAKCD6Oi0EVrbk1JtfbKe4zqwB2Iy
AhMHVX7cExUn3JlXeEzBwmeMBtsZvLjfb2OCWu0ULlSO/yXDd09jbPdscoVH3iPs
zZBpTIN4efprvd9HahqDLqRGTpUCAvTRGotSlA9suynavRZPCvFs7J7gpXam/o2b
Q1di1OJSCff+Hoax0RXH80eHzzlyVRwNMnogPtayw6OStKET5AggC+quN38SNV20
A23LFvx7b/IN5ZYC3mcdVWR4oMPrS+OPdIF2WDY82CmCS0Djk5CrzgXVfYF4MsdG
7aol0QIkEIAkhJR+5SwqgjMd4mXrX5WWdPbsiCeWuIPWdmOdF0y2I7agSnljZpIT
dSQSNS2wIbTXFaqkxeMHXk2NIlTjQUMWNmTiHa9BWJLACQoHqwI/YAAMzF2OjoS9
7svQiHgULozxrC3U9dtlN/abqQDlnmK4Pze2WwRRSABrjz5l1D3bUBAMugjpyQ/E
3zO33S9H/AcsWKYpEXfx
=YG2W
-----END PGP SIGNATURE-----


From kloecker at kde.org  Thu Jan  1 22:55:18 2015
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 1 Jan 2015 22:55:18 +0100
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
References: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
 <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
Message-ID: <1730353.2En7Uh9f3Y@collossus.ingo-kloecker.de>

On Thursday 01 January 2015 04:59:37 Kelly Dean wrote:
> Getting the fingerprint should not require importing the key. Getting the
> fingerprint should not require writing to any file at all. It should only
> require reading.

I haven't tried with gpg 1.4, but with gpg 2.0.22 it's as easy as

# gpg --with-fingerprint key.gpg


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150101/ec3343e2/attachment.sig>

From kloecker at kde.org  Thu Jan  1 23:26:09 2015
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 1 Jan 2015 23:26:09 +0100
Subject: gpg vs smime, snowden etc
In-Reply-To: <87ppay5po1.fsf@mat.ucm.es>
References: <87ppay5po1.fsf@mat.ucm.es>
Message-ID: <1775539.bvqa6kmzgr@collossus.ingo-kloecker.de>

On Thursday 01 January 2015 19:19:58 Uwe Brauer wrote:
> Hello
> 
> I am sorry if this is a little off-topic but I am not sure where to ask.
> I use both, gpg and smime (the later either with gpgsm or with
> thunderbird)
> 
> Recently the German news magazine ?Der Spiegel? [1] published more of
> the ?Snowden files?, which reveal that gpg is NSA safe[2].
> 
> Does anybody know whether smime has the same level of security? There
> are at least two possible weak spots.
> 
>     -  the generation and sign of the certificate, ideally the
>        generation of the keypair should be done by the crypto module of
>        the browser, but that could be hacked...
> 
>     -  the length of the key for the symmetric encryption.
> 
> Maybe there are others.

The PKI resp. the CAs are the weakest spot of S/MIME (if you rely on the 
S/MIME PKI for certificate verification).


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150101/73a87047/attachment.sig>

From gabriel.niebler at gmail.com  Thu Jan  1 22:28:40 2015
From: gabriel.niebler at gmail.com (Gabriel Niebler)
Date: Thu, 01 Jan 2015 22:28:40 +0100
Subject: Updating public key problem
In-Reply-To: <54A57F98.3070503@zoho.com>
References: <mailman.18499.1420080307.28939.gnupg-users@gnupg.org>
 <54A57F98.3070503@zoho.com>
Message-ID: <54A5BC08.5000102@gmail.com>

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

Am 01.01.2015 um 18:10 schrieb Linux Debian:
(...)
> I've updated my GnuPG key and send to keyservers. What I updated ?
>  I've just deleted 2 expired subkeys and added one with a longer 
> (in 2015) expiration. But (...) those 2 expired subkeys still 
> appear (...)

Yes, key servers are purely cumulative.
Information cannot be deleted or made to disappear from them,
including revoked or expired (sub)keys.
This is by design, so that noone can e.g. remove someone else's
(sub)key(s), signatures, preferences etc. from the key server network.

> (...) and that's why, in my opinion, why the sending an encrypted 
> message doesn't work by the free service like - 
> https://encrypt.to/linuxdebian at zoho.com Before the expirationd
> date of those 2 keys, the encrypt.to service worked.

I don't know that service, but if that is the case, then I suggest you
take it up with the people who run the encrypt.to service. If it
cannot handle expired subkeys then they don't implement the OpenPGP
standard correctly.

Cheers
gabe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUpbwIAAoJEO7XEikU4kSzr0gH/jWaRd2+8f/uv74iRjRkVdyK
w8/wNFC1kgnnpCknabtQWZsyIdtltSSuH3Eg8RxuGQWqLAcguJ/5rvPO1DxyW142
7kuUZhOFHWKKzH6oK8jqCnf/FGEu4TSg20Qzf3KGiOB+AKGYAMEfEHo5KjwZfxYi
WRwMRhLj/eLa9HNbUQvTPTpVlZFhy7ueXB0kt7mhXt5yasa9QQIEX1YlPgr/QTL+
R8uHC3GMBHzHzcj/YqzXCx/dPX8gsnfdodEMgSzPvuGsnj3YJ65kuCSdYYgUpoJ4
MKJp+rldUQAFb/zMDObSHCgTOej3hP+yNHoTPnGC4JFiW7RJUBYhL+NVWG9wcaM=
=5yoP
-----END PGP SIGNATURE-----


From dougb at dougbarton.email  Fri Jan  2 00:11:14 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Thu, 01 Jan 2015 15:11:14 -0800
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
References: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
 <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
Message-ID: <54A5D412.4020905@dougbarton.email>

On 12/31/2014 08:59 PM, Kelly Dean wrote:
> I thought my original message made clear that I was trying to get the fingerprint. The point of my message was that GPG apparently requires pointless circumlocution for this simple function.

No, your original message contained nothing but the output of various 
commands. I'm sure it was clear to you, and it may even have been clear 
to some on the list. But assuming that people can infer meaning from 
such a post is not really a strategy for success. :)

Doug



From rjh at sixdemonbag.org  Fri Jan  2 00:38:42 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 1 Jan 2015 18:38:42 -0500
Subject: photo-ID
In-Reply-To: <702A2B4C-3A96-49EC-8A1B-C9B65CF4C956@mykolab.com>
References: <54A3EF49.2050300@nordnet.fr>
 <05827616-4C64-4E5D-B80C-0B6B4F0C90CC@sixdemonbag.org>
 <2A75FF8F-EE33-4B43-83A7-6E3AAF8C2F4B@mykolab.com>
 <D10BEF77-7525-453C-852D-BBFE73AB335C@sixdemonbag.org>
 <702A2B4C-3A96-49EC-8A1B-C9B65CF4C956@mykolab.com>
Message-ID: <3124D1FC-9219-4399-95F7-5436B47DBD6E@sixdemonbag.org>

> Sorry if I misunderstood, but I didn?t say that the photo ID should
> be allowed to be as large as possible, and this is not allowed anyway
> by, for example, apps like GPG Keychain.

It *is* allowed by the spec, and it?s the spec that?s the problem here.

> But I was wondering ? instead of attaching a photo to a public key,
> why not attach a hash of the photo using an image hashing
> algorithm?

This is sort of what keybase.io does; it lets you post cryptographically-signed statements like ?this is my Twitter account? to let other people have confidence that a given social media account really does belong to you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150101/a0765a14/attachment-0001.bin>

From dougb at dougbarton.email  Fri Jan  2 00:47:27 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Thu, 01 Jan 2015 15:47:27 -0800
Subject: The praise of GnuPG @31C3
In-Reply-To: <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
 <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
 <54A487DA.9000708@dougbarton.email>
 <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>
Message-ID: <54A5DC8F.4030408@dougbarton.email>

On 12/31/2014 06:40 PM, Robert J. Hansen wrote:
> The protocol was secure: you just had to configure it correctly.

Yes, thank you for your tidy summary of "Security 101." :)

What I'm looking for is some sort of concrete information about "When 
ssh is configured <this way> the NSA can break it." I've seen quite a 
few sites make the claim that "zomg, ssh is broken!" but haven't yet 
seen any specifics.

Doug



From 2014-667rhzu3dc-lists-groups at riseup.net  Fri Jan  2 01:28:44 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Fri, 2 Jan 2015 00:28:44 +0000
Subject: GPG (v. 1.4.12) is not user-friendly
In-Reply-To: <1730353.2En7Uh9f3Y@collossus.ingo-kloecker.de>
References: <CANy18xBf8fXbGKhDYgW6WQdgZ_VmjCRXziFvFEsCRoqCDvAJBw@mail.gmail.com>
 <dcl7X40MOcWSA4MhSJGXXuGTzbCY1Nd53TWuGoSeNka@local>
 <1730353.2En7Uh9f3Y@collossus.ingo-kloecker.de>
Message-ID: <16910466044.20150102002844@my_localhost>

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

Hi


On Thursday 1 January 2015 at 9:55:18 PM, in
<mid:1730353.2En7Uh9f3Y at collossus.ingo-kloecker.de>, Ingo Kl?cker
wrote:


> I haven't tried with gpg 1.4, but with gpg 2.0.22 it's
> as easy as

> # gpg --with-fingerprint key.gpg


I just tested with GnuPG 1.4.18 and it worked.



- --
Best regards

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

The man who really wants to do something finds a way,
the other finds an excuse.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUpeZPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwAN4H/2C+9NRhXmZkT7ZHxBOGTJ8v
IAKJv7svgbe1qHRic0WeT4nEVupmAUiAnlpHvuhFAts2NiFGFn2uFXeMsGD5w4Yw
/pjSMAbxtHtzY1mS4J4YoHtl9xtjttNCItF5D31/h7NKX5WEZSPlS1jI7U3gPc2B
oVmzV0BwOc0xu9zQO4xj1OC/EkEO1wC0VoGkP67tDCFXcAAyE3OOKSmvWjSGvcAi
kuf57Mj5qD6EYqxpc3NruKDFBYObZjnVt2NbR5U2hLEdVEAxWZtCMSC9XZidYSnE
TADG2jYO7ZoSVwYFAIlQDf4py55ZX3gVZqAH6iR619SUj3NCSekeFQLvNpV16emI
vgQBFgoAZgUCVKXmWV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45LSlAQBLI61c+4uEI/+cAu9ufHNPQWCZ
xXSSDKnkEtqC/i71EgEAFyiAXzniocZzNHUv+hA9X58amPyy5pxRaZjqk1+sGQc=
=NIoa
-----END PGP SIGNATURE-----



From rjh at sixdemonbag.org  Fri Jan  2 01:31:51 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 1 Jan 2015 19:31:51 -0500
Subject: The praise of GnuPG @31C3
In-Reply-To: <54A5DC8F.4030408@dougbarton.email>
References: <54A41C5B.3050507@josuttis.de> <54A4846B.9030102@dougbarton.email>
 <CABETfimsKzL7yixfjJN9erCG6p8_qV9us2y-mj3gAFs8s21CWw@mail.gmail.com>
 <54A487DA.9000708@dougbarton.email>
 <A9148AFA-3E6E-4ED3-A19A-F5669A3B222A@sixdemonbag.org>
 <54A5DC8F.4030408@dougbarton.email>
Message-ID: <2AFC841E-1C34-4BF0-96FF-A22BDB51BF53@sixdemonbag.org>

> What I'm looking for is some sort of concrete information about "When ssh is configured <this way> the NSA can break it." I've seen quite a few sites make the claim that "zomg, ssh is broken!" but haven't yet seen any specifics.

First, my usual reminder: don?t focus on the three-letter Voldemort.  The world is a bigger place than that and there are lots of threats, including many non-government actors.

Second ? I suspect those who know won?t tell, and those who claim to know will steadfastly refuse to demonstrate it.  Which tells you nothing you didn?t already know, I?m sorry.  :(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150101/aaf274c9/attachment.bin>

From jesper at graffen.dk  Fri Jan  2 11:33:15 2015
From: jesper at graffen.dk (Jesper Hess Nielsen)
Date: Fri, 02 Jan 2015 11:33:15 +0100
Subject: Can't import private key to GnuPG 2.1.1 on Windows 8 x64
Message-ID: <54A673EB.3060907@graffen.dk>

Hi all!

I just installed the latest GnuPG 2.1.1 on my main Windows PC and tried
to import my private key. However, it fails with a message from gpg-agent:

gpg: key 0x416C5A0DD9FA2EE5/0x416C5A0DD9FA2EE5: error sending to agent:
End of file
gpg: error building skey array: End of file

In the Windows Event Viewer I get the following notification of a crash:

Faulting application name: gpg-agent.exe, version: 2.1.1.2240, time
stamp: 0x549051a1
Faulting module name: libgcrypt-20.dll, version: 1.6.2.45971, time
stamp: 0x54905081
Exception code: 0xc0000005
Fault offset: 0x0002a242
Faulting process id: 0x1050
Faulting application start time: 0x01d026705b3bc20a
Faulting application path: c:\Program Files
(x86)\GNU\GnuPG\bin\gpg-agent.exe
Faulting module path: c:\Program Files (x86)\GNU\GnuPG\bin\libgcrypt-20.dll
Report Id: b586c710-9263-11e4-827f-002522a499c0
Faulting package full name:
Faulting package-relative application ID:

Any ideas what might be going wrong here?

-- 
Jesper Hess Nielsen

GPG Key Fingerprint: 7818 9E24 005B 0933 0CF6 2536 416C 5A0D D9FA 2EE5



From jesper at graffen.dk  Fri Jan  2 11:04:57 2015
From: jesper at graffen.dk (Jesper Hess Nielsen)
Date: Fri, 02 Jan 2015 11:04:57 +0100
Subject: Can't import private key to GnuPG 2.1.1 on Windows 8 x64
Message-ID: <54A66D49.8080207@graffen.dk>

Hi all!

I just installed the latest GnuPG 2.1.1 on my main Windows PC and tried
to import my private key. However, it fails with a message from gpg-agent:

gpg: key 0x416C5A0DD9FA2EE5/0x416C5A0DD9FA2EE5: error sending to agent:
End of file
gpg: error building skey array: End of file

In the Windows Event Viewer I get the following notification of a crash:

Faulting application name: gpg-agent.exe, version: 2.1.1.2240, time
stamp: 0x549051a1
Faulting module name: libgcrypt-20.dll, version: 1.6.2.45971, time
stamp: 0x54905081
Exception code: 0xc0000005
Fault offset: 0x0002a242
Faulting process id: 0x1050
Faulting application start time: 0x01d026705b3bc20a
Faulting application path: c:\Program Files
(x86)\GNU\GnuPG\bin\gpg-agent.exe
Faulting module path: c:\Program Files (x86)\GNU\GnuPG\bin\libgcrypt-20.dll
Report Id: b586c710-9263-11e4-827f-002522a499c0
Faulting package full name:
Faulting package-relative application ID:

Any ideas what might be going wrong here?

-- 
Jesper Hess Nielsen

GPG Key Fingerprint: 7818 9E24 005B 0933 0CF6 2536 416C 5A0D D9FA 2EE5



From wk at gnupg.org  Fri Jan  2 13:26:31 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 Jan 2015 13:26:31 +0100
Subject: Can't import private key to GnuPG 2.1.1 on Windows 8 x64
In-Reply-To: <54A673EB.3060907@graffen.dk> (Jesper Hess Nielsen's message of
 "Fri, 02 Jan 2015 11:33:15 +0100")
References: <54A673EB.3060907@graffen.dk>
Message-ID: <87h9w9fjwo.fsf@vigenere.g10code.de>

On Fri,  2 Jan 2015 11:33, jesper at graffen.dk said:

> gpg: key 0x416C5A0DD9FA2EE5/0x416C5A0DD9FA2EE5: error sending to agent:
> End of file

Can you please enable logging for the gpg-agent?  You may either use
GPA's backend preferences to do this or use a text editor to change or
create gpg-agent.conf.  The file shall be in the GnuPG homedir (run
"gpgconf --list-dirs").

Useful options for gpg-agent.conf are

  log-file c:/temp/gpg-agent.log
  debug 1024
  verbose

The run again and check that file.  It may give some more clues on the
error location.


Salam-Shalom,

   Werner

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



From sben1783 at yahoo.de  Fri Jan  2 13:14:26 2015
From: sben1783 at yahoo.de (sben1783)
Date: Fri, 02 Jan 2015 13:14:26 +0100
Subject: Craft public key so that private key equals given string (my
 =?UTF-8?Q?password=29=3F?=
Message-ID: <65195a4af1ac8692eca3bf73342ab980@sun>

 Hi all,

 maybe this question is completely stupid and only shows I didn't 
 understand anything about encryption, but anyway I'm really curious:

 I want to store some of my private files encrypted on my NAS. Until 
 now, I'm using --symmetric for encryption with a (think so) strong 
 password that I can remember. Now I want to make this "process" more 
 robust and more user-friendly - I don't want to enter my password every 
 time I'm encrypting a file. I want to sort of store the password in a 
 short script so that I just type "my_gpg /foo/bar/" and it gets done 
 without further input from me.

 Yes, I know I shouldn't store my password in a script;-) Acutally I 
 don't want to store it anywhere. Also I don't want to depend on a 
 private key that is stored somewhere. What I'd like to do is: create a 
 public key so that the corresponding private key equals my given 
 password. I could store that public key in my script and, for 
 decryption, just enter my remembered password as I do it with the 
 --symmetric option I'm currently using.

 Does this make any sense? Is it possible or did I miss some other way 
 to achieve my goal (no password for encryption, no private key for 
 decryption)?

 Thanks
 Ben

 P.S.: I also don't really want to set up a password agent on every 
 machine I want to encrypt files on.


From jesper at graffen.dk  Fri Jan  2 14:54:00 2015
From: jesper at graffen.dk (Jesper Hess Nielsen)
Date: Fri, 02 Jan 2015 14:54:00 +0100
Subject: Can't import private key to GnuPG 2.1.1 on Windows 8 x64
In-Reply-To: <87h9w9fjwo.fsf@vigenere.g10code.de>
References: <54A673EB.3060907@graffen.dk> <87h9w9fjwo.fsf@vigenere.g10code.de>
Message-ID: <54A6A2F8.4050203@graffen.dk>


On 02-01-2015 13:26, Werner Koch wrote:
> The run again and check that file.  It may give some more clues on the
> error location.

This is the output generated to the log file:

2015-01-02 14:51:30 gpg-agent[8956] listening on socket
'C:/Users/JesperHess/AppData/Roaming/gnupg/S.gpg-agent'
2015-01-02 14:51:30 gpg-agent[8956] gpg-agent (GnuPG) 2.1.1 started
2015-01-02 14:51:32 gpg-agent[8956] handler 0x2 for fd 364 started
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK Pleased to
meet you
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- RESET
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- OPTION
allow-pinentry-notify
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- OPTION
agent-awareness=2.1.0
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- AGENT_ID
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> ERR 67109139
Unknown IPC command <GPG Agent>
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- KEYWRAP_KEY
--import
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> D @?X?z=???????(??
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- SETKEYDESC
Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22Jesper+Hess+Nielsen+(Graffen)+<jesper at graffen.dk>%22%0A2048-bit+DSA+key,+ID+0x416C5A0DD9FA2EE5,%0Acreated+2014-04-06.%0A
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> OK
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- IMPORT_KEY
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C -> [[Confidential
data not shown]]
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- [[Confidential
data not shown]]
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- [[Confidential
data not shown]]
2015-01-02 14:51:32 gpg-agent[8956] DBG: chan_0000016C <- [[Confidential
data not shown]]




-- 
Jesper Hess Nielsen

GPG Key Fingerprint: 7818 9E24 005B 0933 0CF6 2536 416C 5A0D D9FA 2EE5



From beckus at beckus.eu  Fri Jan  2 14:18:21 2015
From: beckus at beckus.eu (Christopher Beck)
Date: Fri, 02 Jan 2015 14:18:21 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <65195a4af1ac8692eca3bf73342ab980@sun>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
Message-ID: <16170574.HaalSukMZ9@maxwell>

On Friday 02 January 2015 13:14:26 sben1783 wrote:
>  Hi all,
> 
>  maybe this question is completely stupid and only shows I didn't
>  understand anything about encryption, but anyway I'm really curious:
> 
>  I want to store some of my private files encrypted on my NAS. Until
>  now, I'm using --symmetric for encryption with a (think so) strong
>  password that I can remember. Now I want to make this "process" more
>  robust and more user-friendly - I don't want to enter my password every
>  time I'm encrypting a file. I want to sort of store the password in a
>  short script so that I just type "my_gpg /foo/bar/" and it gets done
>  without further input from me.
> 
>  Yes, I know I shouldn't store my password in a script;-) Acutally I
>  don't want to store it anywhere. Also I don't want to depend on a
>  private key that is stored somewhere. What I'd like to do is: create a
>  public key so that the corresponding private key equals my given
>  password. I could store that public key in my script and, for
>  decryption, just enter my remembered password as I do it with the
>  --symmetric option I'm currently using.
> 
>  Does this make any sense? Is it possible or did I miss some other way
>  to achieve my goal (no password for encryption, no private key for
>  decryption)?
> 
>  Thanks
>  Ben
> 
>  P.S.: I also don't really want to set up a password agent on every
>  machine I want to encrypt files on.
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi,

you can use the asymmetric variant: Generate a encryption key pair, store the 
private key on your save place and the public key on your computer. Then you 
can encrypt files without any password and decrypt them using your private key.

Dies this describe your purpose, except the fact you don't want an extra 
private key? But think of the meaning of symmetric encryption: This meas, both 
keys are the same and there is no difference between the private and public 
key. So AFAIK you can't get around using an asymmetric key pair.

Regards,
Beckus

-- 
Christopher Beck

Gerhart-Hauptmann-Str. 1
91058 Erlangen
Tel.: 09131 / 9245437
Fax.: 09131 / 8148708
Jabber: beckus at jabber.org
EPVPN: (+49 221 59619) - 5232
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150102/216743ff/attachment.sig>

From sben1783 at yahoo.de  Fri Jan  2 15:13:53 2015
From: sben1783 at yahoo.de (Ben Staude)
Date: Fri, 02 Jan 2015 15:13:53 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <16170574.HaalSukMZ9@maxwell>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell>
Message-ID: <54A6A7A1.4030501@yahoo.de>

[...]

> Hi,
>
> you can use the asymmetric variant: Generate a encryption key pair, store the
> private key on your save place and the public key on your computer. Then you
> can encrypt files without any password and decrypt them using your private key.
>
> Dies this describe your purpose, except the fact you don't want an extra
> private key? But think of the meaning of symmetric encryption: This meas, both
> keys are the same and there is no difference between the private and public
> key. So AFAIK you can't get around using an asymmetric key pair.

I'm ok with asymmetric encryption as this will AFAIK be the only way to 
get rid of entering the password for every encryption. But as I 
mentioned I don't want to depend on a private key stored somewhere, but 
I'd like to use my password as the private key. I would need a keypair 
where the public key is some I-don't-care-ascii-bulk, but the private 
key is exactly my password.

Ben


From 2014-667rhzu3dc-lists-groups at riseup.net  Fri Jan  2 15:30:03 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Fri, 2 Jan 2015 14:30:03 +0000
Subject: Updating public key problem
In-Reply-To: <54A57F98.3070503@zoho.com>
References: <mailman.18499.1420080307.28939.gnupg-users@gnupg.org>
 <54A57F98.3070503@zoho.com>
Message-ID: <559812766.20150102143003@my_localhost>

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

Hi


On Thursday 1 January 2015 at 5:10:48 PM, in
<mid:54A57F98.3070503 at zoho.com>, Linux Debian wrote:


> those 2 expired subkeys still appear

That should be the case. But the key you attached has only one subkey
(0x1181AAE315915635), and that is all I can see in the web interface
of three different keyservers. I also do not pick up any additional
subkeys in GnuPG if I refresh your key from a keyserver.



> and that's why, in
> my opinion, why the sending an encrypted message
> doesn't work by the free service like -
> https://encrypt.to/linuxdebian at zoho.com Before the
> expirationd date of those 2 keys, the encrypt.to
> service worked.

If that is the reason, there must be an awful lot of keys that would
not work with that service. However, in the absence of error messages
it is hard to diagnose the reason. Maybe the people who run encrypt.to
might be willing to help you.

My current and previous keys don't work there, and nor do a couple of
test keys I have knocking around. Two of the four cause the page to
freeze and block input to the message compose window, with no error
message at all - just like yours does. One generates a message saying
there is no key id associated with that email address, or there is no
email address associated with that key id - yet I can retrieved it
from a keyserver by searching on the email address. The fourth one
encrypts the message in the box, then (because the UID intentionally
intentionally contains an unrouteable address) produces the rather
uninformative error message "Oops! Something went wrong. Please try
again."



> Thanks for any tip how to correctly update or what to
> do, so my public key would be possible to be used by
> encrypt.to for those who wanna send me a private
> message.

Does encrypt.to cope with 4096-bit keys and SHA256 binding signatures?
What size was your old encryption subkey?



- --
Best regards

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

ETHERNET(n): device used to catch the Ether bunny
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUpqtsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwc+sIAKwD5ww3Dx1vOMYxD5xW56Gz
xOk/qWbTtCSRNlYdKoqlDCAqRzJBObN8xDmFjSkx/xOVXHSN8+5Y4SBzLtZ79uGW
LpM/62zZwQa3BqYgBz3TyAty2Atsfai94opDkIrUQI2nV0Z4fOHeEWDXVj2qWZY4
j8hBn0iZMnzwslQkEY3S6ZXdeDUCVP1TkYowSo5wlvlTc3KaQCjHY24mthVM3mpT
2MaBYFpp6Lun8xkfm6Zd/Pye48PiwR5HxuBnnQD3L4s6PBDHIWVBD/QozkDdLSvM
PgIIKuEfCRa2sh4CFiPqI+epOnIkJq3noYp5NO8kWyw7hDIH8QwYOHNto+KowmiI
vgQBFgoAZgUCVKarbF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KIQAQDF7OS1wnJu7VhFwhbZ8Uj9byTr
INYY7KtuQZQFN8pT5gEAsnskB0jHrp3FqCAUgsPzbAgt+Z9KyRelHd5IPbEF0g4=
=G4T1
-----END PGP SIGNATURE-----



From beckus at beckus.eu  Fri Jan  2 15:52:52 2015
From: beckus at beckus.eu (Christopher Beck)
Date: Fri, 02 Jan 2015 15:52:52 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <54A6A7A1.4030501@yahoo.de>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
Message-ID: <8147372.Ai0z4QYZv3@maxwell>


On Friday 02 January 2015 15:13:53 Ben Staude wrote:
> [...]
> 
> > Hi,
> > 
> > you can use the asymmetric variant: Generate a encryption key pair, store
> > the private key on your save place and the public key on your computer.
> > Then you can encrypt files without any password and decrypt them using
> > your private key.
> > 
> > Dies this describe your purpose, except the fact you don't want an extra
> > private key? But think of the meaning of symmetric encryption: This meas,
> > both keys are the same and there is no difference between the private and
> > public key. So AFAIK you can't get around using an asymmetric key pair.
> 
> I'm ok with asymmetric encryption as this will AFAIK be the only way to
> get rid of entering the password for every encryption. But as I
> mentioned I don't want to depend on a private key stored somewhere, but
> I'd like to use my password as the private key. I would need a keypair
> where the public key is some I-don't-care-ascii-bulk, but the private
> key is exactly my password.
> 
> Ben
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

Since the keys (depending on the algorithm - I am not an expert on that) are 
AFAIK calculated from random primes the reverse task, e.g. finding a public key 
to a given private key, sounds like a bit of reverse engineering. And I think 
(and if the reverse task has the same complexity I really hope it ;-)) it 
won't be possible.

Another thought: You could generate a Keypair with a keysize small enough to 
remember als a password but then I think the key size is that small it won't 
be secure anymore.

But sorry, I am not an expert on that...

-- 
Christopher Beck

Gerhart-Hauptmann-Str. 1
91058 Erlangen
Tel.: 09131 / 9245437
Fax.: 09131 / 8148708
Jabber: beckus at jabber.org
EPVPN: (+49 221 59619) - 5232
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150102/c668c01d/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Fri Jan  2 16:29:28 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Fri, 2 Jan 2015 15:29:28 +0000
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <54A6A7A1.4030501@yahoo.de>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
Message-ID: <1154947722.20150102152928@my_localhost>

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

Hi


On Friday 2 January 2015 at 2:13:53 PM, in
<mid:54A6A7A1.4030501 at yahoo.de>, Ben Staude wrote:


> But as I  mentioned I don't want to
> depend on a private key stored somewhere, but I'd like
> to use my password as the private key. I would need a
> keypair where the public key is some
> I-don't-care-ascii-bulk, but the private  key is
> exactly my password.


Quoting from [0]:-

        When you generate a key pair, you do so with:

             1. a deterministic procedure;
             2. a source of random bits.

        For instance, with RSA, you generate p and q by creating
        random odd numbers of the right size and looping until a prime
        number is found. For a given random source, the whole process
        is deterministic: given the same random bits, this will find
        the same primes p and q.

        Hence you can develop a PRNG seeded by a secret key K and use
        it as random source for the key generation process. Whenever
        you need the private key, you run the key generation process
        again, using K as input. And voil?! Your private key, the one
        you need to store, is now K.



[0] <https://stackoverflow.com/questions/3812416/custom-assymetric-cryptography-algorithm>



- --
Best regards

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

Confusion is always the most honest response
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUprloXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwX0gH/Aiu7hzfr5cNxI4EYSYenIXw
oj/VUyVlkbrdveiPNL3A2xjCWDHK8f915kYp7MgAqSWP6utAt8iepp4BTXg4ZQR3
SR2lSMR1sIvCSJThNHiXvT4PtvqaCZBwGyXB+QOtHxCkPos2Q+pl9zrJ42ZyQjqv
EgCeygLelOoaa4E3k01uiYVAP2FjZWHu8zIhJXFBK3fLdYQjcSfZaW1udK26kaJW
IcMXhUR6QX2DtdcM98o8hIKlCgWeu3rawoPaS6pzinzpgb38Z+JNx6DZY9qUQopr
ouMOmV6u7d/lXYZn93zCC5731HO1On8mZaQJGR3TZZZyY+G0QUVdt5R25LmOAkqI
vgQBFgoAZgUCVKa5bl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45BrgAQD2qgZm3vkJigsuMq/MqKcVI1MZ
C6Ag2W2w41MsDxgH7QEApa49lZOtUvnNrRYGKG561urKOzwcY3E1ueRTzf+rMwk=
=ZJAL
-----END PGP SIGNATURE-----



From sben1783 at yahoo.de  Fri Jan  2 17:04:33 2015
From: sben1783 at yahoo.de (Ben Staude)
Date: Fri, 02 Jan 2015 17:04:33 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <8147372.Ai0z4QYZv3@maxwell>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
 <8147372.Ai0z4QYZv3@maxwell>
Message-ID: <54A6C191.9000906@yahoo.de>

[...]

> Another thought: You could generate a Keypair with a keysize small enough to
> remember als a password but then I think the key size is that small it won't
> be secure anymore.

Would a key size matching the size of my password (say, 15 characters) 
be less secure than symmetric encryption with that password?

Another thought would be to just paste the private key (encrypted by my 
password) to the gpg'd files? Of course my private key would then be 
sort of "public", but still it is as secure as using symmetric 
encryption with that password in the first place (but allowing me to use 
the real public key in my script)? Does gpg by any chance happen to 
offer some feature like that..?

ben


From peter at digitalbrains.com  Fri Jan  2 17:11:19 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 02 Jan 2015 17:11:19 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <65195a4af1ac8692eca3bf73342ab980@sun>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
Message-ID: <54A6C327.6010703@digitalbrains.com>

On 02/01/15 13:14, sben1783 wrote:
> What I'd like to do is: create a public key so that the corresponding private
> key equals my given password.

This is possible with elliptic curve cryptography, although you should realise
that a passphrase usually contains a lot less entropy than a private key based
on random numbers. This means it is possible to try passphrases for your public
key and try them out as the secret key, which is not possible with ordinary
secret keys.

OpenPGP and GnuPG do not support this, though.

An example of software using this property of ECC keys is SECCURE[1]. This is
not a recommendation, and I'm also not recommending against it. I simply make no
statement as to its security. Other than what I will say now, that is.

The only input to key generation in SECCURE is your password; there is no
salting. The same password leads to the same public key.

If you were to use, for instance, PBKDF2 to generate the public key, you'd at
least strengthen the password against a number of attacks such as rainbow
tables. I don't know why the author of SECCURE didn't use that; it would
increase the size of the public key by at least 13 characters (making it 50%
longer) but it seems a good tradeoff to me.

Cheers,

Peter.

[1] http://point-at-infinity.org/seccure/

-- 
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 peter at digitalbrains.com  Fri Jan  2 17:14:22 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 02 Jan 2015 17:14:22 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <54A6C191.9000906@yahoo.de>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
 <8147372.Ai0z4QYZv3@maxwell> <54A6C191.9000906@yahoo.de>
Message-ID: <54A6C3DE.5020106@digitalbrains.com>

On 02/01/15 17:04, Ben Staude wrote:
> Another thought would be to just paste the private key (encrypted by my
> password) to the gpg'd files? Of course my private key would then be sort of
> "public", but still it is as secure as using symmetric encryption with that
> password in the first place (but allowing me to use the real public key in my
> script)?

Yes, that is perfectly possible. It is just as secure as using gpg's --symmetric
mode with the same password for each file you encrypt.

> Does gpg by any chance happen to offer some feature like that..?

What feature are you asking for? It seems to me it doesn't need a feature,
doesn't need explicit support. You write a copy of the key to the same directory
as where you store the encrypted files. You write a script that fetches the
private key from there into GnuPG's secret keyring. GnuPG never needs to know ;).

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 peter at digitalbrains.com  Fri Jan  2 17:37:19 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 02 Jan 2015 17:37:19 +0100
Subject: Key selection
In-Reply-To: <03B194EF-130A-4E0E-9E05-D9AF1183155F@mykolab.com>
References: <57C2F421-F088-44A5-8007-F4F6B36235F3@mykolab.com>
 <549F0B75.1070203@dougbarton.email> <54A42A54.2090509@fifthhorseman.net>
 <03B194EF-130A-4E0E-9E05-D9AF1183155F@mykolab.com>
Message-ID: <54A6C93F.3010000@digitalbrains.com>

On 31/12/14 22:09, Sandeep Murthy wrote:
> This is clearly a bug, and surely there?s an easy fix for it

I respectfully disagree on both. Editing a revoked key might not have a use, but
editing an expired key is perfectly valid, i.e., to extend its expiry date.
The matching behaviour is also clear and known: without being specific, one of
the matching keys. While being specific and applying to 1.4 and 2.0: the first
one in the keyring. With all respect, that this doesn't match what you'd like
to see is something else than "this is clearly a bug".

And whether there is an easy fix can't really be said without knowing the
internal structure of GnuPG. I think matching the first key you find needs to
know nothing apart from the key ID and the UID's. Matching other
characteristics means you need to parse more details of the key, which might not
be done until after key selection. It is not clear cut that this is an easy fix.
It might be, it might not be. Patches might be welcome if it's a small patch
with clear behaviour, i.e., easily verified as correct and complete. I'm
inclined to think the patch is not that small and clear, though.

> This issue is specific to the command line program, not any GUI based 
> program like Keychain (from MacGPG2 suite), because there the user can see 
> the keys and know which one to edit.

For the command line, it's a two-step process which requires the user to repeat
8 hex characters unless they have a mouse: they could also copy-paste. Surely
this is not much work.

$ gpg2 -k lebbing
pub   1024R/3E4FCA14 2006-03-31 [revoked: 2009-11-12]
uid       [ revoked] Peter Lebbing <peter at digitalbrains.com>

pub   2048R/DE500B3E 2009-11-12 [expires: 2015-10-27]
uid       [ultimate] Peter Lebbing <peter at digitalbrains.com>
sub   2048R/DE6CDCA1 2009-11-12 [expires: 2015-10-27]
sub   2048R/73A33BEE 2009-11-12 [expires: 2015-10-27]
sub   2048R/B65D8246 2009-12-05 [expires: 2015-10-27]

$ gpg2 --edit-key de500b3e

Possibly add a third step for a failed "gpg2 --edit-key lebbing" command as
the first step.

Conflicting short ID's make the first step above a bit more verbose but is
really rare:

$ gpg2 --keyid-format long -k lebbing

In this case, you might want to add keyid-format to your gpg.conf so you can
save on all that typing ;).

Conflicting long ID's are really, really rare but would make it a lot more
complicated.

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 peter at digitalbrains.com  Fri Jan  2 18:07:40 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 02 Jan 2015 18:07:40 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <54A6C327.6010703@digitalbrains.com>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <54A6C327.6010703@digitalbrains.com>
Message-ID: <54A6D05C.2040006@digitalbrains.com>

On 02/01/15 17:11, Peter Lebbing wrote:
> it would increase the size of the public key by at least 13 characters
> (making it 50% longer) but it seems a good tradeoff to me.

Minor nitpick: I meant 12 characters. I didn't want to think about it and simply
used 'echo 12345678|base64|wc' but that included the newline (should have
specified -n to echo).

And also, it's only an increase of 50% when you use a 160-bit curve; it gets
relatively less for larger curves.

The reason I'm taking 64 bits as the size of the increase is that PBKDF2
recommends at least 64 bits of salting.

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 sben1783 at yahoo.de  Fri Jan  2 21:29:26 2015
From: sben1783 at yahoo.de (sben1783)
Date: Fri, 02 Jan 2015 21:29:26 +0100
Subject: Craft public key so that private key equals given string (my
 =?UTF-8?Q?password=29=3F?=
In-Reply-To: <54A6C3DE.5020106@digitalbrains.com>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
 <8147372.Ai0z4QYZv3@maxwell> <54A6C191.9000906@yahoo.de>
 <54A6C3DE.5020106@digitalbrains.com>
Message-ID: <49993896d3ca57d0db8c46e48a7f6b05@sun>

 On Fri, 02 Jan 2015 17:14:22 +0100, Peter Lebbing 
 <peter at digitalbrains.com> wrote:

 [...]

> What feature are you asking for? It seems to me it doesn't need a 
> feature,
> doesn't need explicit support. You write a copy of the key to the
> same directory
> as where you store the encrypted files. You write a script that 
> fetches the
> private key from there into GnuPG's secret keyring. GnuPG never needs
> to know ;).

 Oh, yes that really covers what I wrote... What I actually meant to 
 write was: couldn't gpg embed the private key into the gpg'd file, like 
 as a part of the header? That way, no matter what happens to my gpg'd 
 file in terms of moving around or whatever, the private key is with it 
 (I personally wouldn't mind some extra bytes with each file). On 
 decryption, gpg would find the private key in the header and just ask me 
 for its passphrase like it does with symmetric encryption.

 Maybe this isn't such a common use case, but I think for me it would 
 perfectly make sense;)

 Ben


From cvimail81 at gmail.com  Fri Jan  2 20:34:44 2015
From: cvimail81 at gmail.com (Egon)
Date: Fri, 02 Jan 2015 20:34:44 +0100
Subject: Symmetric encrypt many files (batch mode)
Message-ID: <54A6F2D4.6030803@gmail.com>

Hi All!

I want to symmetrically encrypt many hundreds of files under Linux, the 
files stored in many subdirectories. I am looking for a shell script 
which can do it for me. What is the simplest way to do it?

Best regards, Egon



From peter at digitalbrains.com  Fri Jan  2 21:35:12 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 02 Jan 2015 21:35:12 +0100
Subject: Craft public key so that private key equals given string (my
 password)?
In-Reply-To: <49993896d3ca57d0db8c46e48a7f6b05@sun>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <16170574.HaalSukMZ9@maxwell> <54A6A7A1.4030501@yahoo.de>
 <8147372.Ai0z4QYZv3@maxwell> <54A6C191.9000906@yahoo.de>
 <54A6C3DE.5020106@digitalbrains.com> <49993896d3ca57d0db8c46e48a7f6b05@sun>
Message-ID: <54A70100.1060401@digitalbrains.com>

On 02/01/15 21:29, sben1783 wrote:
> Maybe this isn't such a common use case, but I think for me it would perfectly
> make sense;)

No, I don't think this will become a feature :). However, if your OS is Linux or
something with the same "scripting power", you could simply have your script
create a tar file with the private key and the encrypted file, and a script that
unpacks the tar to a temp dir, imports the private key and decrypts the file.
All this could be done with a simple[1] bash script, tar, and some creativity.

HTH,

Peter.

[1] I think it would stay relatively simple, but you might have to think a bit
about it.

-- 
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 sben1783 at yahoo.de  Fri Jan  2 21:36:16 2015
From: sben1783 at yahoo.de (sben1783)
Date: Fri, 02 Jan 2015 21:36:16 +0100
Subject: Craft public key so that private key equals given string (my
 =?UTF-8?Q?password=29=3F?=
In-Reply-To: <54A6D05C.2040006@digitalbrains.com>
References: <65195a4af1ac8692eca3bf73342ab980@sun>
 <54A6C327.6010703@digitalbrains.com> <54A6D05C.2040006@digitalbrains.com>
Message-ID: <ba61e981041160208fc10b307c4c9df5@sun>

 On Fri, 02 Jan 2015 18:07:40 +0100, Peter Lebbing 
 <peter at digitalbrains.com> wrote:
> On 02/01/15 17:11, Peter Lebbing wrote:
>> it would increase the size of the public key by at least 13 
>> characters
>> (making it 50% longer) but it seems a good tradeoff to me.
>
> Minor nitpick: I meant 12 characters. I didn't want to think about it
> and simply
> used 'echo 12345678|base64|wc' but that included the newline (should 
> have
> specified -n to echo).
>
> And also, it's only an increase of 50% when you use a 160-bit curve; 
> it gets
> relatively less for larger curves.
>
> The reason I'm taking 64 bits as the size of the increase is that 
> PBKDF2
> recommends at least 64 bits of salting.

 Thank you Peter for your answers - the nitpick in this case doesn't 
 really change my conclusions, but I very much appreciate that kind of 
 precise and complete information. Even if only for the feeling of 
 "complete comprehension" (if that term makes sense in english).

 Ben



From dave.pawson at gmail.com  Fri Jan  2 22:37:56 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Fri, 2 Jan 2015 21:37:56 +0000
Subject: Symmetric encrypt many files (batch mode)
In-Reply-To: <54A6F2D4.6030803@gmail.com>
References: <54A6F2D4.6030803@gmail.com>
Message-ID: <CAEncD4emB7YHbDrF3vzfAZzPX4hgmt8cRihTvj0-n82Me33Erw@mail.gmail.com>

If you can get a list (comma, space separated) of the files, bash
would do it nicely?
  whatever you do, you'll need that?
then obtain the basename, $bn and use a for each on the list?

HTH

On 2 January 2015 at 19:34, Egon <cvimail81 at gmail.com> wrote:
> Hi All!
>
> I want to symmetrically encrypt many hundreds of files under Linux, the
> files stored in many subdirectories. I am looking for a shell script which
> can do it for me. What is the simplest way to do it?
>
> Best regards, Egon
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From sben1783 at yahoo.de  Fri Jan  2 23:41:21 2015
From: sben1783 at yahoo.de (Ben Staude)
Date: Fri, 02 Jan 2015 23:41:21 +0100
Subject: Symmetric encrypt many files (batch mode)
In-Reply-To: <54A6F2D4.6030803@gmail.com>
References: <54A6F2D4.6030803@gmail.com>
Message-ID: <54A71E91.3010802@yahoo.de>

Am 02.01.2015 um 20:34 schrieb Egon:
> Hi All!
>
> I want to symmetrically encrypt many hundreds of files under Linux, the
> files stored in many subdirectories. I am looking for a shell script
> which can do it for me. What is the simplest way to do it?

You might want to look at gpgdir: https://cipherdyne.org/gpgdir/

Ben


From n6ghost at yahoo.com  Fri Jan  2 23:50:05 2015
From: n6ghost at yahoo.com (Nex6|Bill)
Date: Fri, 2 Jan 2015 14:50:05 -0800
Subject: The praise of GnuPG @31C3 and why it is important (was: Guys
 please all see)
In-Reply-To: <54A3F823.3050603@josuttis.de>
References: <57C2F421-F088-44A5-8007-F4F6B36235F3@mykolab.com>
 <549F0B75.1070203@dougbarton.email> <1314470459.20141229011446@my_localhost>
 <54A0B5FE.9090603@enigmail.net> <748007345.20141229235114@my_localhost>
 <54A3F823.3050603@josuttis.de>
Message-ID: <446CA088-F138-4F69-B149-6D0EAC4D0C9E@yahoo.com>

watched the video, its amazing how much is broken and that GPG and OTR are not.


> On Dec 31, 2014, at 5:20 AM, Nicolai Josuttis <nico at josuttis.de> wrote:
> 
> OK,
> for those who didn't have time to see the talk at 31C3
> as a whole and therefore wondering why this is an important talk,
> let me point out and quote some content from
>>> http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video
> with the timepoints to be able to see/hear/double-check it yourself
> and some add-ons in [...] to understand the context.
> All quotes except the last by Jacob Appelbaum.
> 
> 26:33 :
> PPTP, ipsec, SSL, TLS, SSH are broken by NSA
> 
> 31:23 :
> we found that they [NSA] consistently break various different
> types of encryption
> 
> 33:40 :
> we want to show one PRISM record
> (the record contains:
>  "no decrypt available for this OTR encrypted message")
> 
> 34:22 :
> basically everyone that uses cryptography is broken
> except for two things: OTR and PGP (36:06)
> 
> 37:08 :
> the sad part is that not everyone is using it
> but the good news is that when you use it it appears to work
> (when you verified the fingerprint for example)
> 
> 37:38 :
> they [NSA] themselves find that they are blinded
> when you use properly implemented cryptography.
> 
> 37:46 :
> GnuPG and OTR are two things that actually stop the spies
> from spying on you with PRISM
> 
> 40:11 :
> if you use redphone and signal,
> if you use something like TOR and GnuPG
> with a properly sized key ...
> if you use OTR
> if you use jabber.ccc.de ...
> if you use encontered together
> you blind them
> 
> 42:41 :
> Werner Koch [GnuPG], ... could you stand up?
> ...
> Ian Goldberg [OTR], ...
> ...
> Christine Corbett [Signal],
> stand up and keep standing
> ...
> These people without even knowing it and without
> even trying they beat them!
> 
> 43:55 :
> Laura Poitras:
> Last night I screened my film Citizenfour here ...
> Somebody ask what an they do to support the work that Snowden has done
> and the Journalists.
> ...
> Everybody should fund the work that you guys do ...
> because literally, my work would not be possible without
> the work that you do.
> So, I would like it if everybody in this room when they leave here
> in the next week to reach out and fund these projects
> because without these projects the journalism
> that Glenn [Greenwald] and I and Jake have done
> would literally not be possible
> 
> 
> 
> Am 30.12.2014 um 00:51 schrieb MFPA:
>> I'm not entirely sure how this relates to the thread in which you
>> posted it.
> 
> --
> Nicolai M. Josuttis
> www.josuttis.de
> mailto:nico at enigmail.net
> PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5
> 
> 
> _______________________________________________
> 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: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150102/53517598/attachment.sig>

From pete at heypete.com  Sat Jan  3 04:59:21 2015
From: pete at heypete.com (Pete Stephenson)
Date: Fri, 2 Jan 2015 19:59:21 -0800
Subject: Thoughts on Keybase
In-Reply-To: <20141229224714.GA26328@eightyeight.xmission.com>
References: <548F2B16.1030703@sixdemonbag.org>
 <20141229224714.GA26328@eightyeight.xmission.com>
Message-ID: <CA+4dSw63f18AH7_ToRByxJmYGbsacjnRERDSjXsN7J5EZ9EEsA@mail.gmail.com>

On Mon, Dec 29, 2014 at 2:47 PM, Aaron Toponce <aaron.toponce at gmail.com> wrote:
> On Mon, Dec 15, 2014 at 01:40:22PM -0500, Robert J. Hansen wrote:
>> Keybase (https://keybase.io) is trying to solve the Web of Trust problem in
>> a new way.  They're currently in beta, but I was able to snag an invitation.
>> (I have no invites to give out, unfortunately.)
>
> FWIW, I have 3 invites. If you want to grab me off-list.
>
> https://keybase.io/atoponce

At present, I have 10 invites and would be happy to share them with
those who are interested. Please contact me off-list as well.

Cheers!
-Pete

-- 
Pete Stephenson


From melvincarvalho at gmail.com  Sat Jan  3 06:52:31 2015
From: melvincarvalho at gmail.com (Melvin Carvalho)
Date: Sat, 3 Jan 2015 06:52:31 +0100
Subject: Thoughts on Keybase
In-Reply-To: <548F2B16.1030703@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
Message-ID: <CAKaEYhLB1N=ZnEaFs5rfevuNd75zgKBu2WeVbQ+5t7y=y+DQSA@mail.gmail.com>

On 15 December 2014 at 19:40, Robert J. Hansen <rjh at sixdemonbag.org> wrote:

> Keybase (https://keybase.io) is trying to solve the Web of Trust problem
> in a new way.  They're currently in beta, but I was able to snag an
> invitation.  (I have no invites to give out, unfortunately.)  The following
> is just a write-up on how it works and what my impressions of it are.  You
> may find it interesting.  You may not.  :)
>
> =====
>
> 1.  SO WHAT'S THE PROBLEM WITH THE WoT?
>
> In a nutshell, "everything."  In my own experience, the Web of Trust goes
> pretty much completely unused.  There are several reasons for this.  The
> first is that trust is intransitive: if Alice trusts Bob and Bob trusts
> Charlene, it doesn't necessarily follow that Alice trusts Charlene.  (I
> like to imagine that Alice and Charlene were competing for Bob's affections
> once upon a time, and that Alice still wishes Bob wouldn't trust that
> hussy.[1])
>
> The dream of the Web of Trust is that trust chains would form and Alice
> would be able to trust Charlene's certificate as well as Doug's and
> Elaine's and all the way on through to Xavier, Yvonne and Zenobia.
> Unfortunately, it doesn't work that way.  If Alice trusts Bob, that means
> Alice has to trust all those people trusted by Bob... or even all those
> people trusted by all those people trusted by Bob... or even all those
> people trusted by all those people trusted by all those people trusted by
> Bob.  It gets impractical really fast.
>
> In twenty years of using PGP and GnuPG, I've relied on the Web of Trust a
> total of something like six times.  It was a neat idea, but as far as
> general rollout goes it's been a dismal failure.
>
>
> 2.  OKAY, SO YOU CONFIRM EVERYTHING VIA VOICE.
>
> Voice doesn't give us much confidence in identity.  Voice allows us to do
> out-of-band verification [2], but it doesn't let us confirm identity.  Most
> people think identity is something that gets proven by documents, but
> identity is actually a lot more nebulous than that.  I normally require two
> forms of government-issued identity documents before I'll sign a
> certificate, but I haven't seen two government-issued identity documents
> from my own mother.  That doesn't mean I think she's not my mother.  It
> means I've somewhere along the line done an identity verification that has
> nothing to do with documents.
>
>
> 3.  SO WHAT'S IDENTITY, ANYWAY?
>
> In a phrase, identity is the name we give to continuity of agency over
> time.  Knowing who's responsible for something right here, now, in this
> moment, is all well-and-good, but it's also kind of trivial: "the person
> standing there with a smoking gun is the one who's responsible for the body
> on the floor."  Doesn't tell you very much, really.  But knowing that
> person is also "the person who bought a bagel at a delicatessen yesterday"
> and "the person who's driven a Peugeot to work every day for the last three
> years" and "the person who for the last several years has lived at this
> address" all builds up to give us a sense of *what choices this person has
> made* (agency) and *over what time frame these choices have been made*
> (time).
>
> Once we have a concept of agency over time, that by itself is an
> identity.  A legal name specifies an agent, but not an identity. Identity
> requires history.  A track record.  A paper trail, as it were.
>

>From my experience, when you ask 10 people 'what is identity', you get 10
different answers.  A better question might be, "How do you name things
(e.g. people)". If different parties name things in a similar way there's
an order of magnitude more chance of growing the network.  Keybase has a
proprietary, centralized naming strategy largely incompatible with the
architecture of the web.  If that sounds like a criticism, it isnt.
Because almost everyone else does the same thing.  Hence identity systems
are balkanized.

Where I think keybase shines is with convenience and utility.  Such systems
have chances of organic growth.  But people tend to over estimate the
chances of making it to millions of users, which is what keybase possibly
needs to change the landscape.

We need a web of trust that's universal (the only way I know to do this is
to use URIs for naming), so that it can span many systems and grow the
network effect.


>
>
> 4.  SO WHAT'S THE RELEVANCE TO KEYBASE?
>
> Keybase has given up on the Web of Trust and on using official government
> records to prove who people are.  Instead, proofs are established by *what
> you've done* (agency) and *for how long you've been able to do it* (time).
>
> For instance, visit this website:
>
>         https://keybase.io/rjh
>

In awww this is a document, we like to put data inside documents.  Then you
can make statements about both things.  I may like Ricky Martin's home page
but may not like Ricky Martin.

Id suggest having an anchor inside such as #me or #this, then tie key value
pairs to it.  It turns out that anchors are very hard to grok on the web
for most people, though.

Using anchors also allows multiple data structures on the page.  One for
the user, one for the key, one for anything else you'd like to add.


>
> You'll see a list of several "what I can do"s.  Key 0xD6B98E10 has been
> used to sign a tweet containing an assertion of identity: "I am Rob Hansen,
> robertjhansen on Twitter."  Thereby, key 0xD6B98E10 has been bound to my
> Twitter social-media identity [3].  You can pull this tweet down from
> Twitter's own servers and verify the statement yourself; you don't have to
> take keybase's word for it.  (In fact, you probably *should* verify it for
> yourself.)
>
> Likewise, I've made similar statements of identity for my GitHub account
> and for a couple of web pages I run.  These disparate activities comprise a
> record of things I have done (agency) over a time period (time), which is
> ... identity.
>
>
> 5.  BUT YOU'RE NOT REALLY PROVING ANYTHING!
>
> It would be pretty foolish to think my legal name was Rob Hansen based
> solely on keybase, yes.  Keybase makes no assertion that someone is
> correctly representing their legal name.  But how many of us really care
> about that?  The more common use case seems to be that we want to know
> we're not being catfished [4].  I could be named Maurice Micklewhite and it
> wouldn't change the fact that I control that Twitter account, that GitHub
> account, or those webpages.  If the fraction of my identity that you care
> about maps well to that realm, then keybase is a pretty effective way to
> verify that fraction.
>
>
> 6.  FRACTIONS OF AN IDENTITY?
>
> Sure.  People on this list know a completely different me than my parents
> do.  You're the only one who knows the fullness of the choices you've made
> over the course of your life: you're the only one who knows who you truly
> are when the chips are down.  The rest of us only ever get to see a
> fraction of the true identity.
>
>
> 7.  SO DO YOU SEE KEYBASE MAKING A BIG DIFFERENCE?
>
> Given how miserable the WoT's adoption rate is, any improvement will be a
> big difference.  In its present form I don't see it as making a big
> difference to the world at large, though.  Right now keybase allows you to
> certify your Twitter, GitHub, Reddit, CoinBase, and Hacker News identities,
> as well as BitCoin addresses and any web pages you control.  For the geek
> cognoscenti that's great, but for the world at large it's not going to
> matter half a damn until and unless keybase gets either Google+ or Facebook
> on board.
>
>
> 8.  CLOSING THOUGHTS
>
> It's a cool idea and worth looking into.  https://keybase.io.  :)
>

yes, but as it's designed hard to get traction

very worth while noting the usability patterns tho


>
>
>
>
>
>
>
>
> [1] Americanism: "an impudent or immoral woman."  Generally considered
> rude, but not profane.
>
> [2] Kind-of sort-of: most phone traffic nowadays flows over the network,
> so it's actually in-band.
>
> [3] I rarely if ever use Twitter.  If you're a Twitter fiend feel free to
> follow me, but don't expect much.
>
> [4] Americanism: "identity deception."
>
> _______________________________________________
> 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/20150103/8533d20c/attachment-0001.html>

From htd+ml at fritha.org  Sat Jan  3 11:21:14 2015
From: htd+ml at fritha.org (Heinz Diehl)
Date: Sat, 3 Jan 2015 11:21:14 +0100
Subject: Symmetric encrypt many files (batch mode)
In-Reply-To: <54A6F2D4.6030803@gmail.com>
References: <54A6F2D4.6030803@gmail.com>
Message-ID: <20150103102114.GA2453@fritha.org>

On 02.01.2015, Egon wrote: 

> I want to symmetrically encrypt many hundreds of files under Linux, the
> files stored in many subdirectories.

Mabe you should consider using a LUKS/dmcrypt container/partition. It would make
things a lot easier and more fail-proof for you.



From juanmi.3000 at gmail.com  Sat Jan  3 14:19:52 2015
From: juanmi.3000 at gmail.com (Juan Miguel Navarro =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sat, 3 Jan 2015 14:19:52 +0100
Subject: HKPS fails on GPG 2.1
Message-ID: <20150103141952.00002b86.juanmi.3000@gmail.com>

Refreshing, receiving, sending and searching for keys using a hkps server fails with a "No keyserver available" error as seen in this debug:

  C:\Users\Juanmi>gpg -vvv --debug 1024 --recv-keys 88E2947F9BC6B3CF  
  gpg: reading options from 'C:/Users/Juanmi/AppData/Roaming/gnupg/gpg.conf'
  gpg: using character set 'CP850'
  gpg: enabled debug flags: extprog assuan
  gpg: DBG: chan_000000C8 <- # Home: C:/Users/Juanmi/AppData/Roaming/gnupg
  gpg: DBG: chan_000000C8 <- # Config: C:/Users/Juanmi/AppData/Roaming/gnupg/dirmn
  gr.conf
  gpg: DBG: chan_000000C8 <- OK Dirmngr 2.1.1 at your service
  gpg: DBG: chan_000000CC <- # Home: C:/Users/Juanmi/AppData/Roaming/gnupg
  gpg: DBG: chan_000000CC <- # Config: C:/Users/Juanmi/AppData/Roaming/gnupg/dirmn
  gr.conf
  gpg: DBG: chan_000000CC <- OK Dirmngr 2.1.1 at your service
  gpg: DBG: connection to the dirmngr established
  gpg: DBG: chan_000000CC -> KEYSERVER --clear hkps://hkps.pool.sks-keyservers.net

  gpg: DBG: chan_000000CC <- OK
  gpg: DBG: chan_000000CC -> KS_GET -- 0x88E2947F9BC6B3CF
  gpg: DBG: chan_000000CC <- ERR 167772346 No keyserver available <Dirmngr>
  gpg: keyserver receive failed: No keyserver available
  gpg: DBG: chan_000000CC -> BYE
  gpg: secmem usage: 0/32768 bytes in 0 blocks

It does not matter which hkps server is, I have tried hkps://keys.riseup.net as well. But if I use hkp, it works.

The certification file is added in the dirmngr.conf as below:

  hkp-cacert C:\Users\Juanmi\AppData\Roaming\gnupg\sks-keyservers.netCA.pem

And gpg.conf file is the one made at riseup.net but with 'default-key' changed to mine and the old 'keyserver-option ca-cert' option commented:
https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf

I'm wondering if it is because gnupg-curl and its libraries do not come with gnupg2.1.1 for Windows installer as it does with GPG4win installer, and I assume GPGTools for Mac.


From kristian.fiskerstrand at sumptuouscapital.com  Sat Jan  3 16:31:03 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sat, 03 Jan 2015 16:31:03 +0100
Subject: HKPS fails on GPG 2.1
In-Reply-To: <20150103141952.00002b86.juanmi.3000@gmail.com>
References: <20150103141952.00002b86.juanmi.3000@gmail.com>
Message-ID: <54A80B37.4050500@sumptuouscapital.com>

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

On 01/03/2015 02:19 PM, Juan Miguel Navarro Mart?nez wrote:
> Refreshing, receiving, sending and searching for keys using a hkps
>  server fails with a "No keyserver available" error as seen in this
>  debug:

Make sure dirmngr is built with gnutls support, use e.g.
$ dirmngr
..
OK Dirmngr 2.1.1 at your service

KEYSERVER --help
S # Known schemata:
S #   hkp
S #   hkps

^^ Make sure the scheme is there
S #   http
S #   finger
S #   kdns
S # (Use an URL for engine specific help.)
OK

> 
> It does not matter which hkps server is, I have tried 
> hkps://keys.riseup.net as well. But if I use hkp, it works.
> 
> The certification file is added in the dirmngr.conf as below:
> 
> hkp-cacert 
> C:\Users\Juanmi\AppData\Roaming\gnupg\sks-keyservers.netCA.pem
> 
> And gpg.conf file is the one made at riseup.net but with 
> 'default-key' changed to mine and the old 'keyserver-option 
> ca-cert' option commented: 
> https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf
>
>
>
> 
I'm wondering if it is because gnupg-curl and its libraries do not
> come with gnupg2.1.1 for Windows installer as it does with GPG4win
>  installer, and I assume GPGTools for Mac.
> 

Gnupg 2.1 does not use curl for these matters


- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Pr?venire melius est quam pr?veniri
It is better to precede than to be preceded
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUqAsxAAoJEPw7F94F4TagiPQQAKGW9VlXXW5oHFKKyLOgORw0
uTuUlelNQVsiQH/7z7bT2FF24UKuaPwlwfGiDH/NHyNPjKS4vlJjSL1z9MWnUhGl
Ds0MRqLCUCv2G+sf2w4xX21Z2O/yIjnUhvBRfTRsFav3pqmCM96HIvzFRqlOXQe0
CAnzfW0ALSa7AWu3YOHHOrS2OCovUWpKJS9RDZ0HlrUFPGEQU3Yvn49UaR7vG/Vs
AVfyX2ItDQVs1FH77bgNiczXOo/lGOv+fw4yKjyhE47K2kr63Ugl3NH5TpB0nZUZ
wRUuOYzGNglIaV1brosIxrg5hlnNL/a1alQAoB34GQUa5+YWF/K0nctZWaI6B2vb
yZihhyYYRaj7LpKMHLK2eqIf65xJLi3yjZKNc0tEtjvZqUtAgaBGRrbrFzGWDotK
uv1x77eO5A2ALq2Yitk7Lxu9pM21kG5i6ebdeAhaYTKyjHqkDSIKCrJyaFNPn3lE
PULeC+hPBtEX0QlmsTUO+EiP4s5HhGqPGoBrWEq+hsSoRoXynovFIdRmu/c7U5aG
wHq/0LDzqFgOrObkCvOfP1bO6EOkazwQjmUBttxnMBHDy9nqrfB/8iwy6M9Q/pGI
KM1znzaf3TsV3OnP4v9cBYN5A4SX9oSzjpsy7bQ1n513ENaOJdKJT3VF9Or0o1pZ
j2+tFtyBFYczknYIunWx
=Yfbm
-----END PGP SIGNATURE-----


From juanmi.3000 at gmail.com  Sat Jan  3 17:24:25 2015
From: juanmi.3000 at gmail.com (Juan Miguel Navarro =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sat, 3 Jan 2015 17:24:25 +0100
Subject: HKPS fails on GPG 2.1
In-Reply-To: <54A80B37.4050500@sumptuouscapital.com>
Message-ID: <20150103172425.00005bfd.juanmi.3000@gmail.com>

> Make sure dirmngr is built with gnutls support, use e.g.
> $ dirmngr
> ..
> OK Dirmngr 2.1.1 at your service
> 
> KEYSERVER --help
> S # Known schemata:
> S #   hkp
> S #   hkps
> 
> ^^ Make sure the scheme is there
> S #   http
> S #   finger
> S #   kdns
> S # (Use an URL for engine specific help.)
> OK

Hkps scheme is not there, how should I add it?


From kristian.fiskerstrand at sumptuouscapital.com  Sat Jan  3 18:55:36 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sat, 03 Jan 2015 18:55:36 +0100
Subject: HKPS fails on GPG 2.1
In-Reply-To: <20150103172425.00005bfd.juanmi.3000@gmail.com>
References: <20150103172425.00005bfd.juanmi.3000@gmail.com>
Message-ID: <54A82D18.5000602@sumptuouscapital.com>

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

On 01/03/2015 05:24 PM, Juan Miguel Navarro Mart?nez wrote:
>> Make sure dirmngr is built with gnutls support, use e.g. $
>> dirmngr .. OK Dirmngr 2.1.1 at your service
>> 
>> KEYSERVER --help S # Known schemata: S #   hkp S #   hkps
>> 
>> ^^ Make sure the scheme is there

> 
> Hkps scheme is not there, how should I add it?

If you compile it yourself Dirmngr has to be compiled with gnutls
support, so make sure you have all the applicable libraries and header
files available when compiling. Check the ./configure output for more
details.

If you didn't compile it yourself, file a bug with whomever provided
the binaries for inclusion of this feature similar to Arch Linux's [0]

References:
[0] https://bugs.archlinux.org/task/42739


- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Nomina stultorum scribuntur ubique locorum
Fools have the habit of writing their names everywhere
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUqC0XAAoJEPw7F94F4TagP+sP/3pHw2bdjhbg0RXNrnPGMysB
YNNYbmkXHFczfRz68u5OfFUFsc/CcYeKs7GW3/fDZ10q82V0h+zAI0kKMn16HoTR
YbCJ01eoOvQjIpRg1yiTFwW9ESuV+IStqoge8LVhYp1jfueBjqT0sISKGdBWxNg6
9inKjZIXXe0Gk3b2aeAnIGNjLrBMLm5/Dsa7vKZMFCfm3PWo4J6LMkWy/qtnGBDO
Kxf+A8fLWguvKQC08bWb/1hwHixyRuqWi/Q2O5ZgZ3bNi4AlAJFv8+fWL8MlFQkP
huD2LOxeOO8cd5le1IWBKNVIF8T6KqLAssd+jivhMTXfMCmy4cnkOUV55sqzqRd7
4Pl72GD57RH6BCzEoIO2kArsH94AZCI6Lrt3/ATD/hhScYJZi/ct6oZVPUYYGlD/
HSRdNLrzkAU95yq91cZjzIr+tHPZCNZYeRwHW2XdCQPfg5TMc7hvNKICU2w0o9rP
uDYrzJBnRFXD1B7RdjRg3wrMj3GjMed0K2nVkbg7NG++eVBtqEfqbAfxMKDU7caR
Y539W+X1lWueuWaFlbwLE+QfmCPgu5P4L23Uh3jL+bLo5BADEOckYC/gT1St/RVS
j+JRVaagibIA2EjXd3WZwEbAbqaurktpOv8eE0IIagub2sbbqXBs0kjM9svIJAZ+
hU/AhY7PaAQqZise/DHn
=5ETy
-----END PGP SIGNATURE-----


From juanmi.3000 at gmail.com  Sat Jan  3 23:39:09 2015
From: juanmi.3000 at gmail.com (Juan Miguel Navarro =?ISO-8859-1?Q?Mart=EDnez?=)
Date: Sat, 3 Jan 2015 23:39:09 +0100
Subject: HKPS fails on GPG 2.1
In-Reply-To: <54A82D18.5000602@sumptuouscapital.com>
Message-ID: <20150103233909.00002830.juanmi.3000@gmail.com>

I assume I must report it at https://bugs.g10code.com/gnupg/index as the installer and the sources to make the installer are hosted at ftp://ftp.gnupg.org/gcrypt/binary/ and signed by the developers.

Thanks for the help.


From wk at gnupg.org  Sun Jan  4 13:16:25 2015
From: wk at gnupg.org (Werner Koch)
Date: Sun, 04 Jan 2015 13:16:25 +0100
Subject: HKPS fails on GPG 2.1
In-Reply-To: <20150103233909.00002830.juanmi.3000@gmail.com> ("Juan Miguel
 Navarro =?utf-8?Q?Mart=C3=ADnez=22's?= message of "Sat, 3 Jan 2015 23:39:09
 +0100")
References: <20150103233909.00002830.juanmi.3000@gmail.com>
Message-ID: <87fvbq91wm.fsf@vigenere.g10code.de>

On Sat,  3 Jan 2015 23:39, juanmi.3000 at gmail.com said:
> I assume I must report it at https://bugs.g10code.com/gnupg/index as the installer and the sources to make the installer are hosted at ftp://ftp.gnupg.org/gcrypt/binary/ and signed by the developers.

The anouncement for 2.11 stated that it is an experimental installer and
thus you have to live with the missing features for now.  Building with
Gnutls on Windows is not easy thus there is no support currently.


Salam-Shalom,

   Werner

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



From giordano_lipari at yahoo.co.uk  Sun Jan  4 13:18:11 2015
From: giordano_lipari at yahoo.co.uk (Giordano Lipari)
Date: Sun, 4 Jan 2015 12:18:11 +0000 (UTC)
Subject: How to upgrade from 1.14.16 to 2.0.26 without duplicating, and
 related issues
Message-ID: <2053423086.4228001.1420373891979.JavaMail.yahoo@jws11117.mail.ir2.yahoo.com>

My machine runs with on a Ubuntu 14.04 LTS distribution. This comes with a default GnuPG 1.4.16 located mainly in /usr/bin as gpg. My competency in software engineering is limited. Following the indications in https://www.gnupg.org/download/index.html and common sense, I managed to install GnuPG 2.0.26 that, however, ended up in /usr/local/bin as pgp2. Therefore I now seem to have two GnuPG packages active on my computer. Admittedly my expectation was that the new version would have taken care of continuity from the old one.

[1] Are detailed how-to instructions on upgrading GnuPG that I missed? If so, could you please point me to them?[2] How do I actually upgrade GnuPG to the later version completely phasing out the old one?[3] After [2] is succesful, will a tool such Enigmail (but, in general, all applications counting on GnuPG) automatically recognise the latest version, seen that the new version is called gpg2 instead of gpg?
Thanks for helping me out!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150104/c54a8a90/attachment-0001.html>

From admin at shalmirane.com  Sun Jan  4 05:30:53 2015
From: admin at shalmirane.com (Ken Kundert)
Date: Sat, 3 Jan 2015 20:30:53 -0800
Subject: preventing gpg-agent from storing a symmetric encryption key
Message-ID: <20150104043053.GA14498@kundert.designers-guide.com>

All,
    Is there a way of preventing the agent from storing a symmetric encryption 
key?

I am writing a password generation program. The main password database will be 
encrypted with my private key and the passphrase to that key will be kept in 
gpg-agent so I don't have to retype this long passphrase every time I need one 
of my passwords.  But I worry that someone might gain access to my console while 
the agent has my passphrase, so would like to encrypt my passwords a second time 
with short password. The idea that most of the protection comes from the private 
key, but once that is unlocked anyone that gained access to the console would 
still have to know the short secondary password. Unfortunately, this plan is 
defeated if gpg-agent also saves the secondary password. So, I am looking for 
a command line option that I can use when doing the second level decrypt to 
prevent those short secondary passwords from being saved in the agent.

-Ken


From philip.jackson at nordnet.fr  Sun Jan  4 14:39:50 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sun, 04 Jan 2015 14:39:50 +0100
Subject: How to upgrade from 1.14.16 to 2.0.26 without duplicating, and
 related issues
In-Reply-To: <2053423086.4228001.1420373891979.JavaMail.yahoo@jws11117.mail.ir2.yahoo.com>
References: <2053423086.4228001.1420373891979.JavaMail.yahoo@jws11117.mail.ir2.yahoo.com>
Message-ID: <54A942A6.9010001@nordnet.fr>

On 04/01/15 13:18, Giordano Lipari wrote:
> My machine runs with on a Ubuntu 14.04 LTS distribution. This comes with a
> default GnuPG 1.4.16 located mainly in /usr/bin as gpg. My competency in
> software engineering is limited. Following the indications in
> https://www.gnupg.org/download/index.html and common sense, I managed to install
> GnuPG 2.0.26 that, however, ended up in /usr/local/bin as pgp2. Therefore I now
> seem to have two GnuPG packages active on my computer. Admittedly my expectation
> was that the new version would have taken care of continuity from the old one.
> 

> [3] After [2] is succesful, will a tool such Enigmail (but, in general, all
> applications counting on GnuPG) automatically recognise the latest version, seen
> that the new version is called gpg2 instead of gpg?

You don't need to worry greatly.  Gnupg 1.4.16 and gnupg 2.0.26 can co-exist on
the same machine with no problem.

I am in exactly the same case with Ubuntu.  I did the same as you and Enigmail
immediately picked up the 2.0.26 gpg2 which it uses with no problems.

I tend to use 1.4.16 from the command line.

However, the next step is to to move to gnupg 2.1 and that cannot co-exist with
2.0 versions.
Philip




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

From s.murthy at mykolab.com  Sun Jan  4 21:50:01 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Sun, 4 Jan 2015 20:50:01 +0000
Subject: How to upgrade from 1.14.16 to 2.0.26 without duplicating,
 and related issues
In-Reply-To: <54A942A6.9010001@nordnet.fr>
References: <2053423086.4228001.1420373891979.JavaMail.yahoo@jws11117.mail.ir2.yahoo.com>
 <54A942A6.9010001@nordnet.fr>
Message-ID: <1D05ACAE-2548-441B-93D0-704E8F2224A4@mykolab.com>

I had two versions on my Mac, worked fine.  I don?t have an Ubuntu machine,
but I seem to remember that `apt-get` is a package installer for Ubuntu,
e.g. `apt-get upgrade` to upgrade existing packages. ?

I don?t think using installing or using GnuPG requires any software engineering
competency. :)

Sandeep Murthy
s.murthy at mykolab.com





> On 4 Jan 2015, at 13:39, Philip Jackson <philip.jackson at nordnet.fr> wrote:
> 
> On 04/01/15 13:18, Giordano Lipari wrote:
>> My machine runs with on a Ubuntu 14.04 LTS distribution. This comes with a
>> default GnuPG 1.4.16 located mainly in /usr/bin as gpg. My competency in
>> software engineering is limited. Following the indications in
>> https://www.gnupg.org/download/index.html and common sense, I managed to install
>> GnuPG 2.0.26 that, however, ended up in /usr/local/bin as pgp2. Therefore I now
>> seem to have two GnuPG packages active on my computer. Admittedly my expectation
>> was that the new version would have taken care of continuity from the old one.
>> 
> 
>> [3] After [2] is succesful, will a tool such Enigmail (but, in general, all
>> applications counting on GnuPG) automatically recognise the latest version, seen
>> that the new version is called gpg2 instead of gpg?
> 
> You don't need to worry greatly.  Gnupg 1.4.16 and gnupg 2.0.26 can co-exist on
> the same machine with no problem.
> 
> I am in exactly the same case with Ubuntu.  I did the same as you and Enigmail
> immediately picked up the 2.0.26 gpg2 which it uses with no problems.
> 
> I tend to use 1.4.16 from the command line.
> 
> However, the next step is to to move to gnupg 2.1 and that cannot co-exist with
> 2.0 versions.
> Philip
> 
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



From a.rajagopal.81 at gmail.com  Sun Jan  4 14:28:13 2015
From: a.rajagopal.81 at gmail.com (Rajagopal Aravindan)
Date: Sun, 4 Jan 2015 18:58:13 +0530
Subject: lock-obj-pub.arm-none-linux-gnueabi.h
Message-ID: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>

All,

I was successfully able to compile libgpg-error-1.17 for my ARM with the
attached file.
The attached file was generated by following the instructions in the
README, which also suggested sharing it back with the group and hence this
mail.
PFB the details of my ARM compiler as well as my target platform.
Please let me know if any more details would be needed from my side, to
include this in your next release.

Thanks,
Rajagopal




*[root at FriendlyARM ~]# uname -aLinux FriendlyARM 3.5.0-FriendlyARM #1 SMP
PREEMPT Tue Dec 23 17:38:40 IST 2014 armv7l GNU/Linux*
*~/Downloads/libgpg-error-1.17$ arm-none-linux-gnueabi-gcc -v*






*Using built-in
specs.COLLECT_GCC=arm-none-linux-gnueabi-gccCOLLECT_LTO_WRAPPER=/home/rajagopal/Downloads/toolschain/4.5.1/bin/../libexec/gcc/arm-none-linux-gnueabi/4.5.1/lto-wrapperTarget:
arm-none-linux-gnueabiConfigured with:
/work/toolchain/build/src/gcc-4.5.1/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=arm-none-linux-gnueabi --prefix=/opt/FriendlyARM/toolschain/4.5.1
--with-sysroot=/opt/FriendlyARM/toolschain/4.5.1/arm-none-linux-gnueabi/sys-root
--enable-languages=c,c++ --disable-multilib --with-cpu=arm1176jzf-s
--with-tune=arm1176jzf-s --with-fpu=vfp --with-float=softfp
--with-pkgversion=ctng-1.8.1-FA --with-bugurl=http://www.arm9.net/
<http://www.arm9.net/> --disable-sjlj-exceptions --enable-__cxa_atexit
--disable-libmudflap --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-gmp=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--with-mpfr=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--with-ppl=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--with-cloog=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--with-mpc=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--with-libelf=/work/toolchain/build/arm-none-linux-gnueabi/build/static
--enable-threads=posix
--with-local-prefix=/opt/FriendlyARM/toolschain/4.5.1/arm-none-linux-gnueabi/sys-root
--disable-nls --enable-symvers=gnu --enable-c99 --enable-long-longThread
model: posixgcc version 4.5.1 (ctng-1.8.1-FA) *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150104/91d6d483/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lock-obj-pub.arm-none-linux-gnueabi.h
Type: text/x-chdr
Size: 508 bytes
Desc: not available
URL: </pipermail/attachments/20150104/91d6d483/attachment.h>

From 2014-667rhzu3dc-lists-groups at riseup.net  Mon Jan  5 03:44:00 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Mon, 5 Jan 2015 02:44:00 +0000
Subject: Thoughts on Keybase
In-Reply-To: <548F2B16.1030703@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
Message-ID: <1291169981.20150105024400@my_localhost>

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



On Monday 15 December 2014 at 6:40:22 PM, in
<mid:548F2B16.1030703 at sixdemonbag.org>, Robert J. Hansen wrote:


> knowing  that person
> is also "the person who bought a bagel at a
> delicatessen  yesterday" and "the person who's driven a
> Peugeot to work every day for the last three years" and
> "the person who for the last several years has lived at
> this address" all builds up to give us a sense of *what
> choices this person has made* (agency) and *over what
> time frame these choices have been made* (time).

To me, that sounds far too invasive to be comfortable.



> Once we have a concept of agency over time, that by
> itself is an  identity.  A legal name specifies an
> agent, but not an identity.  Identity requires history.
> A track record.  A paper trail, as it were.

I like that as a working desciption of Identity. But the track record
does not need to be as all-encompassing as you describe above. I have
a natural pre-disposition to not disclose "Fractions of an identity"
that are not relevant to the specific identity enquiry.



> For instance, visit this website:

>         https://keybase.io/rjh

> You'll see a list of several "what I can do"s.  Key
> 0xD6B98E10 has been used to sign a tweet containing an
> assertion of identity: "I am Rob  Hansen, robertjhansen
> on Twitter."  Thereby, key 0xD6B98E10 has been  bound
> to my Twitter social-media identity [3].  You can pull
> this tweet down from Twitter's own servers and verify
> the statement yourself; you don't have to take
> keybase's word for it.  (In fact, you probably
> *should* verify it for yourself.)

> Likewise, I've made similar statements of identity for
> my GitHub account and for a couple of web pages I run.
> These disparate activities  comprise a record of things
> I have done (agency) over a time period  (time), which
> is ... identity.

I know people who tend towards presenting a single blended identity,
and people who compartmentalise the facets of their life as separate
"fractions". I guess keybase is not a good "fit" for the latter group.




- --
Best regards

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

Coffee doesn't need a menu, it needs a cup.
-----BEGIN PGP SIGNATURE-----

iQF7BAEBCgBmBQJUqfqTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwfrEH+JzGEMxJROyLzgVNpmnUuQY0
n4sP5mIj8/54P2FdjE+R06GPNc2QHPjT2OsShWSwE4nn5+T5wLqMQpoCw72aMs8m
29DFWaQd5UiB7ZFrOskeTZf8lleBj1UWz5OmLloVc/dqD8l+e0ni15VYNcz16Dsv
P2Aia35mt6ZRdpI1Wca0/412EWxmt8MAYe2RPAFegRNzYv+h6xqjCHnhD678veo9
MV0jXMnEyPuL3Ow6NollI7ekIpqxporjLsB8jlHzrVq6FIVGweA0tUlx9O93Xtmg
Udra8zan4XhRARdH+j9iOW9xXc/O1NvXQnmiaTXNiu4amFH+ho/RvHYljMJUQIi+
BAEWCgBmBQJUqfqcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5w
Z3AuZmlmdGhob3JzZW1hbi5uZXQzM0FDRUQ0RUU5MTM0RUVCREU2QTg1MDYxNzEy
QkM0NjFBRjc3OEU0AAoJEBcSvEYa93jkmBMBAHJsCeg4n0Ohl6EanWG8KMtizHM1
lOUqlzqEz/dw0iPAAQB16t2CYfFSRqDMx+avRGvTsy3TyFZGJOfUd2+JF3ueCw==
=tRp4
-----END PGP SIGNATURE-----



From rjh at sixdemonbag.org  Mon Jan  5 04:22:19 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 4 Jan 2015 22:22:19 -0500
Subject: Thoughts on Keybase
In-Reply-To: <1291169981.20150105024400@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
Message-ID: <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>

> To me, that sounds far too invasive to be comfortable.

In context, the person had just committed a murder (see my remark about standing over a dead body holding a smoking pistol).

I?m just fine with invasive identity establishment for murder suspects.  :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150104/2e2346f6/attachment-0001.bin>

From ryan at b19.org  Mon Jan  5 06:33:03 2015
From: ryan at b19.org (Ryan Sawhill)
Date: Mon, 5 Jan 2015 00:33:03 -0500
Subject: Symmetric encrypt many files (batch mode)
In-Reply-To: <54A6F2D4.6030803@gmail.com>
References: <54A6F2D4.6030803@gmail.com>
Message-ID: <CANy18xDZe8+a6vx9ZiQTV1ig4W1SQqR3AjCbpfkm9u+8DwtoxQ@mail.gmail.com>

Assuming you want to encrypt every single file in a directory tree, your
best bet would be to use the find command. Something like this:

find /SomeDirectory -type f -exec gpg2 --batch --cipher-algo AES256
--force-mdc --symmetric --passphrase-file /FILE -o {}.gpg {} \;

The above will save each file with the same name + an extension of ".gpg".
The cipher-algo & force-mdc options aren't required of course. Just a
personal recommendation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150105/16d0a1a2/attachment.html>

From dougb at dougbarton.email  Mon Jan  5 09:08:35 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Mon, 05 Jan 2015 00:08:35 -0800
Subject: preventing gpg-agent from storing a symmetric encryption key
In-Reply-To: <20150104043053.GA14498@kundert.designers-guide.com>
References: <20150104043053.GA14498@kundert.designers-guide.com>
Message-ID: <54AA4683.40308@dougbarton.email>

FYI, what you want to do doesn't make sense. :)

You should read the man page, and learn about inactivity timeouts for 
gpg-agent. Also, you can wipe the agent altogether quite easily.

Your concern about people gaining access to the console is well founded, 
but there are better solutions already available to you.

Doug


From admin at shalmirane.com  Mon Jan  5 10:51:55 2015
From: admin at shalmirane.com (Ken Kundert)
Date: Mon, 5 Jan 2015 01:51:55 -0800
Subject: preventing gpg-agent from storing a symmetric encryption key
In-Reply-To: <54AA4683.40308@dougbarton.email>
References: <20150104043053.GA14498@kundert.designers-guide.com>
 <54AA4683.40308@dougbarton.email>
Message-ID: <20150105095155.GA2530@kundert.designers-guide.com>

Hi Doug.
    I am aware of the ability to set inactivity timeouts and to clear the entire 
agent.  And I still believe I can use this feature.

What I have noticed about myself is that I will walk away from my keyboard 
without locking the screen. I just forget to do it. I have been trying to change 
this behavior for the last few years, and yet I still do it. Now, the screen 
locks itself after 10 to 15 minutes, so that is my window of vulnerability.  
Unless I set the gpg-agent inactivity time-out to no more than a minute or two, 
it is not going to help this situation much.  However, I cannot bear to set the 
time-out that short because it would effectively be like turning off the agent 
altogether. That is problematic for me because I use long passphrases.

So my thought is to double encrypt my secrets, once with my private key that is 
protected with a long XKCD style passphrase and once with a symmetric cipher 
with a relatively short password, and keep the passphrase in gpg-agent but not 
the password. Use of the private key with the long passphrase protects me in 
case someone steals both the private key and the cipertext and mounts an 
automated attack.  The short passwords are there to protect me if someone sits 
down at my keyboard while I am at lunch.  Here the chance of an automated attack 
is much lower, and so a short easy to type password should be sufficient in most 
cases.

Anyway, that is what I would like to do. I think I can do it with the original 
GPG, but I was hoping to use GPG2.

As an aside, after switching to longer XKCD style passphrase a few years ago 
I came to realize that most security programs inadvertently discourage the use 
of long passphrases. Probably 99% of the time that I type a passphrase I am 
alone, so obscuring the passphrase provides little value. But the longer 
passphrase you have the more chance you are going to have a typo, and with the 
passphrase obscured you cannot see it or correct it. Thus in my experience, 
obscuring the passphrase largely limits me to using about 4 words, anything 
longer than that and I find myself in seeming endless passphrase entry loops.  
Pinentry suffers from this problem. I would like to suggest that a button be 
added to pinentry that un-obscures the passphrase.

So those are my two suggestions:
1. reactivate the --no-use-agent command line option in gpg2
2. add an 'unobscure passphrase' button to pinentry.

I love gpg, and I use it heavily. Thank you to all that contribute to it.

-Ken


On Mon, Jan 05, 2015 at 12:08:35AM -0800, Doug Barton wrote:
> FYI, what you want to do doesn't make sense. :)
> 
> You should read the man page, and learn about inactivity timeouts for
> gpg-agent. Also, you can wipe the agent altogether quite easily.
> 
> Your concern about people gaining access to the console is well founded, but
> there are better solutions already available to you.
> 
> Doug


From s.murthy at mykolab.com  Mon Jan  5 16:54:45 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Mon, 5 Jan 2015 15:54:45 +0000
Subject: Key generation, subkeys and improved documentation
Message-ID: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>

Hi

I have a couple of questions about key generation, subkeys and the documentation
on gnupg.org.

(FYI I have GnuPG/MacGPG (v. 2.0.26) on my Mac.)

1. I just tried to generate an RSA keypair using `gpg` on the command line, and it
asks me to choose a key length between 1024 and 8192.  Here is the relevant output
from my terminal session:

    RSA keys may be between 1024 and 8192 bits long.
    What keysize do you want? (2048) 8192
    Requested keysize is 8192 bits

I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain
utility from the GPGTools suite which installs the GnuPG/MacGPG) doesnt?t allow
key sizes bigger than 4096.  In any case, choosing 8192 fails with `gpg`:

    gpg: keysize invalid; using 4096 bits

Shouldn?t this be changed to ensure that 4096 is the limit, or is it possible to have
an 8192 length RSA key or this limited by the current capabilities of the random
number generator?

2. The key generation dialogue for v. 2.0.26 (started by `gpg ?gen-key`) shows
the following list of options for keys:

    Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)

As a user this is confusing to see, for example, RSA and RSA - of course I worked
out afterwards that this was going to generate two keypairs one for signatures (S),
the other for encryption (E), but at the moment it?s just confusing, even if have to
generate new keys again.  There is also no explanation that the public key itself is
a pair of keys, one which actually makes the signatures using the private key, and
the other (subkey) which others use to encrypt messages to you.

Also these subway codes S, E, and also C, A are not explained at all - I had to
lookup the source code (?keyedit.c` in the `/g10/ subfolder of the source folder) to
guess at what they mean.

For example, here is the information provided by `gpg` for my keybase.io public key:

pub  4096R/9EAB92B4  created: 2014-12-30  expires: never       usage: SCEA
                     trust: ultimate      validity: ultimate
sub  2048R/238026C5  created: 2014-12-30  expires: 2022-12-28  usage: S
sub  2048R/66C9185A  created: 2014-12-30  expires: 2022-12-28  usage: E
[ultimate] (1). keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>

There should be an explanation surely of what S C E A mean: S (signatures),
E (encryption), C (creating a certificate) and A (authentication?).

3. At the moment the documentation on gnupg.org - both the manuals and the
privacy handbook - are out of date for v. 2.x+), e.g. the privacy handbook
https://www.gnupg.org/gph/en/manual/c14.html showing the possible keypair
choices as

   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (4) ElGamal (sign and encrypt)

which is obviously different from what the current one version allows.  Perhaps
there should be a much better explanation of subways and the codes S, C, E, A,
because I don?t think it?s there right now.  Since the handbook is aimed at first
time users it seems these updates should be (and could be) made very quickly.

I use GnuPG but I would also like to contribute.  Would it be possible to clone
the repo and make a pull request or something like that?

Sandeep Murthy
s.murthy at mykolab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150105/4248a543/attachment.sig>

From philip.jackson at nordnet.fr  Mon Jan  5 21:52:36 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Mon, 05 Jan 2015 21:52:36 +0100
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
Message-ID: <54AAF994.1060209@nordnet.fr>

On 05/01/15 16:54, Sandeep Murthy wrote:
> I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain
> utility from the GPGTools suite which installs the GnuPG/MacGPG) doesnt?t allow
> key sizes bigger than 4096.  In any case, choosing 8192 fails with `gpg`:
> 
>     gpg: keysize invalid; using 4096 bits

It is possible to create keys larger than 4096.  When I was on Windows, there
was a discussion on the gpg4win forum which gave steps to create an 8192 key
pair.  I followed the procedure out of curiosity and I do now have an 8192 key
which I've never used (for various reasons).
Philip

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

From 2014-667rhzu3dc-lists-groups at riseup.net  Mon Jan  5 23:49:54 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Mon, 5 Jan 2015 22:49:54 +0000
Subject: Thoughts on Keybase
In-Reply-To: <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
Message-ID: <1709158100.20150105224954@my_localhost>

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

Hi


On Monday 5 January 2015 at 3:22:19 AM, in
<mid:D14D23FF-4273-4FBE-999A-3527A03DD8C8 at sixdemonbag.org>, Robert J.
Hansen wrote:


> In context, the person had just committed a murder (see
> my remark about standing over a dead body holding a
> smoking pistol).

We only *suspect* that: we saw him holding a smoking gun but did not
actually see him fire it. Maybe a second earlier the person he was
trying to disarm fled or hid, or maybe they are the body on the
ground. Your scenario gives facts about yesterday and the last three
or more years, but provides only supposition about the events that
just occurred before we saw the smoking gun.



> I?m just fine with invasive identity establishment for
> murder suspects.  :)

I'm not fine with invasive anything whilst they are *only* a suspect.
And once you have proven guilt or innocence it matters not a jot who
they are.


- --
Best regards

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

The greater the power, the more dangerous the abuse.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUqxUlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwLrQH/1RxX5d8tCa5LIOqah0ntPb5
BlzAEmZSKB3n/fRM7WhgExZMVnQXOcawgmphTF5DXToWHRYtCI5eYvviR00ZaKF4
P+/ls8xiUp3+BRehpEZOBE09tXrGjHFPwQF9uyzki8Rmx2sI94zcUWEiH46YqoxG
sz6hleWugT6nMMFaliVW/t0tSnuQb4VA9OdRGAkIFCI4BfNiXUp+Smk4Yx5BKacm
Or92Q4SPOrqCnJ1RhA5SMQTM5VIVcf30EAZvLg9SDl4wVWp60K0037VEl0050Q94
VohmU/K5NYZmV/SqFO+vRoALY1OaZCc5GmGFwgqkmsHtII53P5yRL0ysK+RyFG+I
vgQBFgoAZgUCVKsVMV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45Ci4AQDbYgEngyEi9AP6D6hDsVvc8OMh
zeprVAwJPOazlcpJrQEAzUqsEHi7leuxqRv1hlfPl3SX/XDyNJIUCj7mn8qzcAk=
=leqr
-----END PGP SIGNATURE-----



From alexander.buchner at posteo.de  Mon Jan  5 23:07:27 2015
From: alexander.buchner at posteo.de (Alexander Buchner)
Date: Mon, 05 Jan 2015 23:07:27 +0100
Subject: Untrusted certificate for https://wiki.gnupg.org/
Message-ID: <54AB0B1F.90303@posteo.de>

In https://www.gnupg.org/blog/index.html there is link to
https://wiki.gnupg.org/ which is kind of broken, because the site's
certificate is untrusted due to an incomplete certificate chain.

Are you aware of that?

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

From n6ghost at yahoo.com  Mon Jan  5 23:46:54 2015
From: n6ghost at yahoo.com (Nex6|Bill)
Date: Mon, 5 Jan 2015 14:46:54 -0800
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
Message-ID: <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>


> On Jan 5, 2015, at 7:54 AM, Sandeep Murthy <s.murthy at mykolab.com> wrote:
> 
> Hi
> 
> I have a couple of questions about key generation, subkeys and the documentation
> on gnupg.org.
> 
> (FYI I have GnuPG/MacGPG (v. 2.0.26) on my Mac.)
> 
> 1. I just tried to generate an RSA keypair using `gpg` on the command line, and it
> asks me to choose a key length between 1024 and 8192.  Here is the relevant output
> from my terminal session:
> 
>    RSA keys may be between 1024 and 8192 bits long.
>    What keysize do you want? (2048) 8192
>    Requested keysize is 8192 bits
> 
> I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain
> utility from the GPGTools suite which installs the GnuPG/MacGPG) doesnt?t allow
> key sizes bigger than 4096.  In any case, choosing 8192 fails with `gpg`:
> 
>    gpg: keysize invalid; using 4096 bits
> 
> Shouldn?t this be changed to ensure that 4096 is the limit, or is it possible to have
> an 8192 length RSA key or this limited by the current capabilities of the random
> number generator?
> 
> 2. The key generation dialogue for v. 2.0.26 (started by `gpg ?gen-key`) shows
> the following list of options for keys:
> 
>    Please select what kind of key you want:
>   (1) RSA and RSA (default)
>   (2) DSA and Elgamal
>   (3) DSA (sign only)
>   (4) RSA (sign only)
> 
> As a user this is confusing to see, for example, RSA and RSA - of course I worked
> out afterwards that this was going to generate two keypairs one for signatures (S),
> the other for encryption (E), but at the moment it?s just confusing, even if have to
> generate new keys again.  There is also no explanation that the public key itself is
> a pair of keys, one which actually makes the signatures using the private key, and
> the other (subkey) which others use to encrypt messages to you.
> 
> Also these subway codes S, E, and also C, A are not explained at all - I had to
> lookup the source code (?keyedit.c` in the `/g10/ subfolder of the source folder) to
> guess at what they mean.
> 
> For example, here is the information provided by `gpg` for my keybase.io public key:
> 
> pub  4096R/9EAB92B4  created: 2014-12-30  expires: never       usage: SCEA
>                     trust: ultimate      validity: ultimate
> sub  2048R/238026C5  created: 2014-12-30  expires: 2022-12-28  usage: S
> sub  2048R/66C9185A  created: 2014-12-30  expires: 2022-12-28  usage: E
> [ultimate] (1). keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>
> 
> There should be an explanation surely of what S C E A mean: S (signatures),
> E (encryption), C (creating a certificate) and A (authentication?).
> 
> 3. At the moment the documentation on gnupg.org - both the manuals and the
> privacy handbook - are out of date for v. 2.x+), e.g. the privacy handbook
> https://www.gnupg.org/gph/en/manual/c14.html showing the possible keypair
> choices as
> 
>   (1) DSA and ElGamal (default)
>   (2) DSA (sign only)
>   (4) ElGamal (sign and encrypt)
> 
> which is obviously different from what the current one version allows.  Perhaps
> there should be a much better explanation of subways and the codes S, C, E, A,
> because I don?t think it?s there right now.  Since the handbook is aimed at first
> time users it seems these updates should be (and could be) made very quickly.
> 
> I use GnuPG but I would also like to contribute.  Would it be possible to clone
> the repo and make a pull request or something like that?
> 
> Sandeep Murthy
> s.murthy at mykolab.com <mailto:s.murthy at mykolab.com>


I believe the recommendation from the GPG folks is a 2048 key pair. But I have seen some of the more paranoid privacy folks doing 4096 key pairs.

Other than that most of the defaults are good.

Nex6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150105/99f31fde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150105/99f31fde/attachment.sig>

From rjh at sixdemonbag.org  Tue Jan  6 02:22:47 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 05 Jan 2015 20:22:47 -0500
Subject: Thoughts on Keybase
In-Reply-To: <1709158100.20150105224954@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost>
Message-ID: <54AB38E7.8070804@sixdemonbag.org>

> We only *suspect* that: we saw him holding a smoking gun but did not 
> actually see him fire it.

Yes, which is plenty sufficient to soothe my conscience about invasive
measures.  If there's a homicide, ought it go uninvestigated and the
shooter undiscovered just because we're concerned we might be invading
the privacy of a possibly-innocent person?  I would suspect I was
grossly misunderstanding you were it not for what you said below:

> I'm not fine with invasive anything whilst they are *only* a
> suspect. And once you have proven guilt or innocence it matters not a
> jot who they are.

"Until you prove guilt I won't approve of any serious investigation into
who did it or how.  And if somehow you prove guilt anyway then you don't
need to ask these questions any more, so I still won't approve."

Okay.  Thanks.  I'm really glad you're in the minority: if I were to
wind up murdered on a city street, I'd really hope the police would care
enough to find out who did it and how it was done and why -- even if
those questions might offend people's sensibilities.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150105/bab82153/attachment.bin>

From s.murthy at mykolab.com  Tue Jan  6 02:58:24 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Tue, 6 Jan 2015 01:58:24 +0000
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
 <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
Message-ID: <3A278BD5-0099-4F04-B188-89DCD6F44E71@mykolab.com>

I think 4096 is enough for me, I don?t want to key of length 8192.

I was just suggesting that the key generation dialogue in gpg could
be improved.

Sandeep Murthy
s.murthy at mykolab.com

> On 5 Jan 2015, at 22:46, Nex6|Bill <n6ghost at yahoo.com> wrote:
> 
>> 
>> On Jan 5, 2015, at 7:54 AM, Sandeep Murthy <s.murthy at mykolab.com> wrote:
>> 
>> Hi
>> 
>> I have a couple of questions about key generation, subkeys and the documentation
>> on gnupg.org.
>> 
>> (FYI I have GnuPG/MacGPG (v. 2.0.26) on my Mac.)
>> 
>> 1. I just tried to generate an RSA keypair using `gpg` on the command line, and it
>> asks me to choose a key length between 1024 and 8192.  Here is the relevant output
>> from my terminal session:
>> 
>>    RSA keys may be between 1024 and 8192 bits long.
>>    What keysize do you want? (2048) 8192
>>    Requested keysize is 8192 bits
>> 
>> I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain
>> utility from the GPGTools suite which installs the GnuPG/MacGPG) doesnt?t allow
>> key sizes bigger than 4096.  In any case, choosing 8192 fails with `gpg`:
>> 
>>    gpg: keysize invalid; using 4096 bits
>> 
>> Shouldn?t this be changed to ensure that 4096 is the limit, or is it possible to have
>> an 8192 length RSA key or this limited by the current capabilities of the random
>> number generator?
>> 
>> 2. The key generation dialogue for v. 2.0.26 (started by `gpg ?gen-key`) shows
>> the following list of options for keys:
>> 
>>    Please select what kind of key you want:
>>   (1) RSA and RSA (default)
>>   (2) DSA and Elgamal
>>   (3) DSA (sign only)
>>   (4) RSA (sign only)
>> 
>> As a user this is confusing to see, for example, RSA and RSA - of course I worked
>> out afterwards that this was going to generate two keypairs one for signatures (S),
>> the other for encryption (E), but at the moment it?s just confusing, even if have to
>> generate new keys again.  There is also no explanation that the public key itself is
>> a pair of keys, one which actually makes the signatures using the private key, and
>> the other (subkey) which others use to encrypt messages to you.
>> 
>> Also these subway codes S, E, and also C, A are not explained at all - I had to
>> lookup the source code (?keyedit.c` in the `/g10/ subfolder of the source folder) to
>> guess at what they mean.
>> 
>> For example, here is the information provided by `gpg` for my keybase.io public key:
>> 
>> pub  4096R/9EAB92B4  created: 2014-12-30  expires: never       usage: SCEA
>>                     trust: ultimate      validity: ultimate
>> sub  2048R/238026C5  created: 2014-12-30  expires: 2022-12-28  usage: S
>> sub  2048R/66C9185A  created: 2014-12-30  expires: 2022-12-28  usage: E
>> [ultimate] (1). keybase.io/sandeepmurthy <sandeepmurthy at keybase.io>
>> 
>> There should be an explanation surely of what S C E A mean: S (signatures),
>> E (encryption), C (creating a certificate) and A (authentication?).
>> 
>> 3. At the moment the documentation on gnupg.org - both the manuals and the
>> privacy handbook - are out of date for v. 2.x+), e.g. the privacy handbook
>> https://www.gnupg.org/gph/en/manual/c14.html showing the possible keypair
>> choices as
>> 
>>   (1) DSA and ElGamal (default)
>>   (2) DSA (sign only)
>>   (4) ElGamal (sign and encrypt)
>> 
>> which is obviously different from what the current one version allows.  Perhaps
>> there should be a much better explanation of subways and the codes S, C, E, A,
>> because I don?t think it?s there right now.  Since the handbook is aimed at first
>> time users it seems these updates should be (and could be) made very quickly.
>> 
>> I use GnuPG but I would also like to contribute.  Would it be possible to clone
>> the repo and make a pull request or something like that?
>> 
>> Sandeep Murthy
>> s.murthy at mykolab.com
> 
> 
> I believe the recommendation from the GPG folks is a 2048 key pair. But I have seen some of the more paranoid privacy folks doing 4096 key pairs.
> 
> Other than that most of the defaults are good.
> 
> Nex6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150106/a9a1631f/attachment-0001.sig>

From wk at gnupg.org  Tue Jan  6 10:23:19 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Jan 2015 10:23:19 +0100
Subject: Untrusted certificate for https://wiki.gnupg.org/
In-Reply-To: <54AB0B1F.90303@posteo.de> (Alexander Buchner's message of "Mon, 
 05 Jan 2015 23:07:27 +0100")
References: <54AB0B1F.90303@posteo.de>
Message-ID: <87sifo460o.fsf@vigenere.g10code.de>

On Mon,  5 Jan 2015 23:07, alexander.buchner at posteo.de said:
> In https://www.gnupg.org/blog/index.html there is link to
> https://wiki.gnupg.org/ which is kind of broken, because the site's
> certificate is untrusted due to an incomplete certificate chain.

You merely need to install the right root certificate.  Or add an
exception.  Unfortunately is is hard to get root certificates installed
by default into browsers unless you are a TLA.


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Tue Jan  6 11:14:31 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Jan 2015 11:14:31 +0100
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com> (Sandeep
 Murthy's message of "Mon, 5 Jan 2015 15:54:45 +0000")
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
Message-ID: <87y4pg2p2w.fsf@vigenere.g10code.de>

On Mon,  5 Jan 2015 16:54, s.murthy at mykolab.com said:

> I thought the maximum was 4096?  For example, GPGKeychain (the GUI keychain

Yes, but the gpgtools folks modified GnuPG to allow for 8k.


Salam-Shalom,

   Werner

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



From alexander.buchner at posteo.de  Tue Jan  6 12:18:08 2015
From: alexander.buchner at posteo.de (Alexander Buchner)
Date: Tue, 06 Jan 2015 12:18:08 +0100
Subject: Untrusted certificate for https://wiki.gnupg.org/
In-Reply-To: <87sifo460o.fsf@vigenere.g10code.de>
References: <54AB0B1F.90303@posteo.de> <87sifo460o.fsf@vigenere.g10code.de>
Message-ID: <54ABC470.5010202@posteo.de>

On 06.01.2015 10:23, Werner Koch wrote:
> You merely need to install the right root certificate.  Or add an
> exception.  Unfortunately is is hard to get root certificates installed
> by default into browsers unless you are a TLA.

We both know that almost nobody installs additional certificates.
So why don't just get a proper certificate like for gnupg.org with a
complete trust path?

Btw: Also the TLS configuration of wiki.gnupg.org is not as good as the
one for gnupg.org (e.g. support for TLS 1.2), see
https://www.ssllabs.com/ssltest/analyze.html?d=wiki.gnupg.org

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

From gnupgpacker at on.yourweb.de  Tue Jan  6 12:22:35 2015
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Tue, 6 Jan 2015 12:22:35 +0100
Subject: Updating public key problem
Message-ID: <000101d029a3$12211370$36633a50$@on.yourweb.de>

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

Hello,
did anyone get a response from encrypt.to?

Btw and sorry for this question:
Seems https://encrypt.to to be a reliable service regarding data security?
Transmission of newly created messages are transferred from browser window
to encrypt.to-server by ssl, but is its content (content of browser window)
encrypted too?

Regards, Chris

> -----Original-Message-----
> and that's why, in my opinion, why
> the sending an encrypted message doesn't work by the free service like -
> https://encrypt.to/linuxdebian at zoho.com Before the expirationd date of
> those 2 keys, the encrypt.to service worked.
> [...]
> Does encrypt.to cope with
> 4096-bit keys and SHA256 binding signatures? What size was your old
> encryption subkey?

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

iF4EAREIAAYFAlSrxYIACgkQI4+xq0ppLEku1QEAnvacvMPB/QSDfqBfthKcxoxR
YgiW6XDIF+0P2bA8TscBAOnCIFSxaqPwbHTswWGH91j6wNasAMOoQDf4c9xTRSFr
=btdK
-----END PGP SIGNATURE-----


From wk at gnupg.org  Tue Jan  6 14:45:49 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Jan 2015 14:45:49 +0100
Subject: Untrusted certificate for https://wiki.gnupg.org/
In-Reply-To: <54ABC470.5010202@posteo.de> (Alexander Buchner's message of
 "Tue, 06 Jan 2015 12:18:08 +0100")
References: <54AB0B1F.90303@posteo.de> <87sifo460o.fsf@vigenere.g10code.de>
 <54ABC470.5010202@posteo.de>
Message-ID: <87mw5w2faq.fsf@vigenere.g10code.de>

On Tue,  6 Jan 2015 12:18, alexander.buchner at posteo.de said:

> We both know that almost nobody installs additional certificates.
> So why don't just get a proper certificate like for gnupg.org with a
> complete trust path?

Well, wiki.gnupg.org is run by the folks from Intevation and they use
there own infrastruture.  They wanted a wiki and thus I setup the DNS
for it.

> Btw: Also the TLS configuration of wiki.gnupg.org is not as good as the
> one for gnupg.org (e.g. support for TLS 1.2), see
> https://www.ssllabs.com/ssltest/analyze.html?d=wiki.gnupg.org

Well, maybe they can give some insights.


Salam-Shalom,

   Werner

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



From mwood at IUPUI.Edu  Tue Jan  6 15:14:20 2015
From: mwood at IUPUI.Edu (Mark H. Wood)
Date: Tue, 6 Jan 2015 09:14:20 -0500
Subject: Thoughts on Keybase
In-Reply-To: <54AB38E7.8070804@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost>
 <54AB38E7.8070804@sixdemonbag.org>
Message-ID: <20150106141420.GB27281@IUPUI.Edu>

On Mon, Jan 05, 2015 at 08:22:47PM -0500, Robert J. Hansen wrote:
> > We only *suspect* that: we saw him holding a smoking gun but did not 
> > actually see him fire it.

True.  But we have established an identity between him and a person of
interest in the case.  Investigation of that interest is going to
require some more identities ("where were you on the night of the 13th?")

> Yes, which is plenty sufficient to soothe my conscience about invasive
> measures.  If there's a homicide, ought it go uninvestigated and the
> shooter undiscovered just because we're concerned we might be invading
> the privacy of a possibly-innocent person?  I would suspect I was
> grossly misunderstanding you were it not for what you said below:
> 
> > I'm not fine with invasive anything whilst they are *only* a
> > suspect. And once you have proven guilt or innocence it matters not a
> > jot who they are.

I suspect that imprecise language such as "who they are" lies at the
root of the disagreement here.  I think there may be some disagreement
about the meaning of "invasive" as well.

> "Until you prove guilt I won't approve of any serious investigation into
> who did it or how.  And if somehow you prove guilt anyway then you don't
> need to ask these questions any more, so I still won't approve."
> 
> Okay.  Thanks.  I'm really glad you're in the minority: if I were to
> wind up murdered on a city street, I'd really hope the police would care
> enough to find out who did it and how it was done and why -- even if
> those questions might offend people's sensibilities.

Well, if a person is suspected of a crime, many of his various
identities are irrelevant.  Others may be critical to establishing
guilt or innocence.  ("But this photo of me in the Boston Globe shows
that I was nowhere near the scene at the time you say the crime was
committed.  Look at that clock behind me.")

Now, if guilt is established, that new identity matters a great deal,
since it tells us who to discipline.  If guilt is disproven then that
should be made clear to anyone who might reasonably have learned of
the suspicion.  So:

o  if guilt is proven, that is the only identity we care about
   w.r.t. the crime;

o  if guilt is disproven, then the suspect's public identities are
   relevant to publishing his innocence.

Things get murky when you consider established procedures.  If the
suspect is released, but ordered to remain available ("don't leave
town") then the police need to record and distribute established
identities sufficient to detect whether the suspect is disobeying the
order.  Later there may be a need to identify a person who is no
longer to be especially watched.

(This is why I tend to think of identification as the establishment
and maintenance of sets of mappings or labels.  I have a lot of labels
("identities") stuck on me by family, friends, enemies, employers,
trading partners, etc., each of which is more or less independent.
Various sets of these labels make up how my associates retrieve their
concepts of me.)

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: </pipermail/attachments/20150106/dbcb9c46/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 02:04:49 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 01:04:49 +0000
Subject: Thoughts on Keybase
In-Reply-To: <54AB38E7.8070804@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
Message-ID: <284799998.20150107010449@my_localhost>

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

Hi


On Tuesday 6 January 2015 at 1:22:47 AM, in
<mid:54AB38E7.8070804 at sixdemonbag.org>, Robert J. Hansen wrote:


> Yes, which is plenty sufficient to soothe my conscience
> about invasive measures.

To me, that is tantamount to saying "If we think he did this but can't
prove it; let's pull his life apart just in case we can pin something
on him."



> If there's a homicide, ought
> it go uninvestigated and the shooter undiscovered just
> because we're concerned we might be invading the
> privacy of a possibly-innocent person?

If there is compelling evidence it should be followed up, sensibly and
in proportion to the weight of that evidence rather than the
accusation. Beyond that and regardless of the seriousness of the
matter under investigation, the individual should not be hounded by
the authorities.

He is placed at the scene with the smoking gun but there is not yet
any evidence that *he* fired it. It is a bit of a leap from that
position to an investigation of what food he bought yesterday, how he
travels to work, where he lives... As I said, "Fractions of an identity"
that are not relevant to the specific identity enquiry.



> "Until you prove guilt I won't approve of any serious
> investigation into who did it or how.  And if somehow
> you prove guilt anyway then you don't need to ask these
> questions any more, so I still won't approve."

That's better than "we have no evidence so we will investigate the
minutiae of everybody in the vicinity's lives."



> Okay.  Thanks.  I'm really glad you're in the minority:
> if I were to wind up murdered on a city street, I'd
> really hope the police would care enough to find out
> who did it and how it was done and why -- even if those
> questions might offend people's sensibilities.

And if I were to wind up murdered on a city street, I'd be dead so I
wouldn't care.

Anyway, we have gone *way* off-topic. My original comment was intended
to convey my general opinion that a publicly-known dossier of
unrelated "identity" events sounds far too invasive to be comfortable.
And later in my posting, the corollary that keybase does not sound
like something attractive to people who, like me, prefer to
compartmentalise the facets of their life as separate "fractions".

- --
Best regards

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

Vegetarian: Indian word for lousy hunter!!!
-----BEGIN PGP SIGNATURE-----

iQF7BAEBCgBmBQJUrIY9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwk+YH9139eKZ5+EzkBQ0UF0Xu010Q
fBlsRRt6kXLsQKZl2lRh0jVU4LfPv3NlheciDDN4jr6tuVYkDfV11l9xB0zPoyE0
qWcg+Zco8RvNU1R/dESI8lf/yZjyD7ID4fE2fM2ZKd+ubbowJfHvizUI0/DaOW37
iZGQRqF9Uc5ghuzVe/9vqHynuR1CzoWz8mjQiPOHtmjngU4qAb0yPzOtE/PSmOJr
e63tpgxjXsPHgMbh6SV77hUb+2bn24VASI+cD57Gg0zYnrvqksIM8H4rk1gfB8Ln
Bjj8e5mcAvLxk3H4YKJ85Qkq3MY0AtfX1X5Yoww/ppIiKJUQn8frpIYEeElvK4i+
BAEWCgBmBQJUrIZCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5w
Z3AuZmlmdGhob3JzZW1hbi5uZXQzM0FDRUQ0RUU5MTM0RUVCREU2QTg1MDYxNzEy
QkM0NjFBRjc3OEU0AAoJEBcSvEYa93jk6XoBAPR9Ike6NoNSgX2oHq52othcKmS9
FS3P27PdztTMjrlcAQC/3J3KDLEYBK3CJYktGJTeewT+d3jveQjsnEhu+tsXAQ==
=tQDU
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 03:01:38 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 02:01:38 +0000
Subject: Thoughts on Keybase
In-Reply-To: <20150106141420.GB27281@IUPUI.Edu>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu>
Message-ID: <1375258041.20150107020138@my_localhost>

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

Hi


On Tuesday 6 January 2015 at 2:14:20 PM, in
<mid:20150106141420.GB27281 at IUPUI.Edu>, Mark H. Wood wrote:



> True.  But we have established an identity between him
> and a person of interest in the case.  Investigation of
> that interest is going to require some more identities
> ("where were you on the night of the 13th?")

We know he was standing with a smoking gun, close to a body on the
ground. We should be investigating what happened, not wasting our time
with yesterday's food and the last three years' commuting habits.



> I suspect that imprecise language such as "who they
> are" lies at the root of the disagreement here.

"Who they are" in the sense of "what their name is" is obviously
irrelevant to whether they fired the gun. And I contend the vast
majority of "choices this person has made over time" would be
similarly unconnected to that night's events.



> I
> think there may be some disagreement about the meaning
> of "invasive" as well.

Probably more to do with context. My comment about sounding too
invasive to be comfortable would, in hindsight, have sat better at the
beginning of my final paragraph.



> Well, if a person is suspected of a crime, many of his
> various identities are irrelevant.

Probably most.



> Others may be
> critical to establishing guilt or innocence.

The authorities need to prove guilt. The suspect does not need to
prove innocence.



> o  if guilt is proven, that is the only identity we
> care about    w.r.t. the crime;

There are those who disagree, and insist on Criminal Record checks
when an individual interacts with them in a context completely
unrelated to any crime - such as a job application.



> o  if guilt is disproven, then the suspect's public
> identities are    relevant to publishing his innocence.

If the suspicion went to court but was not proven, that is a matter of
public record. If it never went to court, it would often be in the
individual's interest to not draw attention to having been a suspect.
(-:



> (This is why I tend to think of identification as the
> establishment and maintenance of sets of mappings or
> labels.  I have a lot of labels ("identities") stuck on
> me by family, friends, enemies, employers, trading
> partners, etc., each of which is more or less
> independent. Various sets of these labels make up how
> my associates retrieve their concepts of me.)

That is right. Each person sees only the subset of labels relevant to
mutual interaction, plus any additional that the subject chooses to
reveal or the associate happens to stumble upon.

(What if each of these labels mapped to a UID on an OpenPGP key, but
anybody who didn't see that particular label on you could not read the
corresponding UID on your key?)



- --
Best regards

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

Confusion is always the most honest response
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrJOOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwc5cH/26xRrdQ0njl2F8XoKdrRDpM
84YeQ2OeRjILpXjcQv0lCViEmb7x0mpHgoMIcOIzetzUzgzSKsqiLOYnrBiczCho
yyg/WObdpep5DdvvRHLY/HQm43j8AsPDmX8AMxhTYJjJRdKNDL7Dw67cWQDyydnw
mi9LFb7U4Jdms9swW57qR0HXWvw2mWJSLeBgiHzzRvIR1q8Mt2gjFlpeU9dP75Bt
OImFi3EborqhKfEFg0bPmvyuhkYkKWYtHr2A0DTSLe/GoPWZpk7IcqNAksf1jGyT
Rv1W5JHPSWoMPmMlgXVDhu1jGiCtr8zEbGuOxLOg3mOjrTg7VVq/EEa1cS106yGI
vgQBFgoAZgUCVKyTlV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KQFAQDb1031URw83UVd4Oig4NEjn4RO
tIhF/ZmbEj5yvpAVUQEAQzbbPe42dVBeeZ+1N0zFPnuDCnzwZkcS7atZHb1NnAs=
=q+KL
-----END PGP SIGNATURE-----



From mirimir at riseup.net  Wed Jan  7 03:14:43 2015
From: mirimir at riseup.net (Mirimir)
Date: Tue, 06 Jan 2015 19:14:43 -0700
Subject: Thoughts on Keybase
In-Reply-To: <284799998.20150107010449@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <284799998.20150107010449@my_localhost>
Message-ID: <54AC9693.2090402@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2015 06:04 PM, MFPA wrote:

<SNIP>

> Anyway, we have gone *way* off-topic. My original comment was intended
> to convey my general opinion that a publicly-known dossier of
> unrelated "identity" events sounds far too invasive to be comfortable.
> And later in my posting, the corollary that keybase does not sound
> like something attractive to people who, like me, prefer to
> compartmentalise the facets of their life as separate "fractions".

I also favor compartmentalization. But reading <https://keybase.io/>, I
don't see any requirement to include all online identity information,
provide government-issued ID, etc, etc, etc. I already use Gravatar
<http://www.gravatar.com/avatar/2fb817d36499985e91e5778ed4a0c8b7.png>.

Wouldn't Keybase just better link all that to Mirimir's GnuPG key? Or am
I missing the point? Is there an expectation that Keybase usernames are
not merely pseudonyms?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUrJaBAAoJEGINZVEXwuQ+L6gH/A0z0qyVlF5kiL5L6ZbPup7r
pzz65XyllIMXJAlPGTlaxfT/RJw39MwtvlHrzfcspfdvpM3C3WjqquWKrN83dyvl
CLT7bYGUkgF2Ziwmw38j7MR9WPC6Yh4VbDHupTZ7Cp7Ita6KT9PT2y4GoSZ1FmCl
NE/9Yv9iM2peWYlnNCQQcLQ8Ajtf1CMKCzxMNHXLzNh4tj64Pz0au/WpMQDl78et
HXzkh61taINTyLW8wBzHu3ossvHg/HbkNOtW3Y6XnxaNsrdMb7HccfDMHOjmi2KZ
+bNSf/xnLN/BvmuKDYMwy/xwqj0WR1iQrmnz2LbQ+vt7q4C1wB1kumwb5Rgiyac=
=o0u9
-----END PGP SIGNATURE-----


From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 03:25:28 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 02:25:28 +0000
Subject: Untrusted certificate for https://wiki.gnupg.org/
In-Reply-To: <54AB0B1F.90303@posteo.de>
References: <54AB0B1F.90303@posteo.de>
Message-ID: <552613829.20150107022528@my_localhost>

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

Hi


On Monday 5 January 2015 at 10:07:27 PM, in
<mid:54AB0B1F.90303 at posteo.de>, Alexander Buchner wrote:


> In https://www.gnupg.org/blog/index.html there is link
> to https://wiki.gnupg.org/ which is kind of broken,
> because the site's certificate is untrusted due to an
> incomplete certificate chain.

I get a complete chain, just with a CA that is not "trusted" by my
copy of Firefox. I don't see what they gained by signing the cert with
that CA rather than leaving it as self-signed.

- --
Best regards

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

The trouble with words is that you never know whose mouths they've been in.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrJkeXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwuj8H+wfeQpL2oNMqQ1c1kukdD95p
d5q0z7PqllVE6rY2xV1V6I74LobURl1WNOKresKrZT8vCOKn5kOQrx/gDSP3cOb8
wamcuA+Y/s4fkdwyAv0JbRmwF1yFRJhFqdlMzWXKhWBtTRTEbyjhzt23/H937Brx
AgvuRTE/aZ33koX5k5svug5KViHKr6C3+oXELRUvW4kvQF4iEChXBz15hvGW4foV
X+jeXOZSHbRagq0wIIMu4y+ViFPBcUwJ3GD/x4jPJA86MmLEBgdlq7hTyN86+Iu6
yfjJPoB/COEALR1TQ9mfY/3M7jBLeEqr0WD64Yx7lSO3ND9wTEC4HJRyrKPlae+I
vgQBFgoAZgUCVKyZJV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45I4TAQCyfqAVCOkXk7tS9odU5RkOn4J+
KkUhigDD0+/iFyairgEALmM048lWoP2JyAvAmrGO6OMO8IUfY+agh6JuMW7LhQs=
=NMup
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 03:30:55 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 02:30:55 +0000
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
 <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
Message-ID: <456250107.20150107023055@my_localhost>

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

Hi


On Monday 5 January 2015 at 10:46:54 PM, in
<mid:4F6CE41D-0A52-42B8-A413-159F3505E204 at yahoo.com>, Nex6|Bill wrote:



> But I have seen some of the more
> paranoid privacy folks doing 4096 key pairs.

I'm sure I have even seen discussions about 16384-bit. I seem to
recall somebody posting where the code would need changing to allow
this, but cautioning such a key would be unusable by virtually
everybody else.



- --
Best regards

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

She looked like butter wouldn't melt in her mouth - or anywhere else.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrJpgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwmqIH/i4XQQw/1S+5xgZGO5LkNZCO
ReVWnU4dhciwEpE1oOSj1EkT/4XQrW3LJNYtRO944YEktvKS2UUUJniJ7rixEoqa
/mzpSmGBD5VZm0YOOanYVceEwMHF8r1+SLZ+Dm9S8z/Sm8KMcvVAIYjrpXSjMN4W
CDHfHSDPKXnvcfp6PZ44vqFhwPEiBNhJ6sEbJ0zRQjrUut8LIZWcAyLDxVajf6I7
FX5xLUVBIx7bD1OUGEdmvcjwslkeOWtjH6w1xZgeNwTRqCg+81hhq8ZPrzFwSITN
bg6JBpaiPBC/N/AwWtFkLnLEsCvQ7CMAKyAX4drr02HGAP3X9KzAirePHH5az6yI
vgQBFgoAZgUCVKyaYF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HCMAQDcfyHpszBcnJVLpjb1M2Jt+xWH
KB2iRhAFvuIyjAAgCgEAMpjbTs/MS+WuCIpZ/osC/mE15YcXq8qOKZpKpF498AQ=
=Xn7S
-----END PGP SIGNATURE-----



From s.murthy at mykolab.com  Wed Jan  7 03:55:50 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Wed, 7 Jan 2015 02:55:50 +0000
Subject: Thoughts on Keybase
In-Reply-To: <54AC9693.2090402@riseup.net>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <284799998.20150107010449@my_localhost> <54AC9693.2090402@riseup.net>
Message-ID: <1351624B-666C-49A1-8896-3009CDFB457C@mykolab.com>

Hi

I like the idea of Keybase, although it may appear ironic
that an application designed to encourage people to
protect their privacy by using encryption more widely
and accessibly may require the storage and public
monitoring of digital identity records.

I think it shows there must be give and take - if you want
complete privacy you can go and hide in a bunker completely
cut off from the external world.  But if you have any desire
to communicate with others then you have to be willing to
give up the that little bit of your public identity which you want
other people to know is genuine, in order to protect your
private communications.

Sandeep Murthy
s.murthy at mykolab.com

> On 7 Jan 2015, at 02:14, Mirimir <mirimir at riseup.net> wrote:
> 
> Signed PGP part
> On 01/06/2015 06:04 PM, MFPA wrote:
> 
> <SNIP>
> 
>> Anyway, we have gone *way* off-topic. My original comment was intended
>> to convey my general opinion that a publicly-known dossier of
>> unrelated "identity" events sounds far too invasive to be comfortable.
>> And later in my posting, the corollary that keybase does not sound
>> like something attractive to people who, like me, prefer to
>> compartmentalise the facets of their life as separate "fractions".
> 
> I also favor compartmentalization. But reading <https://keybase.io/>, I
> don't see any requirement to include all online identity information,
> provide government-issued ID, etc, etc, etc. I already use Gravatar
> <http://www.gravatar.com/avatar/2fb817d36499985e91e5778ed4a0c8b7.png>.
> 
> Wouldn't Keybase just better link all that to Mirimir's GnuPG key? Or am
> I missing the point? Is there an expectation that Keybase usernames are
> not merely pseudonyms?
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



From rjh at sixdemonbag.org  Wed Jan  7 04:27:10 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 6 Jan 2015 22:27:10 -0500
Subject: Thoughts on Keybase
In-Reply-To: <1375258041.20150107020138@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
Message-ID: <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>

> We know he was standing with a smoking gun, close to a body on the
> ground. We should be investigating what happened, not wasting our time
> with yesterday's food and the last three years' commuting habits.

Unfortunately, unless you?re psychic this is impossible.  You don?t know what information will be relevant.  You?ll never discover ?the dead guy spilled a hot coffee all over the other guy yesterday, and they had an argument, and the guy said he was going to kill him for spilling coffee? unless you interview the barista where the shooter had a cup of coffee yesterday.

> "Who they are" in the sense of "what their name is" is obviously
> irrelevant to whether they fired the gun.

The police?s job isn?t just to see whether a person fired the gun; it?s also to determine why, and whether more crimes are likely connected. If the dead guy is named McCoy and the living one is named Hatfield, that?s a strong hint the death is connected to a blood feud and the police need to be on the lookout for revenge killings.

> And I contend the vast
> majority of "choices this person has made over time" would be
> similarly unconnected to that night's events.

Yes.  But some would likely be.  You don?t know what information will be relevant.

> The authorities need to prove guilt. The suspect does not need to
> prove innocence.

Only true in certain countries.

> There are those who disagree, and insist on Criminal Record checks
> when an individual interacts with them in a context completely
> unrelated to any crime - such as a job application.

Not a privacy invasion, since that?s a public record.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150106/f5ad45bf/attachment.bin>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 04:29:36 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 03:29:36 +0000
Subject: Thoughts on Keybase
In-Reply-To: <54AC9693.2090402@riseup.net>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <284799998.20150107010449@my_localhost> <54AC9693.2090402@riseup.net>
Message-ID: <1965247078.20150107032936@my_localhost>

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

Hi


On Wednesday 7 January 2015 at 2:14:43 AM, in
<mid:54AC9693.2090402 at riseup.net>, Mirimir wrote:



> I also favor compartmentalization. But reading
> <https://keybase.io/>, I don't see any requirement to
> include all online identity information, provide
> government-issued ID, etc, etc, etc.

Including more than one of your online identities on the same keybase
profile damages the compartmentalisation between those identities.

Would there be much point in having a separate keybase profile for
each separate online identity? I guess it would have some value as a
kind of surrogate keyserver. A quick look at a few random keybase
profiles showed me some that had only a person's name and a link to a
key. And one with no identity links at all but 20 trackers.




> I already use
> Gravatar
> <http://www.gravatar.com/avatar/2fb817d36499985e91e5778ed4a0c8b7.png>.

Does that mean Gravatar can track your activity (or popularity?)
across all sites that fetch the image?



> Wouldn't Keybase just better link all that to Mirimir's
> GnuPG key?

If you favour compartmentalisation, wouldn't that be something to
avoid?



> Or am I missing the point? Is there an
> expectation that Keybase usernames are not merely
> pseudonyms?

I think it is that you *can* (rather than *must*) use your real name
and photo and link it to your OpenPGP key and your other online
presences.

People believe it really is *your* facebook page (or whatever), so
they will believe it is *your* key.

Here is a review of Keybase I found:-

<http://www.coindesk.com/keybase-project-plans-make-cryptography-easy-twitter/>.

- --
Best regards

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

Was time invented by an Irishman named O'Clock?
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrKgtXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwZdUH/RVdHkDRfRumN5gEAzcAUupQ
WTVT3OVAu759mpm+eBddpraOCYKh2sDz9lAGS8yXQDRqkSjyWGIPCcZWVgbsWlvE
A1BQQ/03BxBZooQ4/ti8W8NBZsL3vBZ8P+mY0WH8XreOc8/8t8UeSzEx91rXWalQ
laqBrAHwXGaMrol71hxWbb/FHmuvnWqW4QwooGohUCYXxP2y4drXRGRLWkKNkY3t
RE5hwszEIfyV4oGSp2TFl3eTqYNMDRG381DACufAIPczdgPifuVwE9cnW97xY9om
ON1DuK4jORtaO+pZh8WrOUkweQHqkjO2ZHYAx/LDg4kss4j2Jtx0eCLxteFA0l2I
vgQBFgoAZgUCVKyoO18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45N9wAQABgI1pwJgF1mf2nG42hPYiLkx5
ETJbjGXQMC6rdckKWAEAWRDbWDK3kzRqW/fWp/bY/+NMGmOMb1wStzHQNX0YIA0=
=bhEM
-----END PGP SIGNATURE-----



From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 05:05:06 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 04:05:06 +0000
Subject: Thoughts on Keybase
In-Reply-To: <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
Message-ID: <10810727989.20150107040506@my_localhost>

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

Hi


On Wednesday 7 January 2015 at 3:27:10 AM, in
<mid:9A642D95-C400-442F-B952-639B7F848067 at sixdemonbag.org>, Robert J.
Hansen wrote:



> Unfortunately, unless you?re psychic this is
> impossible.  You don?t know what information will be
> relevant.  You?ll never discover ?the dead guy spilled
> a hot coffee all over the other guy yesterday, and they
> had an argument, and the guy said he was going to kill
> him for spilling coffee? unless you interview the
> barista where the shooter had a cup of coffee
> yesterday.

Aside from only demonstrating possible earlier intent rather later
actions, the fraction of comments of "I'll kill you" that actually convert to
murders is vanishingly small. If I were a juror, this evidence would
tell me nothing about guilt or otherwise.



> The police?s job isn?t just to see whether a person
> fired the gun; it?s also to determine why, and whether
> more crimes are likely connected.

I'm not sure the "why" matters, unless for mitigation. But connected
crimes makes sense.



> If the dead guy is
> named McCoy and the living one is named Hatfield,
> that?s a strong hint the death is connected to a blood
> feud and the police need to be on the lookout for
> revenge killings.

The reference is lost on me. Neither is exactly an uncommon name.



> Only true in certain countries.

I read recently that under Napoleonic law in France, the accused has
to disprove state accusations. But I never gave it any credence.



> Not a privacy invasion, since that?s a public record.

CRB checks (in the UK) also include non-public records held by police
forces and other organisations.

And of course it is a privacy invasion to go delving into records of
past events if the subject has not shared them with you and does not
generally broadcast them. When the penalty has been paid, the debt to
society is discharged and it is no longer anybody else's business.

- --
Best regards

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

Put knot yore trust inn spel chequers
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrLCAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwRfoH/30RzmjOCXF4+eV7uSMqUHkn
iXbv7NBp9agKN84sc04umU64d2QAgx47G5hsaFrw3Vzb/yVmSXYOCwWjqXKL9hql
5MEDvHVtNvhuo+kweIkSbvT9SGempZxBOGJ81cc8PEKVadAL9LInWH6qA5r/Ne7H
lCkq9Z7GngdObJ5OZ1gINdQwP0Wwae3yW6dhCCWzmRUZEQ89KtUSUeydsw4wvkXw
tvzV/Pur3fABOVE2JS/Nxo/1gU//+DfKlnwU4UCA4begrTGbD4vAAn3dU4XU8R4H
tFfyhPm3LyAKou4aqKrdO/XmWEnQOQAfu/aBDcbWK845PJbhop9m8RPsyczba6+I
vgQBFgoAZgUCVKywhV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45JVyAQCmWr2UjSVSu215CgM3T/QHoYS5
wHjUNVlU/rUi9V9NHQEASFFhiJcdFd90AMfDcMYDYjP3sgChIF1UWwL1L/hv0wY=
=wv7y
-----END PGP SIGNATURE-----



From mirimir at riseup.net  Wed Jan  7 05:12:22 2015
From: mirimir at riseup.net (Mirimir)
Date: Tue, 06 Jan 2015 21:12:22 -0700
Subject: Thoughts on Keybase
In-Reply-To: <1965247078.20150107032936@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <284799998.20150107010449@my_localhost> <54AC9693.2090402@riseup.net>
 <1965247078.20150107032936@my_localhost>
Message-ID: <54ACB226.2000804@riseup.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2015 08:29 PM, MFPA wrote:
> Hi
> 
> 
> On Wednesday 7 January 2015 at 2:14:43 AM, in
> <mid:54AC9693.2090402 at riseup.net>, Mirimir wrote:
> 
> 
> 
>> I also favor compartmentalization. But reading
>> <https://keybase.io/>, I don't see any requirement to
>> include all online identity information, provide
>> government-issued ID, etc, etc, etc.
> 
> Including more than one of your online identities on the same keybase
> profile damages the compartmentalisation between those identities.

Right. But including more than one seems more genuine, somehow ;) And
mostly I meant multiple accounts using a particular pseudonym, rather
than multiple pseudonyms.

> Would there be much point in having a separate keybase profile for
> each separate online identity? I guess it would have some value as a
> kind of surrogate keyserver. A quick look at a few random keybase
> profiles showed me some that had only a person's name and a link to a
> key. And one with no identity links at all but 20 trackers.

I wouldn't bother for most of them. But I do like having all Mirimir
stuff linked, with authenticated association to a key. I see it more as
an enhanced keyserver than as a surrogate.

>> I already use
>> Gravatar
>> <http://www.gravatar.com/avatar/2fb817d36499985e91e5778ed4a0c8b7.png>.
> 
> Does that mean Gravatar can track your activity (or popularity?)
> across all sites that fetch the image?

I'm sure that they could. But I don't care.

>> Wouldn't Keybase just better link all that to Mirimir's
>> GnuPG key?
> 
> If you favour compartmentalisation, wouldn't that be something to
> avoid?

Not at all, as long as it's just Mirimir stuff that's linked. Each of my
other pseudonyms has its own key, and its own set of accounts. But none
of them is active in the same circles as Mirimir. I don't play sock
puppet games.

>> Or am I missing the point? Is there an
>> expectation that Keybase usernames are not merely
>> pseudonyms?
> 
> I think it is that you *can* (rather than *must*) use your real name
> and photo and link it to your OpenPGP key and your other online
> presences.

We shall see if they give me an account :)

> People believe it really is *your* facebook page (or whatever), so
> they will believe it is *your* key.

Well, I don't do Facebook as Mirimir. But Wilders is arguably a geeky
equivalent thereof.

> Here is a review of Keybase I found:-
> 
> <http://www.coindesk.com/keybase-project-plans-make-cryptography-easy-twitter/>.

Cool.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUrLIgAAoJEGINZVEXwuQ+8DMH/1kQCyE9F+n4xq1TBDiIG1hS
a8AqCN2v3uuWU3+1iPZrnaT1aOR0Hauty6uq9pupEFOw3hb7VF8ZUV9+ksp9nUO2
RnvMEDFr0Bw1SIFUhGZhYcDM6cv7gBbvpVQ9rX6JyaaqbF6DY/dgfI9P+io+WFxu
3cPfNMAnf4VeGQvW+uL6WygHmy0dNHKw2S55kqyfEYMmpNw2xjiKMvk9Dz5mWxFG
kUeHVDsSjegVgto3DKX6E/0dTb66NxmX01HYxZ0UcSsR5gL/L7mAEnVJZtW/JcOT
xe1plqW0KhxP8yOYTmd3dpqTjnAQB/s7oMFrfIAu8RNOYmL3sFU837zbFgz6+FM=
=fVw9
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Wed Jan  7 05:30:45 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 6 Jan 2015 23:30:45 -0500
Subject: Thoughts on Keybase
In-Reply-To: <10810727989.20150107040506@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
Message-ID: <F648B258-B808-42CD-90F2-A8888A66EF3D@sixdemonbag.org>

> Aside from only demonstrating possible earlier intent rather later
> actions, the fraction of comments of "I'll kill you" that actually convert to
> murders is vanishingly small. If I were a juror, this evidence would
> tell me nothing about guilt or otherwise.

Sure it does ? premeditation.  Murder committed with premeditation and malice aforethought is punished much more severely (in most places) than a heat-of-the-moment killing.  Knowing the offender?s state of mind is thus a perfectly legitimate avenue of inquiry, and requires investigation into background.

>> If the dead guy is
>> named McCoy and the living one is named Hatfield,
>> that?s a strong hint the death is connected to a blood
>> feud and the police need to be on the lookout for
>> revenge killings.
> 
> The reference is lost on me. Neither is exactly an uncommon name.

http://en.wikipedia.org/wiki/Hatfield%E2%80%93McCoy_feud

Or just Google ?hatfield mccoy?.

> And of course it is a privacy invasion to go delving into records of
> past events if the subject has not shared them with you and does not
> generally broadcast them. When the penalty has been paid, the debt to
> society is discharged and it is no longer anybody else's business.

I understand you believe there is a right to be forgotten; I hope you will understand I consider that to be Pollyannic fantasy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150106/ed94e7ad/attachment.bin>

From mirimir at riseup.net  Wed Jan  7 06:02:03 2015
From: mirimir at riseup.net (Mirimir)
Date: Tue, 06 Jan 2015 22:02:03 -0700
Subject: Thoughts on Keybase
In-Reply-To: <F648B258-B808-42CD-90F2-A8888A66EF3D@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
 <F648B258-B808-42CD-90F2-A8888A66EF3D@sixdemonbag.org>
Message-ID: <54ACBDCB.20003@riseup.net>

On 01/06/2015 09:30 PM, Robert J. Hansen wrote:

<SNIP>

> I understand you [MFPA] believe there is a right to be forgotten; I
> hope you will understand I consider that to be Pollyannic fantasy.

Indeed. I agree.

But what about a right to authenticated pseudonymity?


From robertc at broadcom.com  Wed Jan  7 06:03:58 2015
From: robertc at broadcom.com (Bob (Robert) Cavanaugh)
Date: Wed, 7 Jan 2015 05:03:58 +0000
Subject: Thoughts on Keybase
In-Reply-To: <10810727989.20150107040506@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D3A329C@IRVEXCHMB11.corp.ad.broadcom.com>

Hi, 
Just to add clarification:

Locke-ian  philosophy posits innocent until proven guilty. Napoleonic posits guilty until proven innocent. Both systems of justice are currently in practice in various parts of the world. The United States is founded on the Locke-ian philosophy which is the one I am personally more comfortable with.

To save you some reading:
The Hatfield-Mccoy feud took place in Appalachia in the United States at the time of and right after the American Civil War. It became iconic for Americans for conflicts involving family and revenge killings.

Thanks,
 
Bob Cavanaugh

-----Original Message-----
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of MFPA
Sent: Tuesday, January 06, 2015 8:05 PM
To: Robert J. Hansen on GnuPG-Users
Subject: Re: Thoughts on Keybase

* PGP Signed by an unknown key

Hi


On Wednesday 7 January 2015 at 3:27:10 AM, in
<mid:9A642D95-C400-442F-B952-639B7F848067 at sixdemonbag.org>, Robert J.
Hansen wrote:



> Unfortunately, unless you?re psychic this is
> impossible.  You don?t know what information will be
> relevant.  You?ll never discover ?the dead guy spilled
> a hot coffee all over the other guy yesterday, and they
> had an argument, and the guy said he was going to kill
> him for spilling coffee? unless you interview the
> barista where the shooter had a cup of coffee
> yesterday.

Aside from only demonstrating possible earlier intent rather later
actions, the fraction of comments of "I'll kill you" that actually convert to
murders is vanishingly small. If I were a juror, this evidence would
tell me nothing about guilt or otherwise.



> The police?s job isn?t just to see whether a person
> fired the gun; it?s also to determine why, and whether
> more crimes are likely connected.

I'm not sure the "why" matters, unless for mitigation. But connected
crimes makes sense.



> If the dead guy is
> named McCoy and the living one is named Hatfield,
> that?s a strong hint the death is connected to a blood
> feud and the police need to be on the lookout for
> revenge killings.

The reference is lost on me. Neither is exactly an uncommon name.



> Only true in certain countries.

I read recently that under Napoleonic law in France, the accused has
to disprove state accusations. But I never gave it any credence.



> Not a privacy invasion, since that?s a public record.

CRB checks (in the UK) also include non-public records held by police
forces and other organisations.

And of course it is a privacy invasion to go delving into records of
past events if the subject has not shared them with you and does not
generally broadcast them. When the penalty has been paid, the debt to
society is discharged and it is no longer anybody else's business.

--
Best regards

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

Put knot yore trust inn spel chequers

* Unknown Key
* 0x1AF778E4(L)


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

From s.murthy at mykolab.com  Wed Jan  7 08:33:51 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Wed, 7 Jan 2015 07:33:51 +0000
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <456250107.20150107023055@my_localhost>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
 <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
 <456250107.20150107023055@my_localhost>
Message-ID: <89DD34EA-4951-4495-B890-82DA97AE368D@mykolab.com>

Just out of curiosity I wanted to know the kind of numbers we are dealing with if
we use keys with length 16384.  Here?s the biggest :)

118973149535723176508575932662800713076344468709651023747267482
123326135818048368690448859547261203991511543748483930925889766
738130868742627452469834156500608087163436600489752214325161953
144684595234570948213584703664746483098478471428096784561413847
604433840488612290528685531323615869599988579010635701812081536
332078096432371275716429061340687520241736532395026788008906751
737227061083564754575578079343162221345190381785963069031134385
065753936064964519328317829176765896540528511355613436979328172
588801590841467528983253806341923488859989898062311402512167447
205187243932132319840294270534136695127473901459381689828899444
517340036461792837713807441134579184857359507717043764419174388
964488537768473832224060823907906139947567533473978401649174262
148522901484767233597789715839733422634973481144165307775825098
892603089478960467615310425726014180682302758800344195145532770
159807128158959716941396560843950498317125506228202662620004804
214980820000206099343368123762385788062747972707287748283843870
504803416463333701338540599804070190866238730160501818826257372
376627924079893171770880790174026540793097641964887786960401751
769193868798808800894425125882696968836419413394578015784436494
605271365545490632718742853189510027869511932349680870363043619
392759269234482081283429736447868686206416904245855513653205505
050818989186684686379991764754729137157350070101519755909745304
003303152068351821649419563669607774811059828490134361146921427
412181049507797927555664516498385006205106651708464736946403664
056933946483717218335295687391204264000361161878927819571005209
456276130670355184033011064510199543516762668866962776382060434
248035790641535421273294675607300690708887049612505006815665925
276129766406549834749266179882406231221040927458456558726484641
765016012317587403472626195728908146619765155383074442470969863
475362777035622712614505254912522944804014911479568135987596851
280857524427187145545408489498615502079480698093921565805531916
564168110596645415995147690858312972150329881658514207306148088
802176981833841712939687837145957584605258314292844724970369854
812529577592093645002265142724994958070820396608284755092189115
213332104801197388363657782553332598885215632543933502131531213
408139045102125536370790349591696312592420116787719010893525591
453948821689711794326937360863907447279275111671512710639642508
135355313721355289053980260297864531979510097643293909192466022
887891290065421011828729829870738215971718456954051540302917330
729245439178956867421964076145117360061775218699191336683703388
720158207162586824713310451331509727471344272834060664289040649
663610444321775281122747002916285809372770104964649954022098398
193278661320425422646424368961010742992319763868154583756177353
556898453605362723442427710576092486402378162966552631491090696
048807347521700512113631187043992576250866603256621375041669571
991967422321060672472137347123402161354071218823990970197194394
434748031421790388631776777992153989217733434436890755031880083
354685234437032708928414750164058944848200125423738668007445734
191093377489195968101651606910614990557242581089558693883306749
020490036862416630196855300568704028509545048484007352864382657
040376715728651238025510995451885701347658818930000413884971588
313986607154757481647672763511643546280440111271139252918057079
419342268681835321279906897224769719147426815791219597379419280
729888695236110088026425880132092804001192815397080113074133955
000329901592497825993697435872628614398052011245436927111408374
791900780340659632135341700406886944340547214067596364099740500
922580350567272646509550626733926889242436456189766190689842418
677049103534408039924832709791171288114017038418205860161475828
420075018350032935849969186406659053966070906953738160188767904
665775965458800193711777134469832642879262289433801611244553353
944708746204976340914754209924881552139592938800771117201789489
779370660427348098516102881545878791116097911342243355754917090
544202639727569528320730533184541999074934781052400619419720059
165214786719369625433786498160383314635420170062881794717751811
521767435201651117234772772707522005617774821892859715834674454
133710735842775791966056258388382326217896169178722611886563276
493428877240585975487775986923553065392993790119361166900747235
474636076460187244203137994413982436682869879021292299617419272
862589172005761250934910048254596415204647792511444650073216410
909934525979945569009557678868639748706194885474902486360792185
783420579379718883477965627347911238858570642483637907235541028
678701852740165393421988836106194967196105506868696146801903562
974942408658719504100440491526647627276107051156838706340126413
651723721140991645879634762494921590453393721093752046579830017
540801753886231271904236103712933889658602815004659607887244436
556448054568903357595570298839671974452821298414257848395400508
426432773084098542002140906948541232080526852009414679887611041
458317039047398248889922809181821393428829567971736994315246044
7027290669964066816

Sandeep Murthy
s.murthy at mykolab.com

> On 7 Jan 2015, at 02:30, MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:
> 
> Signed PGP part
> Hi
> 
> 
> On Monday 5 January 2015 at 10:46:54 PM, in
> <mid:4F6CE41D-0A52-42B8-A413-159F3505E204 at yahoo.com>, Nex6|Bill wrote:
> 
> 
> 
> > But I have seen some of the more
> > paranoid privacy folks doing 4096 key pairs.
> 
> I'm sure I have even seen discussions about 16384-bit. I seem to
> recall somebody posting where the code would need changing to allow
> this, but cautioning such a key would be unusable by virtually
> everybody else.
> 
> 
> 
> --
> Best regards
> 
> MFPA                    mailto:2014-667rhzu3dc-lists-groups at riseup.net
> 
> She looked like butter wouldn't melt in her mouth - or anywhere else.
> 
> 
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150107/fd72d33c/attachment.sig>

From bernhard at intevation.de  Wed Jan  7 09:24:34 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 7 Jan 2015 09:24:34 +0100
Subject: Untrusted certificate for https://wiki.gnupg.org/
In-Reply-To: <87mw5w2faq.fsf@vigenere.g10code.de>
References: <54AB0B1F.90303@posteo.de> <54ABC470.5010202@posteo.de>
 <87mw5w2faq.fsf@vigenere.g10code.de>
Message-ID: <201501070924.46450.bernhard@intevation.de>

On Tuesday 06 January 2015 at 14:45:49, Werner Koch wrote:
> > Btw: Also the TLS configuration of wiki.gnupg.org is not as good as the
> > one for gnupg.org (e.g. support for TLS 1.2), see
> > https://www.ssllabs.com/ssltest/analyze.html?d=wiki.gnupg.org
>
> Well, maybe they can give some insights.

We will look into this.
Probably elder settings for a low security side.

(Thanks for the direct copy, as I am reading this list occasionally 
and sometimes miss emails.)

On Wednesday 07 January 2015 at 03:25:28, MFPA wrote:
> I don't see what they gained by signing the cert with
> that CA rather than leaving it as self-signed.

You can get our root cert from 
  https://ssl.intevation.de/
Traditionally we run our own little CA. It serves testing purposes
and it allows us production use for lower security levels for less costs.
(So we do not feed the CA business as much. A business that Werner for the 
most part considers heavily broken.)

Best,
Bernhard


-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150107/68c72420/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan  7 11:13:35 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Wed, 7 Jan 2015 10:13:35 +0000
Subject: Thoughts on Keybase
In-Reply-To: <F648B258-B808-42CD-90F2-A8888A66EF3D@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
 <F648B258-B808-42CD-90F2-A8888A66EF3D@sixdemonbag.org>
Message-ID: <525738584.20150107101335@my_localhost>

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

Hi


On Wednesday 7 January 2015 at 4:30:45 AM, in
<mid:F648B258-B808-42CD-90F2-A8888A66EF3D at sixdemonbag.org>, Robert J.
Hansen wrote:


> Sure it does ? premeditation.  Murder committed with
> premeditation and malice aforethought is punished much
> more severely (in most places) than a
> heat-of-the-moment killing.

Indeed. In some places the label of "Murder" applies to the crime with
premeditation and malice aforethought, otherwise there is a different
label such as "Manslaughter".



> Knowing the offender?s
> state of mind is thus a perfectly legitimate avenue of
> inquiry, and requires investigation into background.

Fair enough, but I do not believe a throw-away comment heard in
arguments thousands of times per day throws any light on the
offender?s state of mind.





> I understand you believe there is a right to be
> forgotten;

In some contexts there is [0]. But I was not referring to any right to
be forgotten, simply to rehabilitation of offenders. Once the offender
has paid their "debt to society" they are rehabilitated and should not
be hindered from playing a full part in that society.



> I hope you will understand I consider that
> to be Pollyannic fantasy.

Absolutely; it is something to be striven towards but unlikely to be
totally achieved.


[0] <https://en.wikipedia.org/wiki/The_Right_to_be_Forgotten>.


- --
Best regards

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

Of course it's a good idea - it's mine!
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrQbgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwr2IH/0gHI6tpClOiy7ToYdO4G2MF
djr+EZAu5sbLXc2+aQOtTQC+vLKjtW1cGVQa/c7+Eb0RLWu1Q/Yt1AA6h5XSj4rg
hmkU3TogZWSzMVn+cRyzePTXPf9WAy2i8ec4K3iiqXB6pniJVxOtm2Nuig4aHudn
QK7kGh0NfKvk4gzxyv5jHua2OcsdDxgC7LflBqQUX6fxMDEGLAGGcF8o7imXi+h5
b4MOxfSZZ5KVi0aZgNkeGJoe1j1wuAahaPVvoj+7InsRCf1F/Ug/5IhMTp1p4Yaq
7O6BAMHPZv4wfpd6Ehj7RcLSxDWwmqKvJxZCSj9X2guyCdzmZUBhgUw7uy5/eEKI
vgQBFgoAZgUCVK0G5l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45PvaAQCJHW3hd6VeE5x9gTImWZJf8tSj
SG15B62BIIqbUg8dTgEAFex2donV0D2JDB57ieoOuAW2p+UDU5NsYl3X22QJAQA=
=VKMZ
-----END PGP SIGNATURE-----



From MichaelQuigley at TheWay.Org  Wed Jan  7 14:08:27 2015
From: MichaelQuigley at TheWay.Org (MichaelQuigley at TheWay.Org)
Date: Wed, 7 Jan 2015 08:08:27 -0500
Subject: Thoughts on Keybase
In-Reply-To: <mailman.18701.1420601292.28939.gnupg-users@gnupg.org>
References: <mailman.18701.1420601292.28939.gnupg-users@gnupg.org>
Message-ID: <OF1D355A4D.211EBF83-ON85257DC6.0046976D-85257DC6.00482F98@TheWay.org>

"Gnupg-users" <gnupg-users-bounces at gnupg.org> wrote on 01/06/2015 10:28:12 
PM:
> ----- Message from "Robert J. Hansen" <rjh at sixdemonbag.org> on Tue, 
> 6 Jan 2015 22:27:10 -0500 -----
> 
> To:
> 
> MFPA <2014-667rhzu3dc-lists-groups at riseup.net>
> 
> cc:
> 
> "Mark H. Wood on GnuPG-Users" <gnupg-users at gnupg.org>, "Mark H. 
> Wood" <mwood at IUPUI.Edu>
> 
> Subject:
> 
> Re: Thoughts on Keybase
> 
> > We know he was standing with a smoking gun, close to a body on the
> > ground. We should be investigating what happened, not wasting our time
> > with yesterday's food and the last three years' commuting habits.

Indeed the events surrounding the crime must be fully investigated. 
However . . .

"Because sentence against an evil work is not executed speedily, therefore 
the heart of the sons of men is fully set in them to do evil." 
Ecclesiastes 8:11

> 
> Unfortunately, unless you?re psychic this is impossible.  You don?t 
> know what information will be relevant.  You?ll never discover ?the 
> dead guy spilled a hot coffee all over the other guy yesterday, and 
> they had an argument, and the guy said he was going to kill him for 
> spilling coffee? unless you interview the barista where the shooter 
> had a cup of coffee yesterday.

I agree. 

> > There are those who disagree, and insist on Criminal Record checks
> > when an individual interacts with them in a context completely
> > unrelated to any crime - such as a job application.
> 
> Not a privacy invasion, since that?s a public record.

Absolutely. Employers have been held liable for hiring people with a 
criminal record. e.g., Someone convicted of child molestation might not be 
the best choice for a school bus driver or even school janitor--even if 
they've "paid their debt." Or another less extreme example: hiring someone 
as a cashier who has a criminal record of armed robbery. Perhaps they 
could still be a candidate for a job, but the previous record would be 
something to discuss with the individual before hiring or perhaps even 
before dismissing them as a job candidate.

I don't suggest we forever treat anyone as guilty of and punishable for a 
crime, but there are reasonable limits to how much we trust someone who 
has been convicted for certain crimes. A criminal records check can 
establish patterns or the need for greater supervision in various 
positions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150107/bed2c530/attachment-0001.html>

From John at enigmail.net  Wed Jan  7 16:09:28 2015
From: John at enigmail.net (John Clizbe)
Date: Wed, 07 Jan 2015 09:09:28 -0600
Subject: Thoughts on Keybase
In-Reply-To: <548F2B16.1030703@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
Message-ID: <54AD4C28.2020903@enigmail.net>

Robert J. Hansen wrote:
> Keybase (https://keybase.io) is trying to solve the Web of Trust problem 
> in a new way.  They're currently in beta, but I was able to snag an 
> invitation.  (I have no invites to give out, unfortunately.)  The 
> following is just a write-up on how it works and what my impressions of 
> it are.  You may find it interesting.  You may not.  :)
> 
> =====

Does look interesting. Anyone have and willing to share an invite?

Reply off-list please.

Thanks,

-J
-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"


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

From rjh at sixdemonbag.org  Wed Jan  7 17:14:53 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 7 Jan 2015 11:14:53 -0500
Subject: Thoughts on Keybase
In-Reply-To: <10810727989.20150107040506@my_localhost>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
Message-ID: <F4A4690A-84E9-4A09-B32D-7AFC98339BC1@sixdemonbag.org>

> Aside from only demonstrating possible earlier intent rather later
> actions, the fraction of comments of "I'll kill you" that actually convert to
> murders is vanishingly small. If I were a juror, this evidence would
> tell me nothing about guilt or otherwise.

One more thing ? remember that probabilities are tricksy things.  They vary wildly depending on how one looks at the problem.

Let?s say there are 10,000 threats of murder that are made, and only 10 murders.  If we assume that only ten of those 10,000 threats was connected to a murder, the probability of any given threat being connected to a murder is vanishingly small ? one in a thousand, or 0.1%.  Starting from the fact there was a threat, it would be foolish to conclude the speaker intended on murdering someone.

However, if we look at the murders, we discover that 100% of them are connected to threats.  If you start from a murder, it would be pretty wise to start looking into who threatened the person.

If the only fact you have is ?Alice threatened Bob?s life,? then yes, that?s pretty poor evidence on which to investigate Alice for Bob?s death.  But if the facts you have are ?Alice threatened Bob?s life and Bob was killed under suspicious circumstances,? then yes, that?s actually pretty good evidence on which to investigate her.

ObComputerSecurityStuff: this turns out to be a recurring mathematical pattern that pops up all over in computer security.  If you have 10,000 IDS red-flags warning of catastrophe and catastrophe never happens, that?s a pretty bad system? but if in post-incident analysis you discover, ?hey, IDS correctly reported this when it was happening,? Management will ask you some really harsh questions about why you didn?t pay attention to the warnings.  I think this is how IDSes manage to get sold: too often we look at them from a postmortem, rather than premortem, perspective.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3634 bytes
Desc: not available
URL: </pipermail/attachments/20150107/989c69e0/attachment.bin>

From John at enigmail.net  Wed Jan  7 18:18:11 2015
From: John at enigmail.net (John Clizbe)
Date: Wed, 07 Jan 2015 11:18:11 -0600
Subject: Thoughts on Keybase
In-Reply-To: <54AD4C28.2020903@enigmail.net>
References: <548F2B16.1030703@sixdemonbag.org> <54AD4C28.2020903@enigmail.net>
Message-ID: <54AD6A53.4080603@enigmail.net>

John Clizbe wrote:
> Does look interesting. Anyone have and willing to share an invite?
> 
> Reply off-list please.
> 

Invite received. Thanks to those who offered.

-J

-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"


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

From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Jan  8 10:43:29 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 8 Jan 2015 09:43:29 +0000
Subject: Thoughts on Keybase
In-Reply-To: <F4A4690A-84E9-4A09-B32D-7AFC98339BC1@sixdemonbag.org>
References: <548F2B16.1030703@sixdemonbag.org>
 <1291169981.20150105024400@my_localhost>
 <D14D23FF-4273-4FBE-999A-3527A03DD8C8@sixdemonbag.org>
 <1709158100.20150105224954@my_localhost> <54AB38E7.8070804@sixdemonbag.org>
 <20150106141420.GB27281@IUPUI.Edu> <1375258041.20150107020138@my_localhost>
 <9A642D95-C400-442F-B952-639B7F848067@sixdemonbag.org>
 <10810727989.20150107040506@my_localhost>
 <F4A4690A-84E9-4A09-B32D-7AFC98339BC1@sixdemonbag.org>
Message-ID: <346726954.20150108094329@my_localhost>

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

Hi


On Wednesday 7 January 2015 at 4:14:53 PM, in
<mid:F4A4690A-84E9-4A09-B32D-7AFC98339BC1 at sixdemonbag.org>, Robert J.
Hansen wrote:


> One more thing ? remember that probabilities are
> tricksy things.  They vary wildly depending on how one
> looks at the problem.

A lot of statistical analysis throws up pretty non-intuitive answers.
Like how few random people you need in a room before there are
probably two who share a birthday.



> Let?s say there are 10,000 threats of murder that are
> made, and only 10 murders.  If we assume that only ten
> of those 10,000 threats was connected to a murder, the
> probability of any given threat being connected to a
> murder is vanishingly small ? one in a thousand, or
> 0.1%.  Starting from the fact there was a threat, it
> would be foolish to conclude the speaker intended on
> murdering someone.

That is how I was looking at it.



> However, if we look at the murders, we discover that
> 100% of them are connected to threats.

100% seems unlikely, but it is probably pretty high.



> If you start
> from a murder, it would be pretty wise to start looking
> into who threatened the person.

Fair enough.



> If the only fact you have is ?Alice threatened Bob?s
> life,? then yes, that?s pretty poor evidence on which
> to investigate Alice for Bob?s death.  But if the facts
> you have are ?Alice threatened Bob?s life and Bob was
> killed under suspicious circumstances,? then yes,
> that?s actually pretty good evidence on which to
> investigate her.

Obviously, without Bob's suspicious death there would be no reason to
investigate Alice. And there could be hundreds of people who recently
uttered a throwaway threat at Bob.



> ObComputerSecurityStuff: this turns out to be a recurring
> mathematical pattern that pops up all over in computer security.  If
> you have 10,000 IDS red-flags warning of catastrophe and catastrophe
> never happens, that?s a pretty bad system? but if in post-incident
> analysis you discover, ?hey, IDS correctly reported this when it was
> happening,? Management will ask you some really harsh questions
> about why you didn?t pay attention to the warnings.

A warning system with many false positives is no warning system at
all.

- --
Best regards

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

Colourless green ideas sleep furiously (Noam Chomsky)
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUrlFPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw4esH/2AjMDHVSPFMih02h6r4IisO
a/cTJG3LPnMMrr88hDlJ902PP/vhciEx4qI3Focvq4Q4jS/jQ4kuJKrM12fRVZOm
WiSL3gsvlOzGIC3zuOOpRa08WiqEPd82nttbi8e60S65eBKBYCNDxRtUifidwK9w
+Nmn0Fb5C53W7qI/vfdq0wpIdxMsA/WZAJQCXkSU4Kc0kEfnsiegOdaadHDe8YJB
j9ZbpidErk/h7wVAkNDg/0nlhxLGHeBi90Fd8J4oqOtBlGFElkYa2VNCspkXnWP7
FpK/MkvS+GjsJYIa+mBOLYxeanLHqJvibU9/HyzUlMu2hFM2Dix9pg2qL+J4DB2I
vgQBFgoAZgUCVK5RVF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45HR0AQBpXYQvhfBZYtAaSTueWissr/r0
ieadHCWdlVz4eAOs+QEAuXQG+p7qeyrJ32faHphTV7G2Pv/EPXG2q/jsgdp15g4=
=Gi3x
-----END PGP SIGNATURE-----



From gnupgpacker at on.yourweb.de  Thu Jan  8 16:59:24 2015
From: gnupgpacker at on.yourweb.de (gnupgpacker)
Date: Thu, 8 Jan 2015 16:59:24 +0100
Subject: Import pubkey to Thunderbird/Enigmail/Gpg4Win
Message-ID: <000f01d02b5c$12c5e890$3851b9b0$@on.yourweb.de>

Hello,
if importing a public gpg rsa key to current Thunderbird/Enigmail/Gpg4Win on
Win7-64, there is an issue with German Umlaute, pls refer to attached
screenshot.

Exported key has been created by GPG-1.4.18/Win7-64, importing Enigmail
works with GPG4Win (GPG-2.0.26)/Win7-64.

Everything (signing, encryption...) works as expected, so maybe it is a
display error only!?
Bugfix possible?

Thanks and best regards, Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import.jpg
Type: image/jpeg
Size: 21911 bytes
Desc: not available
URL: </pipermail/attachments/20150108/44417d1b/attachment-0001.jpg>

From patrick at enigmail.net  Thu Jan  8 17:52:15 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 08 Jan 2015 17:52:15 +0100
Subject: Import pubkey to Thunderbird/Enigmail/Gpg4Win
In-Reply-To: <000f01d02b5c$12c5e890$3851b9b0$__28293.0434369066$1420732980$gmane$org@on.yourweb.de>
References: <000f01d02b5c$12c5e890$3851b9b0$__28293.0434369066$1420732980$gmane$org@on.yourweb.de>
Message-ID: <54AEB5BF.2040900@enigmail.net>

On 08.01.15 16:59, gnupgpacker wrote:
> Hello,
> if importing a public gpg rsa key to current Thunderbird/Enigmail/Gpg4Win on
> Win7-64, there is an issue with German Umlaute, pls refer to attached
> screenshot.
> 
> Exported key has been created by GPG-1.4.18/Win7-64, importing Enigmail
> works with GPG4Win (GPG-2.0.26)/Win7-64.
> 
> Everything (signing, encryption...) works as expected, so maybe it is a
> display error only!?
> Bugfix possible?

That's a problem with Enigmail, not GnuPG.

It's only a display problem; if you go to the key manager, you should
see the Umlauts correctly. And no, this can't be properly fixed.

-Patrick



From Rob.Fries at ascensus.com  Fri Jan  9 21:24:39 2015
From: Rob.Fries at ascensus.com (Rob Fries)
Date: Fri, 9 Jan 2015 20:24:39 +0000
Subject: gpg-connect-agent querying max-cache-ttl
Message-ID: <effa331a9eb84a469bfe9bdb9f41b3fe@RDRE1-PEXCH02.rsd.crumprsd.com>

Hi,

I have done a lot of searching and have not found much to cover my use case. Please direct me to any previous discussions if there are any!

Basically, I have stand alone system where files are automatically encrypted and decrypted for processing. This is currently setup using quintuple-agent, but we want to use something which is maintained.
I am looking to use gpg-agent to store the passphrase, which is entered using gpg-preset-passphrase. This all works perfectly other than max-cache-ttl removing the passphrase.

I am looking for a way to query the max-cache-ttl  time for gpg-agent so I can have an alert as this time approaches.
This will give me a heads up before I need to enter a passphrase with gpg-preset-passphrase so it can be planned for an optimal time.

I know there are ways to query some information from gpg-agent with gpg-connect-agent, but I have not found any central documentation on how to query this.

Let me know if there are any questions and thanks!
-Rob

CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150109/4197295c/attachment.html>

From patrick at enigmail.net  Sat Jan 10 11:26:05 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sat, 10 Jan 2015 11:26:05 +0100
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
Message-ID: <54B0FE3D.6060805@enigmail.net>

On 09.01.15 21:24, Rob Fries wrote:
> Hi,
> 
>  
> 
> I have done a lot of searching and have not found much to cover my use
> case. Please direct me to any previous discussions if there are any!
> 
>  
> 
> Basically, I have stand alone system where files are automatically
> encrypted and decrypted for processing. This is currently setup using
> quintuple-agent, but we want to use something which is maintained.
> 
> I am looking to use gpg-agent to store the passphrase, which is entered
> using gpg-preset-passphrase. This all works perfectly other than
> max-cache-ttl removing the passphrase.
> 
>  
> 
> I am looking for a way to query the max-cache-ttl  time for gpg-agent so
> I can have an alert as this time approaches.
> 
> This will give me a heads up before I need to enter a passphrase with
> gpg-preset-passphrase so it can be planned for an optimal time.
> 
>  
> 
> I know there are ways to query some information from gpg-agent with
> gpg-connect-agent, but I have not found any central documentation on how
> to query this.

You should use gpgconf for this.

https://www.gnupg.org/documentation/manuals/gnupg/gpgconf.html

-Patrick



From patrick-mailinglists at whonix.org  Mon Jan 12 03:19:18 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Mon, 12 Jan 2015 02:19:18 +0000
Subject: How to detect extraneous content in clearsigned (--clearsign) files?
Message-ID: <54B32F26.3030007@whonix.org>

Hi!

Suppose a file has been `--clearsign`ed. Then an adversary pretended or
appended extraneous content.

How can such a situation be detected? Any gpg built in way or would one
have to use a third party solution or invent one?

Perhaps code talks more:
https://gist.github.com/adrelanos/defdf9d693c2726514fd

Cheers,
Patrick


From wk at gnupg.org  Mon Jan 12 11:58:24 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 12 Jan 2015 11:58:24 +0100
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <54B32F26.3030007@whonix.org> (Patrick Schleizer's message of
 "Mon, 12 Jan 2015 02:19:18 +0000")
References: <54B32F26.3030007@whonix.org>
Message-ID: <87sifggt9r.fsf@vigenere.g10code.de>

On Mon, 12 Jan 2015 03:19, patrick-mailinglists at whonix.org said:

> Suppose a file has been `--clearsign`ed. Then an adversary pretended or
> appended extraneous content.

That is what the signature is all about ;-).  Use

  gpg --verify --output OUT SIGNEDDATA

to write the _verified_ content of the file SIGNEDDATA to the file OUT.
You also need to check the verification status of course.


Shalom-Salam,

   Werner

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



From bernhard at intevation.de  Mon Jan 12 15:09:13 2015
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 12 Jan 2015 15:09:13 +0100
Subject: Key generation, subkeys and improved documentation
In-Reply-To: <456250107.20150107023055@my_localhost>
References: <A063AAC5-6C36-4A43-851A-53E890D0A36E@mykolab.com>
 <4F6CE41D-0A52-42B8-A413-159F3505E204@yahoo.com>
 <456250107.20150107023055@my_localhost>
Message-ID: <201501121509.14876.bernhard@intevation.de>

On Wednesday 07 January 2015 at 03:30:55, MFPA wrote:
> > But I have seen some of the more
> > paranoid privacy folks doing 4096 key pairs.
>
> I'm sure I have even seen discussions about 16384-bit. I seem to
> recall somebody posting where the code would need changing to allow
> this, but cautioning such a key would be unusable by virtually
> everybody else.

Pointers to the FAQ and discussions:
  https://wiki.gnupg.org/LargeKeys


-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150112/ffe8c316/attachment.sig>

From marcio.barbado at gmail.com  Mon Jan 12 16:17:50 2015
From: marcio.barbado at gmail.com (Marcio Barbado, Jr.)
Date: Mon, 12 Jan 2015 13:17:50 -0200
Subject: The praise of GnuPG @31C3
In-Reply-To: <54A41C5B.3050507@josuttis.de>
References: <54A41C5B.3050507@josuttis.de>
Message-ID: <CA+0jWE1XJ5nU7nKVcz69bnUyPm3syM_HQ3gz=hJwD9bzWmzZWQ@mail.gmail.com>

Hi Nicolai,


> So, please watch it completely at:
>> http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video:43:10


It would've been better not to induce to scripts. Video file here:


http://c3media.vsos.ethz.ch/congress/2014/h264-hd/31c3-6258-en-Reconstructing_narratives_hd.mp4


thanks for sharing it, anyway. Only watched it now.

Sadly, noticeable is the fact that many of us are concerned with
hiding information, instead of exploring limits of math. There's the
power of fear. Funding wars since ever.


Regards,



Marcio Barbado, Jr.



On Wed, Dec 31, 2014 at 1:55 PM, Nicolai Josuttis <nico at josuttis.de> wrote:
> Disclaimer:
> Sorry guys, I first wrote these emails as part of another thread.
> (Not enough sleep over the last days of 31C3 ...)
> But because IMO this is something important for this list,
> please allow me to redistribute it as separate thread, again.
>
>
> For those who didn't have time to see it yet,
> there was an important talk at 31C3
> about the social and technical status and consequences of
> encryption by Jacob Applebaum and Laura Poitras.
> As a side effect it covers GnuPG significantly.
>
> So, please watch it completely at:
>> http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video:43:10
>
> For those not having enough time let me point out and quote some content
> from the talk with the timepoints in the video
> to be able to see/hear/double-check it yourself.
> I also added sometime some add-ons in [...] to understand the context.
> All quotes except the last are by Jacob Appelbaum.
>
> [26:33]:
>  PPTP, ipsec, SSL, TLS, SSH are broken by NSA
>
> [31:23]:
>  we found that they [NSA] consistently break various different
>  types of encryption
>
> [33:40]:
>  we want to show one PRISM record
>  (the record contains:
>   "no decrypt available for this OTR encrypted message")
>
> [34:22]:
>  basically everyone that uses cryptography is broken
>  except for two things: OTR and PGP ([36:06])
>
> [37:08]:
>  the sad part is that not everyone is using it
>  but the good news is that when you use it it appears to work
>  (when you verified the fingerprint for example)
>
> [37:38]:
>  they [NSA] themselves find that they are blinded
>  when you use properly implemented cryptography.
>
> [37:46]:
>  GnuPG and OTR are two things that actually stop the spies
>  from spying on you with PRISM
>
> [40:11]:
>  if you use redphone and signal,
>  if you use something like TOR and GnuPG
>  with a properly sized key ...
>  if you use OTR
>  if you use jabber.ccc.de ...
>  if you use encontered together
>  you blind them
>
> [42:41]:
>  Werner Koch [GnuPG], ... could you stand up?
>  ...
>  Ian Goldberg [OTR], ...
>  ...
>  Christine Corbett [Signal],
>  stand up and keep standing!
>  ...
>  These people without even knowing it and without
>  even trying they beat them!
>
> 43:55 :
>  Laura Poitras:
>  Last night I screened my film Citizenfour here ...
>  Somebody ask what an they do to support the work that Snowden has done
>  and the Journalists.
>  ...
>  Everybody should fund the work that you guys do ...
>  because literally, my work would not be possible without
>  the work that you do.
>  So, I would like it if everybody in this room when they leave here
>  in the next week to reach out and fund these projects
>  because without these projects the journalism
>  that Glenn [Greenwald] and I and Jake have done
>  would literally not be possible
>
>
> --
> Nicolai M. Josuttis
> www.josuttis.de
> PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From s7r at sky-ip.org  Mon Jan 12 16:13:48 2015
From: s7r at sky-ip.org (s7r)
Date: Mon, 12 Jan 2015 17:13:48 +0200
Subject: different passwords for subkeys of the same masterkey
Message-ID: <54B3E4AC.80202@sky-ip.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Is it possible to have one masterkey with two subkeys (sbind), one for
encrypt only and one for sign only, and each of them to have different
passphrases?

Additionally, how can I select in enigmail which userID I want to sign
when signing a key with multiple UserIDs? I do not want to sign the
primary one. Enigmail just offers me the ability to 'sign key',
nothing said about UserID, just lets me select either normal signature
or local signature not exportable.

Thanks in advance.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUs+SsAAoJEIN/pSyBJlsRCtMH/jJeQytEZIi7z9TeNhC0v2L/
cjVAmYxtE7NhymoTC5DonOJCCZLOUYNcYT8Y9UQO0SOiIcjm32ca2fgqI2Mb4570
NrmNAnWtqS8LKzEOupNYl3A/23CQSCgiGNJOJUq8tOZ3kRItxzLhW4GPVRIBYDlt
6uvA2ibfs0W5R/2gLJgQ+FKIDNwuh68EEzEvRBjE1OdiVhg0QUBlk+AZV0M+xkOV
xQshCJulF7JdOzA8DOgwXe5VV2LVwOU8bCPYszxt0aK5sUglb3oyjgnUbVG6Q2W5
a0rf75lvgNGpiCKpnMKprIRPVXiJlbxjXyfaZv0bafmakQzueVUQODZUWoan25o=
=u5Nr
-----END PGP SIGNATURE-----


From Rob.Fries at ascensus.com  Mon Jan 12 18:45:30 2015
From: Rob.Fries at ascensus.com (Rob Fries)
Date: Mon, 12 Jan 2015 17:45:30 +0000
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <54B0FE3D.6060805@enigmail.net>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B0FE3D.6060805@enigmail.net>
Message-ID: <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>

After some off list communication, I wanted to circle back here with my findings.

To recap, and perhaps more clearly:

I am attempting to query from gpg-agent the time remaining before a passphrase expires for a key due to the max-cache-ttl setting.  I believe the proper way to do this would be through gpg-connect-agent.


I found the gpg-agent Assuan protocol here:

https://www.gnupg.org/documentation/manuals/gnupg/Agent-Protocol.html

There appears to be no way to get the remaining time for before a passphrase expires at this time.

CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems.

From patrick-mailinglists at whonix.org  Mon Jan 12 19:44:06 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Mon, 12 Jan 2015 18:44:06 +0000
Subject: How to sign the name of the name as well, not just the file?
Message-ID: <54B415F6.60306@whonix.org>

Hi!

When using "gpg --armor --detach-sign some-file-version-c" a file:
some-file-version-c.asc will be created.

But an adversary position to arbitrarily change file names on a mirror
or so could rename it to some-file-version-d and some-file-version-d.asc.

That could trick the verifier into believing having received a more
recent version than expected. The adversary could use this to mount
rollback [1] (downgrade) or indefinite freeze [2] attacks.

Is there a way to make gnupg sign the name of the file as well? So
verification would fail if file names were renamed?

I know, one could create a sha512sum (or so) file that contains the hash
and the name of the file, then gpg sign that file. But I find that
method more complex, complicated, cumbersome. Is there any easier and/or
gpg built in way?

Cheers,
Patrick

[1] [2] Defined as per TUF (The Update Framework) - Attacks and
Weaknesses - Threat Model:
https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
http://www.webcitation.org/6F7Io2ncN


From rjh at sixdemonbag.org  Mon Jan 12 19:46:42 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jan 2015 13:46:42 -0500
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
Message-ID: <54B41692.6060301@sixdemonbag.org>

On a Fedora 20 box running GnuPG 2.0.20-something (.25?), I made a 
backup of several sensitive files -- including my keyrings -- and used 
GnuPG to symmetrically encrypt the archive.  I can decrypt this archive 
on every 2.0.whatever installation I have, but my one GnuPG 2.1.1 
installation, on a Windows 7 x64 box, can't decrypt it.

C:\Users\rjh\Desktop>gpg -vvvv backup.tar.xz.gpg
gpg: using character set 'CP437'
# off=0 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid B8A6B74C001892C2
         data: [2044 bits]
         data: [2047 bits]
gpg: public key is 001892C2
# off=529 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid E5B12DCFA1AC6FC0
         data: [2047 bits]
gpg: public key is A1AC6FC0
# off=800 ctb=8c tag=3 hlen=2 plen=46
:symkey enc packet: version 4, cipher 2, s2k 3, hash 2, seskey 256 bits
         salt 018490B8887579F9, count 65536 (96)
gpg: 3DES encrypted session key
# off=848 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
         length: unknown
         mdc_method: 2
gpg: encrypted with 1 passphrase
gpg: encrypted with RSA key, ID A1AC6FC0
gpg: encrypted with ELG key, ID 001892C2
gpg: encrypted with unknown algorithm 64
gpg: decryption failed: Invalid cipher algorithm



... What's going on here?  It seems like an alarming regression if GnuPG 
2.1.1 is unable to decrypt symmetrically-encrypted files made with GnuPG 
2.0.x.


From patrick-mailinglists at whonix.org  Mon Jan 12 19:52:53 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Mon, 12 Jan 2015 18:52:53 +0000
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <87sifggt9r.fsf@vigenere.g10code.de>
References: <54B32F26.3030007@whonix.org> <87sifggt9r.fsf@vigenere.g10code.de>
Message-ID: <54B41805.9010007@whonix.org>

Werner Koch:
> On Mon, 12 Jan 2015 03:19, patrick-mailinglists at whonix.org said:
> 
>> Suppose a file has been `--clearsign`ed. Then an adversary pretended or
>> appended extraneous content.
> 
> That is what the signature is all about ;-).  Use
> 
>   gpg --verify --output OUT SIGNEDDATA
> 
> to write the _verified_ content of the file SIGNEDDATA to the file OUT.
> You also need to check the verification status of course.

Tried your syntax. And also tried this one:

gpg --output ./out --verify ./sha512sums.asc

Never created an "out" file for me.

However, what works for me is this:

gpg --output ./out --verify ./sha512sums.asc

When it exits 0, then this approach is sound, sane and fine?

-----

Is there a way to detect, that a file looks like this:

##################################
b4e5ac6ceb9812dacf1f5db26c65b3329da031b0ef5a6107e38e2d92b91ae5f6daff6e6774fbb0ab5bb4148ae4f71b4511595149876f181c40fba5ec0e20a399
test
##################################

vs a file looking like this:

##################################
prepended content
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

b4e5ac6ceb9812dacf1f5db26c65b3329da031b0ef5a6107e38e2d92b91ae5f6daff6e6774fbb0ab5bb4148ae4f71b4511595149876f181c40fba5ec0e20a399
test
-----BEGIN PGP SIGNATURE-----

...
-----END PGP SIGNATURE-----
appended content
##################################

Any way to distinguish both states?

Cheers,
Patrick


From rjh at sixdemonbag.org  Mon Jan 12 20:14:36 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jan 2015 14:14:36 -0500
Subject: How to sign the name of the name as well, not just the file?
In-Reply-To: <54B415F6.60306@whonix.org>
References: <54B415F6.60306@whonix.org>
Message-ID: <54B41D1C.9050308@sixdemonbag.org>

> Is there a way to make gnupg sign the name of the file as well? So
> verification would fail if file names were renamed?

Drop version 1.7 of your 'foo' program into a directory called
'foo-1.7'.  Now:

tar cf foo-1.7 foo-1.7.tar && gpg --sign foo-1.7.tar

Congratulations.  Even if someone changes "foo-1.7.tar.xz" to
"foo-1.6.tar.xz", you can trivially look inside the archive and see it's
foo-1.7.  The contents are signed and you have some way of being able to
verify the file version hasn't been tampered with by comparing the
version number inside the signed tarfile with the version number on the
tarfile.

> I know, one could create a sha512sum (or so) file that contains the
> hash and the name of the file, then gpg sign that file. But I find
> that method more complex, complicated, cumbersome. Is there any
> easier and/or gpg built in way?

What you're talking about is called 'signing a manifest' and it's pretty
much the only game in town.  That technique is in use in a lot of
different places and it's a standard tool.  Done right, it's simple and
easy -- I use a Python script to do this task automagically.


From s.murthy at mykolab.com  Mon Jan 12 21:17:38 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Mon, 12 Jan 2015 20:17:38 +0000
Subject: A passphrase for all keyrings
Message-ID: <0BB8CA76-92A6-473C-870B-755D50134334@mykolab.com>

Hi

At the moment one has to remember a passphrase for each keypair,
which becomes more difficult as you have several emails each associated
with different key pairs.  Would it be possible to have one passphrase for
the whole bunch of keypairs?

Sandeep Murthy
s.murthy at mykolab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150112/d6b59c6e/attachment.sig>

From peter at digitalbrains.com  Mon Jan 12 21:24:49 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 12 Jan 2015 21:24:49 +0100
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B0FE3D.6060805@enigmail.net>
 <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>
Message-ID: <54B42D91.1070407@digitalbrains.com>

On 12/01/15 18:45, Rob Fries wrote:
> I believe the proper way to do this would be through gpg-connect-agent.

You're mistaken; it's as Patrick said through gpgconf, the program to
programmatically query the configuration.

$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 10

But note:

> If  it is empty, then the option is not explicitly set in the current
> configuration, and the default  applies  (if  any).

The value is field 10, the default is field 8. So if the above command returns a
blank string, try:

$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 8

Obviously you could do this in one go, doing your own parsing rather than
calling grep and cut, etcetera.

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 patrick-mailinglists at whonix.org  Mon Jan 12 21:46:25 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Mon, 12 Jan 2015 20:46:25 +0000
Subject: How to sign the name of the name as well, not just the file?
In-Reply-To: <54B41D1C.9050308@sixdemonbag.org>
References: <54B415F6.60306@whonix.org> <54B41D1C.9050308@sixdemonbag.org>
Message-ID: <54B432A1.6060803@whonix.org>

Added Hauke, because he seems interested in OpenPGP notations [1] that I
will talk about below.

Robert J. Hansen:
>> Is there a way to make gnupg sign the name of the file as well? So
>> verification would fail if file names were renamed?
> 
> Drop version 1.7 of your 'foo' program into a directory called
> 'foo-1.7'.  Now:
> 
> tar cf foo-1.7 foo-1.7.tar && gpg --sign foo-1.7.tar
> 
> Congratulations.  Even if someone changes "foo-1.7.tar.xz" to
> "foo-1.6.tar.xz", you can trivially look inside the archive and see it's
> foo-1.7.  The contents are signed and you have some way of being able to
> verify the file version hasn't been tampered with by comparing the
> version number inside the signed tarfile with the version number on the
> tarfile.

Hm. That's one way. Thanks for taking time answering me. Respectfully, I
must say, sounds still non-ideal. Doesn't get me too excited.

Software shipped by the project I am working on are ova files. Virtual
Box image files. Which are already compressed. Packing them into just
another tar archive would only add up build time and complicate steps a
user has to do. That is, unpack, figure out that there is no some
seemingly useless sub folder. And the naming of that sub folder could
still be overlooked.

>> I know, one could create a sha512sum (or so) file that contains the
>> hash and the name of the file, then gpg sign that file. But I find
>> that method more complex, complicated, cumbersome. Is there any
>> easier and/or gpg built in way?
> 
> What you're talking about is called 'signing a manifest' and it's pretty
> much the only game in town.  That technique is in use in a lot of
> different places and it's a standard tool.  Done right, it's simple and
> easy -- I use a Python script to do this task automagically.

You mean as in creating something like a software updater system?

-----

What about OpenPGP notations?

gpg --armor --set-notation file at name="x" --detach-sign x

gpg --armor --verify-options show-notations --verify x.asc

That would be secure? Given that, users are available of notations and
use the unpopular "--verify-options show-notations". Probably few would
know. But perhaps we can train at least a few users to check.

Any suggestion for a better OpenPGP notation name than 'file at name="..."'?

Couldn't that be turned into a good feature request for gnupg?

1) To have a standardized OpenPGP notation that includes the file name.

2) When another "check file name" OpenPGP notation is set, let gpg say
"bad signature" if the file name has been tampered with?

Cheers,
Patrick

[1] http://www.openpgp-notations.org/



From Rob.Fries at ascensus.com  Mon Jan 12 21:48:59 2015
From: Rob.Fries at ascensus.com (Rob Fries)
Date: Mon, 12 Jan 2015 20:48:59 +0000
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <54B42D91.1070407@digitalbrains.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B0FE3D.6060805@enigmail.net>
 <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B42D91.1070407@digitalbrains.com>
Message-ID: <b5f1e899e0a4434daef13a4471cba9c9@RDRE1-PEXCH02.rsd.crumprsd.com>

Peter,

Thanks for the reply, but this is what Patrick and I discussed of ticket.

> You're mistaken; it's as Patrick said through gpgconf, the program to programmatically query the configuration.

But I am not looking for the value in the "configuration", I am looking for the "time remaining" until a passphrase expires.

If I set my max-cache-ttl to 5 days:

$ echo $((60*60*24*5))
432000

I can retrieve that value here:

$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 8,10
7200:432000

Then I set my passphrase:

$ gpg-preset-passphrase -cP <PASSPHRASE> $key

I am looking for the "time remaining" until I am required to re-enter that passphrase. Gpgconf will only give me what is configured as the max:

$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 8,10
7200:432000
$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 8,10
7200:432000
$ gpgconf --list-options gpg-agent|grep ^max-cache-ttl: |cut -d: -f 8,10
7200:432000

In 5 days, I am looking for that value to be 1 day or 86400 seconds so that I can trigger an alert.

I hope that clarifies everything.

Thanks!
-Rob

CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems.

From rjh at sixdemonbag.org  Mon Jan 12 21:50:42 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jan 2015 15:50:42 -0500
Subject: A passphrase for all keyrings
In-Reply-To: <0BB8CA76-92A6-473C-870B-755D50134334@mykolab.com>
References: <0BB8CA76-92A6-473C-870B-755D50134334@mykolab.com>
Message-ID: <54B433A2.7070302@sixdemonbag.org>

> At the moment one has to remember a passphrase for each keypair, 
> which becomes more difficult as you have several emails each
> associated with different key pairs.  Would it be possible to have
> one passphrase for the whole bunch of keypairs?

Sure, just use the same passphrase for each certificate.  There's some
risk here, in that if one passphrase gets compromised all your
certificates get jeopardized, but if you're comfortable accepting that
risk then go for it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150112/41e37839/attachment.bin>

From peter at digitalbrains.com  Mon Jan 12 22:00:31 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 12 Jan 2015 22:00:31 +0100
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <b5f1e899e0a4434daef13a4471cba9c9@RDRE1-PEXCH02.rsd.crumprsd.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B0FE3D.6060805@enigmail.net>
 <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B42D91.1070407@digitalbrains.com>
 <b5f1e899e0a4434daef13a4471cba9c9@RDRE1-PEXCH02.rsd.crumprsd.com>
Message-ID: <54B435EF.1000004@digitalbrains.com>

On 12/01/15 21:48, Rob Fries wrote:
> But I am not looking for the value in the "configuration", I am looking for
> the "time remaining" until a passphrase expires.

Oh ah!

Have you considered these two options:

1) gpgconf says the ttl is a 32-bit unsigned number. Have you tried entering the
value 4294967295 and making a mental note to rethink that strategy when your
system reaches an uptime of more than 136 years? (I got the impression you
didn't have ttl issues with your current solution, so I inferred this might be
because it doesn't expire).

2) You say you preset the passphrase with gpg-preset-passphrase. Have you
considered writing a wrapper script that does nothing but call
gpg-preset-passphrase and write a timestamp in some file? The actual ttl can
then be computed from the timestamp and the gpgconf output.

This might help you out without needing a feature that indeed isn't present AFAIK.

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 Rob.Fries at ascensus.com  Mon Jan 12 22:26:56 2015
From: Rob.Fries at ascensus.com (Rob Fries)
Date: Mon, 12 Jan 2015 21:26:56 +0000
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <54B435EF.1000004@digitalbrains.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe__18782.0325293162$1420838022$gmane$org@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B0FE3D.6060805@enigmail.net>
 <533cb724e2b94b03a59c35d6726b9e7f@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B42D91.1070407@digitalbrains.com>
 <b5f1e899e0a4434daef13a4471cba9c9@RDRE1-PEXCH02.rsd.crumprsd.com>
 <54B435EF.1000004@digitalbrains.com>
Message-ID: <5006595eaf714945a7f4642fd9121d6f@RDRE1-PEXCH02.rsd.crumprsd.com>

> Have you considered these two options:

> 1) gpgconf says the ttl is a 32-bit unsigned number. Have you tried entering the value 4294967295 and making a mental note to rethink that strategy when your system reaches an uptime of more than 136 years? (I got the impression you didn't have ttl issues with your current solution, so I inferred this might be because it doesn't expire).

You are correct, ttl is not a current issue, and a high setting is something we are considering . ( thanks for the max value! :) ) 

> 2) You say you preset the passphrase with gpg-preset-passphrase. Have you considered writing a wrapper script that does nothing but call gpg-preset-passphrase and write a timestamp in some file? The actual ttl can then be computed from the timestamp and the gpgconf output.

Hmm... I hadn't considered my own time stamp file exactly, but that is another solution we could certainly use. We already have a wrapper, so it would be simple to add.

> This might help you out without needing a feature that indeed isn't present AFAIK.

Thanks!
-Rob

CONFIDENTIALITY NOTICE: This message, including attachments, is intended to be viewed only by the addressee. It may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No confidentiality or privilege is lost by any transmission error. This message may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose except as permitted by law. Any dissemination, distribution or copying of this message is strictly prohibited without our prior written permission. If you are not an intended recipient, or if you have received this message in error, please notify us immediately by return e-mail and permanently remove the original message and any copies from your computer and all back-up systems.

From rjh at sixdemonbag.org  Mon Jan 12 22:51:57 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jan 2015 16:51:57 -0500
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
In-Reply-To: <54B41692.6060301@sixdemonbag.org>
References: <54B41692.6060301@sixdemonbag.org>
Message-ID: <54B441FD.4020604@sixdemonbag.org>

> On a Fedora 20 box running GnuPG 2.0.20-something (.25?), I made a
> backup of several sensitive files -- including my keyrings -- and used
> GnuPG to symmetrically encrypt the archive.  I can decrypt this archive
> on every 2.0.whatever installation I have, but my one GnuPG 2.1.1
> installation, on a Windows 7 x64 box, can't decrypt it.

Update: 2.1.1 on OS X (using Patrick Brunschwig's build) works fine.

The major difference between the two installations is (a) one is a
Windows box and one is an OS X box, and (b) OS X has my private keys on
it, and on Windows I was relying on using the symmetric passphrase to
decrypt it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150112/d568494d/attachment-0001.bin>

From dougb at dougbarton.email  Mon Jan 12 22:51:48 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Mon, 12 Jan 2015 13:51:48 -0800
Subject: How to sign the name of the name as well, not just the file?
In-Reply-To: <54B415F6.60306@whonix.org>
References: <54B415F6.60306@whonix.org>
Message-ID: <54B441F4.2020703@dougbarton.email>

On 1/12/15 10:44 AM, Patrick Schleizer wrote:
> When using "gpg --armor --detach-sign some-file-version-c" a file:
> some-file-version-c.asc will be created.
>
> But an adversary position to arbitrarily change file names on a mirror
> or so could rename it to some-file-version-d and some-file-version-d.asc.

Robert already gave you a method to deal with non-text items. If your 
example is a simple text file, put the name of the file in the file as 
part of your text: "This is version some-file-version-c"

hope this helps,

Doug



From rjh at sixdemonbag.org  Mon Jan 12 22:58:55 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 12 Jan 2015 16:58:55 -0500
Subject: How to sign the name of the name as well, not just the file?
In-Reply-To: <54B441F4.2020703@dougbarton.email>
References: <54B415F6.60306@whonix.org> <54B441F4.2020703@dougbarton.email>
Message-ID: <54B4439F.6070003@sixdemonbag.org>

> Robert already gave you a method to deal with non-text items.

Yeah, except that I think I screwed up the order of arguments to tar.
Been using UNIX for over 20 years and I still do that from time to time.

"tar cf foo-1.7 foo-1.7.tar" should be "tar cf foo-1.7.tar foo-1.7".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150112/64076125/attachment.bin>

From gnupg at lists.grepular.com  Mon Jan 12 21:51:04 2015
From: gnupg at lists.grepular.com (Mike Cardwell)
Date: Mon, 12 Jan 2015 20:51:04 +0000
Subject: Vanity Keys
Message-ID: <20150112205104.GA12857@glue.grepular.com>

Just thought I'd make you aware of this horrendous website, which is charging
people for pre-generated GnuPG key pairs with "vanity" key ids:

  https://vanitykeys.io/

I read about it earlier today on the following thread, where the author of the
website has been talking about it:

  https://news.ycombinator.com/item?id=8873182

Apparently some of the funds will be donated to the GnuPG project. I suspect
he hasn't been in contact, and I imagine the funds would not be welcome?

-- 
Mike Cardwell  https://grepular.com https://emailprivacytester.com
OpenPGP Key    35BC AF1D 3AA2 1F84 3DC3   B0CF 70A5 F512 0018 461F
XMPP OTR Key   8924 B06A 7917 AAF3 DBB1   BF1B 295C 3C78 3EF1 46B4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 598 bytes
Desc: Digital signature
URL: </pipermail/attachments/20150112/c76c31f6/attachment.sig>

From vedaal at nym.hush.com  Mon Jan 12 23:09:29 2015
From: vedaal at nym.hush.com (vedaal at nym.hush.com)
Date: Mon, 12 Jan 2015 17:09:29 -0500
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <54B41805.9010007@whonix.org>
References: <54B32F26.3030007@whonix.org> <87sifggt9r.fsf@vigenere.g10code.de>
 <54B41805.9010007@whonix.org> 
Message-ID: <20150112220929.E540CC035E@smtp.hushmail.com>

On 1/12/2015 at 1:50 PM, "Patrick Schleizer" <patrick-mailinglists at whonix.org> wrote:

>>   gpg --verify --output OUT SIGNEDDATA
-----
>gpg --output ./out --verify ./sha512sums.asc
>
>When it exits 0, then this approach is sound, sane and fine?
-----

There is a way of addition to clearsigned messages that is not detectable:

Adding 'spaces' at the end of the line of visible characters.


Here is a clearsigned message without any spaces added:

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

This
Is
Just
a
Test
-----BEGIN PGP SIGNATURE-----
Comment: Fingerprint:   C982 4216 3053 B6F3 62F2  7DC0 506F 4FA1 D35F B186
Comment: Key ID:  0xD35FB186
Comment: nothing added to cleartext

iQIcBAEBCAAGBQJUtCfmAAoJEFBvT6HTX7GGJlUP+QGHkTWBRvXUsfsVi5QyqJji
WKt5KkJIu+cv5dKVwJuWHVnhlCrdpqvVToofgk+oVJQp2KrnkesxkdwbPi87oJO9
nSc/4BCQedvYqa9nZ54YPGdRse9yttfzpwLtlbCWPqaMHN5trOwmBervAEW7GhCR
kmUeM7ZlPAj9QUVS8TKzWXlMu63YpYwrRGt1EXevbTaMcUWOOG9+azQy5nYw04oq
yuDDhdzV6MqL6bgxcnH4Psw5ykB59nlAEHjAeTVAObR6SzkSrOUhAL6velZcIJXq
kVLvKustBhTQ12JVL52S7Y+CMKQPE8SA2apvbhALV9RjnQK6jG99oradSFpQtlfh
PnM2ENRWZXi1D1BO5PJft4JzsMh2v6WqaiYJy5rmrJbbZyoo0vBqfizon1Mx2rtc
YmIOw7bvClV4oG/zOlC0aeI0QNKPGcESWWV5THEPVBGOx9edVcuzADJMJGbbIC/0
Ufs4lngy4zrKlLSWqwKM6MoYyXiRHsHaUCcGbXVGnbSspnUbEybDAPskBcqVp+DC
VH5NxDmQQEWUdTQEyiSmygXpa9GojX3KCFkF85Ohh3SUZ3O88ila+zpbDpfrXkJL
D2w6dyIqKghQuM9hivMYUNdLTYmWHNgDSbFyCcZuhzAbPCRx3tjle+BRSMKT3V6X
y0ofhIQ+3QeZzkHWkL+R
=M/in
-----END PGP SIGNATURE-----


It is possible to add blank spaces to the end of the visible characters on each line, as long as it doesn't result in a new line wrap,
and the signature will still verify.

Don't know of any practical exploits of this property, other than possibly intentionally padding the files to use up someone's storage, 
(not likely in today's large storage capacity ;-)   )

It could be useful if  a sender and receiver would agree on a special code as to the padding,
i.e. if someone is being forced to sign something, the sender and receiver could agree
that adding the following spaces to each line for 4 lines:  
7
7
2
4 

would signify the hidden message:

signing 
against
my 
will

(but this could also easily be forged by anyone who knew the system ...)


Anyway, just a curiosity of which users should be aware.

Absolutely *no* suggestions/requests to change GnuPG in any way
(which wouldn't be backward compatible anyway)

Armored signing, or a detached signature of a text file,  *will*  detect any spaces added on to a line.


vedaal






From wk at gnupg.org  Mon Jan 12 23:06:13 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 12 Jan 2015 23:06:13 +0100
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
In-Reply-To: <54B41692.6060301@sixdemonbag.org> (Robert J. Hansen's message of
 "Mon, 12 Jan 2015 13:46:42 -0500")
References: <54B41692.6060301@sixdemonbag.org>
Message-ID: <87iogbfycq.fsf@vigenere.g10code.de>

On Mon, 12 Jan 2015 19:46, rjh at sixdemonbag.org said:

> ... What's going on here?  It seems like an alarming regression if
> GnuPG 2.1.1 is unable to decrypt symmetrically-encrypted files made
> with GnuPG 2.0.x.

I did some quick tests by encrypting to one symmetric key and two public
keys using 1.4.18.  Decryption with current 2.1 shows no problems.  With
a 1.5M tarball and thus partial length encoding the test file is simlar
to yours.  However, I did test on Debian.

Can you please try to decrypt on Unix or create a sample encrypted file
and send it to me?


Salam-Shalom,

   Werner

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



From wk at gnupg.org  Tue Jan 13 09:01:36 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 09:01:36 +0100
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
In-Reply-To: <54B441FD.4020604@sixdemonbag.org> (Robert J. Hansen's message of
 "Mon, 12 Jan 2015 16:51:57 -0500")
References: <54B41692.6060301@sixdemonbag.org>
 <54B441FD.4020604@sixdemonbag.org>
Message-ID: <87vbkbds7z.fsf@vigenere.g10code.de>

On Mon, 12 Jan 2015 22:51, rjh at sixdemonbag.org said:

> The major difference between the two installations is (a) one is a
> Windows box and one is an OS X box, and (b) OS X has my private keys on
> it, and on Windows I was relying on using the symmetric passphrase to

Can you move the private keys away from the OS X box and try again? 

"gpg --with-keygrip -K" shows the files you need to move from
private-keys-v1.d to a temporary directory.  kill the gpa-agent then.
With that gpg should act identical to your Windows installation.  Same
problem now?


Shalom-Salam,

   Werner

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



From rjh at sixdemonbag.org  Tue Jan 13 09:14:51 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 13 Jan 2015 03:14:51 -0500
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
In-Reply-To: <87vbkbds7z.fsf@vigenere.g10code.de>
References: <54B41692.6060301@sixdemonbag.org>	<54B441FD.4020604@sixdemonbag.org>
 <87vbkbds7z.fsf@vigenere.g10code.de>
Message-ID: <54B4D3FB.4080606@sixdemonbag.org>

> Can you move the private keys away from the OS X box and try again? 

Same results as on Win7/x64.  *However*... I have some useful
information.  Namely, I mistyped the passphrase and got the output below:


quorra:~ rjh$ gpg -vvvv backup.tar.xz.gpg
gpg: using character set 'utf-8'
# off=0 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid B8A6B74C001892C2
	data: [2044 bits]
	data: [2047 bits]
gpg: public key is 001892C2
gpg: no running gpg-agent - starting '/usr/local/gnupg-2.1/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to agent established
# off=529 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid E5B12DCFA1AC6FC0
	data: [2047 bits]
gpg: public key is A1AC6FC0
# off=800 ctb=8c tag=3 hlen=2 plen=46
:symkey enc packet: version 4, cipher 2, s2k 3, hash 2, seskey 256 bits
	salt 018490B8887579F9, count 65536 (96)
gpg: 3DES encrypted session key
# off=848 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
	length: unknown
	mdc_method: 2
gpg: encrypted with 1 passphrase
gpg: using subkey A1AC6FC0 instead of primary key 2B89BD45
gpg: encrypted with 2048-bit RSA key, ID A1AC6FC0, created 2011-07-28
      "Robert J. Hansen <rjh at sixdemonbag.org>"
gpg: using subkey 001892C2 instead of primary key D6B98E10
gpg: encrypted with 2048-bit ELG key, ID 001892C2, created 2008-07-30
      "Robert J. Hansen <rob at enigmail.net>"
gpg: encrypted with unknown algorithm 64
gpg: decryption failed: Invalid cipher algorithm


... but when I entered the passphrase correctly, it decrypted correctly.
 I suspect I mistyped the passphrase on Win 7/x64; I'll check that in
the morning.

Still, GnuPG reporting an invalid cipher algorithm when the real problem
is a bad passphrase should still be a bug worth fixing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150113/ba9c6da8/attachment-0001.bin>

From wk at gnupg.org  Tue Jan 13 09:10:32 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 09:10:32 +0100
Subject: Vanity Keys
In-Reply-To: <20150112205104.GA12857@glue.grepular.com> (Mike Cardwell's
 message of "Mon, 12 Jan 2015 20:51:04 +0000")
References: <20150112205104.GA12857@glue.grepular.com>
Message-ID: <87r3uzdrt3.fsf@vigenere.g10code.de>

On Mon, 12 Jan 2015 21:51, gnupg at lists.grepular.com said:

> Apparently some of the funds will be donated to the GnuPG project. I suspect
> he hasn't been in contact, and I imagine the funds would not be welcome?

I have not heard about it but given that the Wau Holland Stiftung is
collecting GnuPG donations also via Bitcoin, it is likely that this
can't be tracked.

However, if that processing power is used to find many dups for long
keyids we will sooner or later neet to invest work to mitigate the
effect of this (e.g. adding a fingerprint as signed attribute to each
signature).



Salam-Shalom,

   Werner


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



From wk at gnupg.org  Tue Jan 13 09:14:41 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 09:14:41 +0100
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <54B41805.9010007@whonix.org> (Patrick Schleizer's message of
 "Mon, 12 Jan 2015 18:52:53 +0000")
References: <54B32F26.3030007@whonix.org> <87sifggt9r.fsf@vigenere.g10code.de>
 <54B41805.9010007@whonix.org>
Message-ID: <87mw5ndrm6.fsf@vigenere.g10code.de>

On Mon, 12 Jan 2015 19:52, patrick-mailinglists at whonix.org said:

> However, what works for me is this:
>
> gpg --output ./out --verify ./sha512sums.asc

We are both wrong.  --verify does only a verify and nothing else.
Running without --verify writes the actual signed data to the file.

> When it exits 0, then this approach is sound, sane and fine?

You better check the status lines; in particular watch out for

  [GNUPG:] VALIDSIG E4B868C8F90C.....

or use gpgv.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Tue Jan 13 10:06:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 10:06:07 +0100
Subject: Bug with GnuPG 2.1.1 on Windows 7 x64
In-Reply-To: <54B4D3FB.4080606@sixdemonbag.org> (Robert J. Hansen's message of
 "Tue, 13 Jan 2015 03:14:51 -0500")
References: <54B41692.6060301@sixdemonbag.org>
 <54B441FD.4020604@sixdemonbag.org>
 <87vbkbds7z.fsf@vigenere.g10code.de>
 <54B4D3FB.4080606@sixdemonbag.org>
Message-ID: <877fwrdp8g.fsf@vigenere.g10code.de>

On Tue, 13 Jan 2015 09:14, rjh at sixdemonbag.org said:

> Same results as on Win7/x64.  *However*... I have some useful

Good. So I don't need to debug on Windows.

> Still, GnuPG reporting an invalid cipher algorithm when the real problem
> is a bad passphrase should still be a bug worth fixing.

Actually this is not a 2.1 bug but also present in 1.4.18 and earlier.
I'll investigate that closer....


Salam-Shalom,

   Werner

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



From nicholas.cole at gmail.com  Tue Jan 13 10:41:42 2015
From: nicholas.cole at gmail.com (Nicholas Cole)
Date: Tue, 13 Jan 2015 09:41:42 +0000
Subject: Vanity Keys
In-Reply-To: <87r3uzdrt3.fsf@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
Message-ID: <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>

On Tue, Jan 13, 2015 at 8:10 AM, Werner Koch <wk at gnupg.org> wrote:
> On Mon, 12 Jan 2015 21:51, gnupg at lists.grepular.com said:
>
>> Apparently some of the funds will be donated to the GnuPG project. I suspect
>> he hasn't been in contact, and I imagine the funds would not be welcome?
>
> I have not heard about it but given that the Wau Holland Stiftung is
> collecting GnuPG donations also via Bitcoin, it is likely that this
> can't be tracked.
>
> However, if that processing power is used to find many dups for long
> keyids we will sooner or later neet to invest work to mitigate the
> effect of this (e.g. adding a fingerprint as signed attribute to each
> signature).

Or a new revision of the standard, I suppose.  But I think that one or
the other would be worth doing in any case given the way things are
moving.  It is best to be ahead of the game.

N.


From wk at gnupg.org  Tue Jan 13 12:33:25 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 12:33:25 +0100
Subject: Issuer Fingerprint (was: Vanity Keys)
In-Reply-To: <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 (Nicholas Cole's message of "Tue, 13 Jan 2015 09:41:42 +0000")
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
Message-ID: <87zj9mdiey.fsf_-_@vigenere.g10code.de>

[Moving discussion to gnupg-devel]

On Tue, 13 Jan 2015 10:41, nicholas.cole at gmail.com said:

> Or a new revision of the standard, I suppose.  But I think that one or

A new key and signature packet version will take years to develop and
deploy.  Thus I think it is better to first do something within the
standard which will be backward compatible.

We currently use this subpacket:

  5.2.3.5.  Issuer

   (8-octet Key ID)

   The OpenPGP Key ID of the key issuing the signature.

A new optional subpacket:

5.2.3.27.  IssuerFingerprint

   (N-octet Key Fingerprint)

   The OpenPGP Fingerprint of the key issuing the signature.  For
   current versions of OpenPGP N has the value 20.  Future versions of
   OpenPGP may specify a different scheme for the fingerprint and thus
   another value for N.  Implementations should thus be prepared for
   other fingerprint lengths but honor this subpacket only if N is 20.

could be used to overcome duplicate key id problems.  The subpacket
type octet for that new subpacket would be 33.  Note that

  Adding a new Signature subpacket MUST be done through the IETF
  CONSENSUS method, as described in [RFC2434].

which takes quite some time.  Should be pursue this task or take a quick
solution by using notation data?

The size of a signature will increase by 22 or even more when using the
notation data approach.  This is noticeable but given that we are anyway
moving to the smaller ECC algorithms I think this is acceptable.


Shalom-Salam,

   Werner

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



From rjh at sixdemonbag.org  Tue Jan 13 17:29:58 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 13 Jan 2015 11:29:58 -0500
Subject: More strangeness.
Message-ID: <54B54806.1040205@sixdemonbag.org>

Starting from an empty GnuPG 2.1.1 Win 7/x64 installation, I imported my
existing secret certificate for 0xD6B98E10 and set it to ultimate trust.
  The result was a little ... weird.

C:\Users\rhansen>gpg --edit-key d6b98e10
Secret key is available.

pub  dsa2048/D6B98E10
      created: 2008-07-30  expires: never       usage: SC
      trust: ultimate      validity: ultimate
sub  elg2048/001892C2
      created: 2008-07-30  expires: never       usage: E
sub  rsa2048/810DB5D0
      created: 2013-03-14  expires: never       usage: S
[  undef ] (1). Robert J. Hansen <rob at enigmail.net>
[  undef ] (2)  Robert J. Hansen <rjh at sixdemonbag.org>
[  undef ] (3)  Robert J. Hansen <rob at mozilla-enigmail.org>
[  undef ] (4)  Robert J. Hansen <rjh at secret-alchemy.com>
[ revoked] (5)  Robert J. Hansen <robert.hansen at redjack.com>
[  undef ] (6)  [jpeg image of size 14285]


... Now, maybe I'm missing something completely obvious here (and if so,
it wouldn't be the first time), but if I have the secret part of a
certificate, and that certificate is marked as ultimately trusted, isn't
it a bit odd that the user IDs would possess undefined validity?


From dshaw at jabberwocky.com  Tue Jan 13 16:34:06 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 13 Jan 2015 10:34:06 -0500
Subject: Vanity Keys
In-Reply-To: <87r3uzdrt3.fsf@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
Message-ID: <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>

On Jan 13, 2015, at 3:10 AM, Werner Koch <wk at gnupg.org> wrote:
> 
> On Mon, 12 Jan 2015 21:51, gnupg at lists.grepular.com said:
> 
>> Apparently some of the funds will be donated to the GnuPG project. I suspect
>> he hasn't been in contact, and I imagine the funds would not be welcome?
> 
> I have not heard about it but given that the Wau Holland Stiftung is
> collecting GnuPG donations also via Bitcoin, it is likely that this
> can't be tracked.
> 
> However, if that processing power is used to find many dups for long
> keyids we will sooner or later neet to invest work to mitigate the
> effect of this (e.g. adding a fingerprint as signed attribute to each
> signature).

I'm sort of amused by vanitykeys.io.  If you read the HN thread, the author is pretty willing to accept this isn't the greatest idea, and has updated the page to say that.  (Of course, he hasn't taken the thing down completely either..)

I like the idea of adding a proper fingerprint to signature packets.  I seem to recall this was suggested once in the past, but I don't recall why it wasn't pursued.

David



From patrick-mailinglists at whonix.org  Tue Jan 13 19:24:55 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Tue, 13 Jan 2015 18:24:55 +0000
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <87mw5ndrm6.fsf@vigenere.g10code.de>
References: <54B32F26.3030007@whonix.org>
 <87sifggt9r.fsf@vigenere.g10code.de>	<54B41805.9010007@whonix.org>
 <87mw5ndrm6.fsf@vigenere.g10code.de>
Message-ID: <54B562F7.4010505@whonix.org>

Werner Koch:
> On Mon, 12 Jan 2015 19:52, patrick-mailinglists at whonix.org said:
> 
>> However, what works for me is this:
>>
>> gpg --output ./out --verify ./sha512sums.asc
> 
> We are both wrong.  --verify does only a verify and nothing else.
> Running without --verify writes the actual signed data to the file.

Indeed.

What I wanted to write in my previous mail...

However, what works for me is this:

gpg --output ./out --decrypt ./sha512sums.asc

Adding --decrypt or not has the same result?



From patrick-mailinglists at whonix.org  Tue Jan 13 20:03:36 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Tue, 13 Jan 2015 19:03:36 +0000
Subject: Are there cases where gpg --verify will exit 0, even if verification
 failed?
Message-ID: <54B56C08.3070402@whonix.org>

In another thread...

Werner Koch
> On Mon, 12 Jan 2015 19:52, patrick-
>> When it exits 0, then this approach is sound, sane and fine?
> You better check the status lines; in particular watch out for
> 
>   [GNUPG:] VALIDSIG E4B868C8F90C.....
> 
> or use gpgv.

Are there cases where gpg --verify will exit 0, even if verification failed?

(Suppose one uses a separate --homedir where only legitimate signing
keys are imported.)



From patrick-mailinglists at whonix.org  Tue Jan 13 20:38:11 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Tue, 13 Jan 2015 19:38:11 +0000
Subject: How to detect extraneous content in clearsigned (--clearsign)
 files?
In-Reply-To: <54B562F7.4010505@whonix.org>
References: <54B32F26.3030007@whonix.org>
 <87sifggt9r.fsf@vigenere.g10code.de>	<54B41805.9010007@whonix.org>
 <87mw5ndrm6.fsf@vigenere.g10code.de> <54B562F7.4010505@whonix.org>
Message-ID: <54B57423.30703@whonix.org>

Patrick Schleizer:
> Werner Koch:
>> On Mon, 12 Jan 2015 19:52, patrick-mailinglists at whonix.org said:
>>
>>> However, what works for me is this:
>>>
>>> gpg --output ./out --verify ./sha512sums.asc
>>
>> We are both wrong.  --verify does only a verify and nothing else.
>> Running without --verify writes the actual signed data to the file.
> 
> Indeed.
> 
> What I wanted to write in my previous mail...
> 
> However, what works for me is this:
> 
> gpg --output ./out --decrypt ./sha512sums.asc
> 
> Adding --decrypt or not has the same result?

Can answer my own question:
Using --decrypt for verification only is a really bad idea in scripts -
gpg would still exit 0 if file is encrypted, but unsigned.



From ndk.clanbo at gmail.com  Tue Jan 13 20:53:37 2015
From: ndk.clanbo at gmail.com (NdK)
Date: Tue, 13 Jan 2015 20:53:37 +0100
Subject: Vanity Keys
In-Reply-To: <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
Message-ID: <54B577C1.1090201@gmail.com>

Il 13/01/2015 16:34, David Shaw ha scritto:

> I like the idea of adding a proper fingerprint to signature packets.  I seem to recall this was suggested once in the past, but I don't recall why it wasn't pursued.
What I don't understand (surely because of my ignorance of GPG inner
working) is what that should add to the security... IOW, if the private
key have been generated by a third party to have a certain fingerprint,
what's the purpose of adding that fingerprint to the signature?

BYtE,
 Diego.



From dgouttegattat at incenp.org  Tue Jan 13 21:33:54 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 13 Jan 2015 21:33:54 +0100
Subject: More strangeness.
In-Reply-To: <54B54806.1040205@sixdemonbag.org>
References: <54B54806.1040205@sixdemonbag.org>
Message-ID: <54B58132.902@incenp.org>

On 01/13/2015 05:29 PM, Robert J. Hansen wrote:
> ... Now, maybe I'm missing something completely obvious here (and if so,
> it wouldn't be the first time), but if I have the secret part of a
> certificate, and that certificate is marked as ultimately trusted, isn't
> it a bit odd that the user IDs would possess undefined validity?

It could be the same problem as the one reported last month by Ximin Luo 
[1,2].

That problem only occurs when the public keys are stored in the new 
keybox format, which would be your case if you were ?starting from an 
empty GnuPG 2.1.1 installation?.

Until the bug is fixed, a possible workaround is to force GnuPG 2.1 to 
use the legacy pubring format, e.g. by creating an empty pubring.gpg 
file in GnuPG?s home directory, prior to importing any key.

[1] http://lists.gnupg.org/pipermail/gnupg-devel/2014-December/029197.html

[2] https://bugs.g10code.com/gnupg/issue1794

-------------- 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/20150113/d64ef65e/attachment.sig>

From wk at gnupg.org  Tue Jan 13 21:38:42 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2015 21:38:42 +0100
Subject: Vanity Keys
In-Reply-To: <54B577C1.1090201@gmail.com> (NdK's message of "Tue, 13 Jan 2015
 20:53:37 +0100")
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
 <54B577C1.1090201@gmail.com>
Message-ID: <87ppaibelp.fsf@vigenere.g10code.de>

On Tue, 13 Jan 2015 20:53, ndk.clanbo at gmail.com said:

> What I don't understand (surely because of my ignorance of GPG inner
> working) is what that should add to the security... IOW, if the private

Indirectly due to a DoS.  By creating a duplicated long key id and
having someone import that one it makes it impossible to verify a
signature made by the original key.  Well, we could also change the code
to trial verify with all key ids but that takes longer than needed and
may by itself be used as a DoS.

> key have been generated by a third party to have a certain fingerprint,
> what's the purpose of adding that fingerprint to the signature?

Preimage attacks on SHA-1 fingerprints are not even on the horizon.  By
the time they are possible all kind of other serious attacks will also
be possible.


Salam-Shalom,

   Werner

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



From dshaw at jabberwocky.com  Tue Jan 13 21:52:07 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 13 Jan 2015 15:52:07 -0500
Subject: Vanity Keys
In-Reply-To: <54B577C1.1090201@gmail.com>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
 <54B577C1.1090201@gmail.com>
Message-ID: <BAE525B1-E0CF-4DE4-BF1E-D82919081017@jabberwocky.com>

On Jan 13, 2015, at 2:53 PM, NdK <ndk.clanbo at gmail.com> wrote:
> 
> Il 13/01/2015 16:34, David Shaw ha scritto:
> 
>> I like the idea of adding a proper fingerprint to signature packets.  I seem to recall this was suggested once in the past, but I don't recall why it wasn't pursued.
> What I don't understand (surely because of my ignorance of GPG inner
> working) is what that should add to the security... IOW, if the private
> key have been generated by a third party to have a certain fingerprint,
> what's the purpose of adding that fingerprint to the signature?

OpenPGP uses the 64-bit key ID to locate keys.  If two people have the same 64-bit key ID, it doesn't mean that person A can impersonate person B, but it does mean that if both person A and person B's keys are on a given keyring, the verifying program will not know which key to use to check the signature.  Only the right key will actually work for verification, but the program may not be able to find that right key.

The fingerprint is a 160-bit key ID - effectively impossible (given today's knowledge) to impersonate.

David

From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Jan 14 00:54:44 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 13 Jan 2015 23:54:44 +0000
Subject: Issuer Fingerprint (was: Vanity Keys)
In-Reply-To: <87zj9mdiey.fsf_-_@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 <87zj9mdiey.fsf_-_@vigenere.g10code.de>
Message-ID: <47353596.20150113235444@my_localhost>

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

Hi


On Tuesday 13 January 2015 at 11:33:25 AM, in
<mid:87zj9mdiey.fsf_-_ at vigenere.g10code.de>, Werner Koch wrote:


> Should be pursue this
> task or take a quick solution by using notation data?

I thought we already took care of this with
sig-notation issuer-fpr at notations.openpgp.fifthhorseman.net=%g [0]

[0] <http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7235>

- --
Best regards

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

I don't suffer from insanity I enjoy every minute of it.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUtbBNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwIx8IALcVn0Fga/hLnz2iksk36PDk
IkIHNMfi4BmszL23i/CXnDVemDXzReIis1n0eWEicw8hkliEAZHKRMomKNnIqXB7
ezp+dnnhYghIuXCDNlYSigSZy0hyln/tR2Mb9bebQC29IxBuP4HIOQGBaJak6Bq1
oeCqfzcp0GNAqIT5MR/k+pJIQeW9NMLCam+5pv7vXrkgVsP+O0HdSRkZ3Ef8y/Vg
3RBF30JhCmpAVKuUeCTputryeBs3RFTQ6f2CbskUY6gvcKmHmofGpUG5eI2gmjKb
hvP3s2RGMewbYUNGZDmXJdaWdtkjsvNx3X/aM2x3IqUvGZ3eECQz2Op++VbcMbyI
vgQBFgoAZgUCVLWwVV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45MaNAQC2k5AjdZepyyvbbwYqgK0OzhFF
9Wz0TAvtpMEltAI1GQEA8RyAlAosJa5bO29y1UI2yIFT9B9iozy00H2vBSl49Qg=
=povV
-----END PGP SIGNATURE-----



From s.murthy at mykolab.com  Wed Jan 14 04:11:51 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Wed, 14 Jan 2015 03:11:51 +0000
Subject: Vanity Keys
In-Reply-To: <BAE525B1-E0CF-4DE4-BF1E-D82919081017@jabberwocky.com>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
 <54B577C1.1090201@gmail.com>
 <BAE525B1-E0CF-4DE4-BF1E-D82919081017@jabberwocky.com>
Message-ID: <88142C57-C97D-453B-8ACA-78688E119840@mykolab.com>

Hi

> Only the right key will actually work for verification, but the program may not be able to find that right key.

Wouldn?t this issue of possible collisions in the long key ID (64 bits / 16 hex digits)
causing problems for the GPG program only be an issue in an organisational setting,
where there is a large number of users sharing that program and where keys
are uploaded to/retrieved from key servers using short IDs?

For an individual who for example only imports keys with fingerprints (160 bits /  40 hex) and
publishes their fingerprint rather than the short or long key ID, how can this risk arise
or is there still an issue with key servers?

Sandeep Murthy
s.murthy at mykolab.com

> On 13 Jan 2015, at 20:52, David Shaw <dshaw at jabberwocky.com> wrote:
> 
> On Jan 13, 2015, at 2:53 PM, NdK <ndk.clanbo at gmail.com> wrote:
>> 
>> Il 13/01/2015 16:34, David Shaw ha scritto:
>> 
>>> I like the idea of adding a proper fingerprint to signature packets.  I seem to recall this was suggested once in the past, but I don't recall why it wasn't pursued.
>> What I don't understand (surely because of my ignorance of GPG inner
>> working) is what that should add to the security... IOW, if the private
>> key have been generated by a third party to have a certain fingerprint,
>> what's the purpose of adding that fingerprint to the signature?
> 
> OpenPGP uses the 64-bit key ID to locate keys.  If two people have the same 64-bit key ID, it doesn't mean that person A can impersonate person B, but it does mean that if both person A and person B's keys are on a given keyring, the verifying program will not know which key to use to check the signature.  Only the right key will actually work for verification, but the program may not be able to find that right key.
> 
> The fingerprint is a 160-bit key ID - effectively impossible (given today's knowledge) to impersonate.
> 
> David
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150114/eda0a5bc/attachment.sig>

From dshaw at jabberwocky.com  Wed Jan 14 04:42:41 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 13 Jan 2015 22:42:41 -0500
Subject: Vanity Keys
In-Reply-To: <88142C57-C97D-453B-8ACA-78688E119840@mykolab.com>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
 <54B577C1.1090201@gmail.com>
 <BAE525B1-E0CF-4DE4-BF1E-D82919081017@jabberwocky.com>
 <88142C57-C97D-453B-8ACA-78688E119840@mykolab.com>
Message-ID: <2A0ECF27-C06A-46D0-99BC-7B54AFBEE249@jabberwocky.com>

On Jan 13, 2015, at 10:11 PM, Sandeep Murthy <s.murthy at mykolab.com> wrote:
> 
> Hi
> 
>> Only the right key will actually work for verification, but the program may not be able to find that right key.
> 
> Wouldn?t this issue of possible collisions in the long key ID (64 bits / 16 hex digits)
> causing problems for the GPG program only be an issue in an organisational setting,
> where there is a large number of users sharing that program and where keys
> are uploaded to/retrieved from key servers using short IDs?
> 
> For an individual who for example only imports keys with fingerprints (160 bits /  40 hex) and
> publishes their fingerprint rather than the short or long key ID, how can this risk arise
> or is there still an issue with key servers?

Unfortunately, it doesn't matter if users only use fingerprints when deciding to import a key or not.  Internally, keys are looked up using the 64-bit key ID.  This is a limitation of OpenPGP - the "issuer" of a signature is 64 bits long.  If the user manages to get two keys that happen to have the same 64-bit key ID (the lowest 64 bits of the fingerprint, for OpenPGP keys) then this problem applies to them.

The discussion on gnupg-devel is about adding a larger issuer that contains the complete fingerprint.

David



From wk at gnupg.org  Wed Jan 14 09:57:47 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 09:57:47 +0100
Subject: More strangeness.
In-Reply-To: <54B58132.902@incenp.org> (Damien Goutte-Gattat's message of
 "Tue, 13 Jan 2015 21:33:54 +0100")
References: <54B54806.1040205@sixdemonbag.org> <54B58132.902@incenp.org>
Message-ID: <87r3uxagdw.fsf@vigenere.g10code.de>

On Tue, 13 Jan 2015 21:33, dgouttegattat at incenp.org said:

> [2] https://bugs.g10code.com/gnupg/issue1794

Right, this is a blocker for a 2.1.2 release.


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Wed Jan 14 09:55:43 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 09:55:43 +0100
Subject: Issuer Fingerprint
In-Reply-To: <47353596.20150113235444@my_localhost> (MFPA's message of "Tue,
 13 Jan 2015 23:54:44 +0000")
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <CAAu18hdCBXbvhfAAnzB7yuHP3h+rffwiVLOKK=Ae=z+VA7YAOw@mail.gmail.com>
 <87zj9mdiey.fsf_-_@vigenere.g10code.de>
 <47353596.20150113235444@my_localhost>
Message-ID: <87vbk9aghc.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 00:54, 2014-667rhzu3dc-lists-groups at riseup.net said:

> I thought we already took care of this with
> sig-notation issuer-fpr at notations.openpgp.fifthhorseman.net=%g [0]

But GnuPG does not know about this - it is Dkg's private thing.  Further
this triples the required size for each signature.

If we would do that with notaion data something like issuer at gnupg.org=
would be used.  But see the discussion on gnupg-devel.


Salam-Shalom,

   Werner

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



From dave.pawson at gmail.com  Wed Jan 14 08:51:46 2015
From: dave.pawson at gmail.com (Dave Pawson)
Date: Wed, 14 Jan 2015 07:51:46 +0000
Subject: Are there cases where gpg --verify will exit 0, even if
 verification failed?
In-Reply-To: <54B56C08.3070402@whonix.org>
References: <54B56C08.3070402@whonix.org>
Message-ID: <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>

In Unix terms, a program that has run successfully to completion
exits with status zero, no 'extra' semantic attached?

Dave

On 13 January 2015 at 19:03, Patrick Schleizer
<patrick-mailinglists at whonix.org> wrote:
> In another thread...
>
> Werner Koch
>> On Mon, 12 Jan 2015 19:52, patrick-
>>> When it exits 0, then this approach is sound, sane and fine?
>> You better check the status lines; in particular watch out for
>>
>>   [GNUPG:] VALIDSIG E4B868C8F90C.....
>>
>> or use gpgv.
>
> Are there cases where gpg --verify will exit 0, even if verification failed?
>
> (Suppose one uses a separate --homedir where only legitimate signing
> keys are imported.)
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk


From s.murthy at mykolab.com  Wed Jan 14 14:22:45 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Wed, 14 Jan 2015 13:22:45 +0000
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
Message-ID: <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>

>> Are there cases where gpg --verify will exit 0, even if verification failed?

Verification could fail internally within the gpg program, or externally because
the signature fie does not exist or is incorrectly named or maybe corrupt
e.g.

[srm@~]$ gpg --verify asig.sig; echo $?
gpg: can't open `asig.sig': No such file or directory
gpg: verify signatures failed: No such file or directory
2

Exit codes in shells indicate problems relating to completion or disruption
of the child process invoked by a parent process.

They will not record unsuccessful events inside the child process
related to program functions, i.e. if you inside gpg editing a key
and enter an incorrect subcommand or use it incorrectly then this will
not affect the exit code, I don?t think.

Sandeep Murthy
s.murthy at mykolab.com

> On 14 Jan 2015, at 07:51, Dave Pawson <dave.pawson at gmail.com> wrote:
> 
> In Unix terms, a program that has run successfully to completion
> exits with status zero, no 'extra' semantic attached?
> 
> Dave
> 
> On 13 January 2015 at 19:03, Patrick Schleizer
> <patrick-mailinglists at whonix.org> wrote:
>> In another thread...
>> 
>> Werner Koch
>>> On Mon, 12 Jan 2015 19:52, patrick-
>>>> When it exits 0, then this approach is sound, sane and fine?
>>> You better check the status lines; in particular watch out for
>>> 
>>>  [GNUPG:] VALIDSIG E4B868C8F90C.....
>>> 
>>> or use gpgv.
>> 
>> Are there cases where gpg --verify will exit 0, even if verification failed?
>> 
>> (Suppose one uses a separate --homedir where only legitimate signing
>> keys are imported.)
>> 
>> 
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 
> 
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150114/1b6b111e/attachment.sig>

From dkg at fifthhorseman.net  Wed Jan 14 14:40:23 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 14 Jan 2015 08:40:23 -0500
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
Message-ID: <878uh55vlk.fsf@alice.fifthhorseman.net>

On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
> Exit codes in shells indicate problems relating to completion or disruption
> of the child process invoked by a parent process.
>
> They will not record unsuccessful events inside the child process
> related to program functions, i.e. if you inside gpg editing a key
> and enter an incorrect subcommand or use it incorrectly then this will
> not affect the exit code, I don?t think.

This is not the case.  all processes have a return code, whether they
are invoked by a shell or by other processes.  The return code is a
critical part of the output of a program.

gpg does use the return code to indicate failure of signature
verification.

consider the results of:

    echo test1 > test1.txt
    echo test2 > test2.txt
    gpg --detach-sign --armor test1.txt
    gpg --verify test1.txt.asc test1.txt
    gpg --verify test1.txt.asc test2.txt

the return value of the first --verify should be 0, but the second
--verify invocation should return 1, indicating that the signature
cannot be verified over the (different) contents of test2.txt

       --dkg


From kristian.fiskerstrand at sumptuouscapital.com  Wed Jan 14 15:06:53 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Wed, 14 Jan 2015 15:06:53 +0100
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <878uh55vlk.fsf@alice.fifthhorseman.net>
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
 <878uh55vlk.fsf@alice.fifthhorseman.net>
Message-ID: <54B677FD.8090002@sumptuouscapital.com>

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

On 01/14/2015 02:40 PM, Daniel Kahn Gillmor wrote:
> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>> Exit codes in shells indicate problems relating to completion or
>> disruption of the child process invoked by a parent process.
>> 


..

> 
> the return value of the first --verify should be 0, but the second 
> --verify invocation should return 1, indicating that the signature 
> cannot be verified over the (different) contents of test2.txt

But iirc you will anyways have to check the status-fd for the validity
of the issuing key.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"A government that robs Peter to pay Paul can always depend on the
support of Paul."
(George Bernard Shaw)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtnf3AAoJEPw7F94F4Tag93cP/3sI+nnS0HK68JEeE3dfCO/5
pFweOpBSeSOeh5gA2e0UuO0Nm7l1hD2syjFNn18L/fMybVfqodYKnIWkh3v9O8oi
sNNxDJ8emhWPaE0oV9VpPocEcq5MbZwerF5iIB+rm9d+R2CuqMKpIkEYv2abIxWJ
tJsMlp9bXWC66QbQBDc9D+okn9yKzJgYdfAilprk7kKPmnSgIVIagwdcQyg9iUks
dX1q6rsGonYzPOwWk2sZdXyAB2TleYSPq8ySaShtSt4dZ/DFK38l4hYOcOX/OrG1
bROwTg3fnjISvFHYAJPx1CCrsdN/fIOPATrCITPQLV0IdTUIhrbi6bgTjDvfr8eQ
NSuggpdjvif1EtDnCQYv6gSoI2egbFFs92bqzLsfm/gVtJJi25d4JRammHNOzjWt
0SBxFBAI64cAuReDkLcqnhSu0dccQRQYUjF88a4dP9ldE6eK4HNo8h6vQxbVJ6Y+
xPQxBCMwHUoLLKWQt+PLBQXqqZFnFOdPRF6Ns+OHsIC3Go/oH7ynY+yKSQHziTRc
6TnLMfg4by2bh1RIsBF1nb1wkXcyV9tZXrriaM4H6wwPoR6IDnZnHU2dTcUn8LLT
c4FBn743TT0OZbVnMhd7e3PdUe6EVE0ZTKXilKqRk36+yEdBcrRj+ihwS9Vy/gt3
/u59aDPZpS8gTPWFSzjN
=KsGq
-----END PGP SIGNATURE-----


From s.murthy at mykolab.com  Wed Jan 14 16:31:43 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Wed, 14 Jan 2015 15:31:43 +0000
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <878uh55vlk.fsf@alice.fifthhorseman.net>
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
 <878uh55vlk.fsf@alice.fifthhorseman.net>
Message-ID: <D214C3E8-F22E-416B-9C86-50AAB7BE74C5@mykolab.com>

I know that all processes have an exit code, what I meant was
if you invoke gpg interactively like gpg ?edit-key <key ID /email>
and then execute a wrong subcommand or specify something incorrectly
then the gpg exit code will not reflect this unless the subcommand
launches another process.

Sandeep Murthy
s.murthy at mykolab.com

> On 14 Jan 2015, at 13:40, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>> Exit codes in shells indicate problems relating to completion or disruption
>> of the child process invoked by a parent process.
>> 
>> They will not record unsuccessful events inside the child process
>> related to program functions, i.e. if you inside gpg editing a key
>> and enter an incorrect subcommand or use it incorrectly then this will
>> not affect the exit code, I don?t think.
> 
> This is not the case.  all processes have a return code, whether they
> are invoked by a shell or by other processes.  The return code is a
> critical part of the output of a program.
> 
> gpg does use the return code to indicate failure of signature
> verification.
> 
> consider the results of:
> 
>   echo test1 > test1.txt
>   echo test2 > test2.txt
>   gpg --detach-sign --armor test1.txt
>   gpg --verify test1.txt.asc test1.txt
>   gpg --verify test1.txt.asc test2.txt
> 
> the return value of the first --verify should be 0, but the second
> --verify invocation should return 1, indicating that the signature
> cannot be verified over the (different) contents of test2.txt
> 
>      --dkg



From wk at gnupg.org  Wed Jan 14 17:18:19 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 17:18:19 +0100
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <878uh55vlk.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Wed, 14 Jan 2015 08:40:23 -0500")
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
 <878uh55vlk.fsf@alice.fifthhorseman.net>
Message-ID: <87wq4p2v5g.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 14:40, dkg at fifthhorseman.net said:

> gpg does use the return code to indicate failure of signature
> verification.

But recall that success does not mean that the signature is good.
Check the status output or use gpgv.

Shalom-Salam,

   Werner

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



From patrick-mailinglists at whonix.org  Wed Jan 14 17:40:34 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Wed, 14 Jan 2015 16:40:34 +0000
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <87wq4p2v5g.fsf@vigenere.g10code.de>
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
 <878uh55vlk.fsf@alice.fifthhorseman.net> <87wq4p2v5g.fsf@vigenere.g10code.de>
Message-ID: <54B69C02.5050905@whonix.org>

Werner Koch:
> On Wed, 14 Jan 2015 14:40, dkg at fifthhorseman.net said:
> 
>> gpg does use the return code to indicate failure of signature
>> verification.
> 
> But recall that success does not mean that the signature is good.
> Check the status output or use gpgv.

Do you mean, for example, the signature could be valid, but the key that
signed it could be revoked and gpg would still exit 0?

Or can you tell another example please where gpg would exit 0, but where
where the signature is bad?



From patrick-mailinglists at whonix.org  Wed Jan 14 17:44:47 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Wed, 14 Jan 2015 16:44:47 +0000
Subject: Is there a shell script or bash library for parsing gpg's --status-fd
 output?
Message-ID: <54B69CFF.5080506@whonix.org>

Hi!

Is there a shell script or bash library for parsing gpg's --status-fd
output?

I mean, I could code it myself. But why duplicate effort and risk
messing up. Maybe there is some existing or even recommended or even
official library to do this?

(What I mean by parsing is: to get from lines such as "[GNUPG:] GOODSIG
416..." to variables such as goodsig=true, fingerprint=416... and so forth.)

Cheers,
Patrick



From johanw at vulcan.xs4all.nl  Wed Jan 14 19:23:48 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Wed, 14 Jan 2015 19:23:48 +0100
Subject: Vanity Keys
In-Reply-To: <87ppaibelp.fsf@vigenere.g10code.de>
References: <20150112205104.GA12857@glue.grepular.com>
 <87r3uzdrt3.fsf@vigenere.g10code.de>
 <449725A2-9D11-4059-9EB9-4166786B74E7@jabberwocky.com>
 <54B577C1.1090201@gmail.com> <87ppaibelp.fsf@vigenere.g10code.de>
Message-ID: <54B6B434.6050200@vulcan.xs4all.nl>

On 13-01-2015 21:38, Werner Koch wrote:

> Well, we could also change the code
> to trial verify with all key ids but that takes longer than needed and
> may by itself be used as a DoS.

You don't need to test all keyID's - just those with the same key ID.
Assuming this is a rare occasion and someone's keyring is not flooded
with keys with the same ID (in that case you are probably under some
kind of attack and might investigate), you can even detect and store
this condition somewere when importing the key and checking this
probably very short list if key ID's that appear multiple times.

I wonder what this would do with the keyserver network. They probably
need adapting too.

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



From wk at gnupg.org  Wed Jan 14 21:15:54 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2015 21:15:54 +0100
Subject: Are there cases where gpg --verify will exit 0,
 even if verification failed?
In-Reply-To: <54B69C02.5050905@whonix.org> (Patrick Schleizer's message of
 "Wed, 14 Jan 2015 16:40:34 +0000")
References: <54B56C08.3070402@whonix.org>
 <CAEncD4eFLZSvHFTgPYV48PXhuGuihsCi8jo-X7JjmNsVhyk3OQ@mail.gmail.com>
 <3B2D48C6-89BD-452E-B7C5-FED144E13925@mykolab.com>
 <878uh55vlk.fsf@alice.fifthhorseman.net>
 <87wq4p2v5g.fsf@vigenere.g10code.de> <54B69C02.5050905@whonix.org>
Message-ID: <87a91l2k5h.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 17:40, patrick-mailinglists at whonix.org said:

> Do you mean, for example, the signature could be valid, but the key that
> signed it could be revoked and gpg would still exit 0?

Sure.  It is just to complex to put it into one number.  Consider the
case for multiple signatures - who is going to decide whether the
signature is valid.  This has all been discussed about 15 years ago
with the result of writing the gpgv binary which is suitable for most
automated signature verification use cases.


Shalom-Salam,

   Werner

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



From jose.castillo at gmail.com  Wed Jan 14 21:59:51 2015
From: jose.castillo at gmail.com (Joey Castillo)
Date: Wed, 14 Jan 2015 15:59:51 -0500
Subject: Specifying passphrase for batch key generation
Message-ID: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>

Reading the manual for batch GPG key generation in GnuPG 2.1, I see
the following note:

> Since GnuPG version 2.1 it is not anymore possible to specify a passphrase for unattended key generation. The passphrase command is simply ignored and ?%ask-passpharse? is thus implicitly enabled.

I'm running into an issue now with a module I was using to generate
keys in a python script (python-gnupg). Its method was to generate a
set of parameters, including the passphrase parameter, and pass that
via stdin to gpg --batch --gen-key.

Now that we cannot specify a passphrase in the batch parameters, what
is the preferred method for batch key generation with a specified
passphrase?


From johanw at vulcan.xs4all.nl  Thu Jan 15 00:28:46 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Thu, 15 Jan 2015 00:28:46 +0100
Subject: Specifying passphrase for batch key generation
In-Reply-To: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>
References: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>
Message-ID: <54B6FBAE.7030502@vulcan.xs4all.nl>

On 14-01-2015 21:59, Joey Castillo wrote:

> Now that we cannot specify a passphrase in the batch parameters, what
> is the preferred method for batch key generation with a specified
> passphrase?

Use GnuPG 1.4.18.

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



From anthony at cajuntechie.org  Thu Jan 15 04:09:15 2015
From: anthony at cajuntechie.org (Anthony Papillion)
Date: Wed, 14 Jan 2015 21:09:15 -0600
Subject: Problems when encrypting to a group on MacGPG
Message-ID: <54B72F5B.7010606@cajuntechie.org>

Hello Everyone,

I'm trying to help someone configure MacGPG 2.0.22. I've defined a group
with multiple keys in it. But when I try to encrypt to the group to test
things, I get the following error:

"gpg: Ohhhh geeee: can't encode a 256 bit key in a 0 bit frame"

This happens after I tell the program to accept the final key in the
group as valid. But it doesn't seem to be related to a key since I've
deleted the final key and it still give me the error.

Any idea what might be causing this? Thanks!

Thanks,
Anthony

-- 
Anthony Papillion

Phone:       1.918.631.7331
XMPP Chat:   cypher at chat.cpunk.us
Fingerprint: 65EF73EC 8B57F6B1 8C475BD4 426088AC FE21B251
PGP Key:     http://www.cajuntechie.org/p/my-pgp-key.html

To any NSA and FBI agents reading my email: please consider whether
defending the US Constitution against all enemies, foreign or domestic,
requires you to follow Edward Snowden's example.



From s.murthy at mykolab.com  Thu Jan 15 05:44:50 2015
From: s.murthy at mykolab.com (Murthy, Sandeep)
Date: Thu, 15 Jan 2015 04:44:50 +0000
Subject: Problems when encrypting to a group on MacGPG
In-Reply-To: <54B72F5B.7010606@cajuntechie.org>
References: <54B72F5B.7010606@cajuntechie.org>
Message-ID: <cf42256b4681691cb167bbcc6567f5a4@mykolab.com>

I use Mac GPG2, but I?ve never had this problem.

You could try posting this to the MacGPG2 support page
which is here

http://support.gpgtools.org/

Sandeep Murthy
s.murthy at mykolab.com


On 2015-01-15 03:09, Anthony Papillion wrote:
> Hello Everyone,
> 
> I'm trying to help someone configure MacGPG 2.0.22. I've defined a 
> group
> with multiple keys in it. But when I try to encrypt to the group to 
> test
> things, I get the following error:
> 
> "gpg: Ohhhh geeee: can't encode a 256 bit key in a 0 bit frame"
> 
> This happens after I tell the program to accept the final key in the
> group as valid. But it doesn't seem to be related to a key since I've
> deleted the final key and it still give me the error.
> 
> Any idea what might be causing this? Thanks!
> 
> Thanks,
> Anthony
> 
> --
> Anthony Papillion
> 
> Phone:       1.918.631.7331
> XMPP Chat:   cypher at chat.cpunk.us
> Fingerprint: 65EF73EC 8B57F6B1 8C475BD4 426088AC FE21B251
> PGP Key:     http://www.cajuntechie.org/p/my-pgp-key.html
> 
> To any NSA and FBI agents reading my email: please consider whether
> defending the US Constitution against all enemies, foreign or domestic,
> requires you to follow Edward Snowden's example.
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From dougb at dougbarton.email  Thu Jan 15 05:53:08 2015
From: dougb at dougbarton.email (Doug Barton)
Date: Wed, 14 Jan 2015 20:53:08 -0800
Subject: Problems when encrypting to a group on MacGPG
In-Reply-To: <54B72F5B.7010606@cajuntechie.org>
References: <54B72F5B.7010606@cajuntechie.org>
Message-ID: <54B747B4.4060809@dougbarton.email>

On 1/14/15 7:09 PM, Anthony Papillion wrote:
> "gpg: Ohhhh geeee: can't encode a 256 bit key in a 0 bit frame"
>
> This happens after I tell the program to accept the final key in the
> group as valid. But it doesn't seem to be related to a key since I've
> deleted the final key and it still give me the error.

You're on the right track .... delete some more keys, test again, repeat 
till you find the key causing problems. Depending on the number of keys 
it may be easier to add/delete a few at a time, do a binary search, etc.

Good luck,

Doug



From wk at gnupg.org  Thu Jan 15 09:56:22 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2015 09:56:22 +0100
Subject: Specifying passphrase for batch key generation
In-Reply-To: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>
 (Joey Castillo's message of "Wed, 14 Jan 2015 15:59:51 -0500")
References: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>
Message-ID: <87r3uw1ky1.fsf@vigenere.g10code.de>

On Wed, 14 Jan 2015 21:59, jose.castillo at gmail.com said:

> Now that we cannot specify a passphrase in the batch parameters, what
> is the preferred method for batch key generation with a specified
> passphrase?

Thanks for this question.  The Enigmail folks also asked on how to do
this and my answer was to switch to pinentry-mode=loopback.  Revisiting
the code, it seems that there could be an easier solution.  I see no
reason why we should not allow passing a passphrase along with the
parameters for the key generation.  After all if the user wants to work
around the Pinentry, they should be allowed to do that - at least for
the key generation.

It requires a bit of code but I think it is worth to have it in 2.1.2.


Salam-Shalom,

   Werner

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



From georgeorwellhardwired at riseup.net  Thu Jan 15 09:11:33 2015
From: georgeorwellhardwired at riseup.net (georgeorwellhardwired at riseup.net)
Date: Thu, 15 Jan 2015 08:11:33 +0000
Subject: Gnupg-users Digest, Vol 136, Issue 23
In-Reply-To: <mailman.18919.1421272311.28939.gnupg-users@gnupg.org>
References: <mailman.18919.1421272311.28939.gnupg-users@gnupg.org>
Message-ID: <35f804cae46ee582bc1f3fcf22b6bc0c@riseup.net>

Subject: cannot build database in GPA in ubuntu and won't generate GPG 
key.

Hey.

Every time I use GPA in ubuntu it says, when I start GPA: "GnuPG is 
rebuilding the trust database.
This might take a few seconds." And I can wait for hours, while nothing 
happens.

And If I try to close the window and try to generate a GPG key, it will 
say: "The GPGME library returned an unexpected error. The error 
was:"General error." This is probably a bug in GPA. GPA will now try to 
recover from this error.

Is there anyone that seen these errors before?





On 2015-01-14 21:51, gnupg-users-request at gnupg.org wrote:
> Send Gnupg-users mailing list submissions to
> 	gnupg-users at gnupg.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.gnupg.org/mailman/listinfo/gnupg-users
> or, via email, send a message with subject or body 'help' to
> 	gnupg-users-request at gnupg.org
> 
> You can reach the person managing the list at
> 	gnupg-users-owner at gnupg.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnupg-users digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Sandeep Murthy)
>    2. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Daniel Kahn Gillmor)
>    3. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Kristian Fiskerstrand)
>    4. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Sandeep Murthy)
>    5. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Werner Koch)
>    6. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Patrick Schleizer)
>    7. Is there a shell script or bash library for parsing gpg's
>       --status-fd output? (Patrick Schleizer)
>    8. Re: Vanity Keys (Johan Wevers)
>    9. Re: Are there cases where gpg --verify will exit 0, even if
>       verification failed? (Werner Koch)
>   10. Specifying passphrase for batch key generation (Joey Castillo)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 14 Jan 2015 13:22:45 +0000
> From: Sandeep Murthy <s.murthy at mykolab.com>
> To: gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <3B2D48C6-89BD-452E-B7C5-FED144E13925 at mykolab.com>
> Content-Type: text/plain; charset="utf-8"
> 
>>> Are there cases where gpg --verify will exit 0, even if verification 
>>> failed?
> 
> Verification could fail internally within the gpg program, or 
> externally because
> the signature fie does not exist or is incorrectly named or maybe 
> corrupt
> e.g.
> 
> [srm@~]$ gpg --verify asig.sig; echo $?
> gpg: can't open `asig.sig': No such file or directory
> gpg: verify signatures failed: No such file or directory
> 2
> 
> Exit codes in shells indicate problems relating to completion or 
> disruption
> of the child process invoked by a parent process.
> 
> They will not record unsuccessful events inside the child process
> related to program functions, i.e. if you inside gpg editing a key
> and enter an incorrect subcommand or use it incorrectly then this will
> not affect the exit code, I don?t think.
> 
> Sandeep Murthy
> s.murthy at mykolab.com
> 
>> On 14 Jan 2015, at 07:51, Dave Pawson <dave.pawson at gmail.com> wrote:
>> 
>> In Unix terms, a program that has run successfully to completion
>> exits with status zero, no 'extra' semantic attached?
>> 
>> Dave
>> 
>> On 13 January 2015 at 19:03, Patrick Schleizer
>> <patrick-mailinglists at whonix.org> wrote:
>>> In another thread...
>>> 
>>> Werner Koch
>>>> On Mon, 12 Jan 2015 19:52, patrick-
>>>>> When it exits 0, then this approach is sound, sane and fine?
>>>> You better check the status lines; in particular watch out for
>>>> 
>>>>  [GNUPG:] VALIDSIG E4B868C8F90C.....
>>>> 
>>>> or use gpgv.
>>> 
>>> Are there cases where gpg --verify will exit 0, even if verification 
>>> failed?
>>> 
>>> (Suppose one uses a separate --homedir where only legitimate signing
>>> keys are imported.)
>>> 
>>> 
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
>> 
>> 
>> --
>> Dave Pawson
>> XSLT XSL-FO FAQ.
>> Docbook FAQ.
>> http://www.dpawson.co.uk
>> 
>> _______________________________________________
>> 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: 873 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: </pipermail/attachments/20150114/1b6b111e/attachment-0001.sig>
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 14 Jan 2015 08:40:23 -0500
> From: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> To: Sandeep Murthy <s.murthy at mykolab.com>, gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <878uh55vlk.fsf at alice.fifthhorseman.net>
> Content-Type: text/plain; charset=utf-8
> 
> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>> Exit codes in shells indicate problems relating to completion or 
>> disruption
>> of the child process invoked by a parent process.
>> 
>> They will not record unsuccessful events inside the child process
>> related to program functions, i.e. if you inside gpg editing a key
>> and enter an incorrect subcommand or use it incorrectly then this will
>> not affect the exit code, I don?t think.
> 
> This is not the case.  all processes have a return code, whether they
> are invoked by a shell or by other processes.  The return code is a
> critical part of the output of a program.
> 
> gpg does use the return code to indicate failure of signature
> verification.
> 
> consider the results of:
> 
>     echo test1 > test1.txt
>     echo test2 > test2.txt
>     gpg --detach-sign --armor test1.txt
>     gpg --verify test1.txt.asc test1.txt
>     gpg --verify test1.txt.asc test2.txt
> 
> the return value of the first --verify should be 0, but the second
> --verify invocation should return 1, indicating that the signature
> cannot be verified over the (different) contents of test2.txt
> 
>        --dkg
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 14 Jan 2015 15:06:53 +0100
> From: Kristian Fiskerstrand
> 	<kristian.fiskerstrand at sumptuouscapital.com>
> To: Daniel Kahn Gillmor <dkg at fifthhorseman.net>,  Sandeep Murthy
> 	<s.murthy at mykolab.com>, gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <54B677FD.8090002 at sumptuouscapital.com>
> Content-Type: text/plain; charset=utf-8
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 01/14/2015 02:40 PM, Daniel Kahn Gillmor wrote:
>> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>>> Exit codes in shells indicate problems relating to completion or
>>> disruption of the child process invoked by a parent process.
>>> 
> 
> 
> ..
> 
>> 
>> the return value of the first --verify should be 0, but the second
>> --verify invocation should return 1, indicating that the signature
>> cannot be verified over the (different) contents of test2.txt
> 
> But iirc you will anyways have to check the status-fd for the validity
> of the issuing key.
> 
> - --
> - ----------------------------
> Kristian Fiskerstrand
> Blog: http://blog.sumptuouscapital.com
> Twitter: @krifisk
> - ----------------------------
> Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> - ----------------------------
> "A government that robs Peter to pay Paul can always depend on the
> support of Paul."
> (George Bernard Shaw)
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJUtnf3AAoJEPw7F94F4Tag93cP/3sI+nnS0HK68JEeE3dfCO/5
> pFweOpBSeSOeh5gA2e0UuO0Nm7l1hD2syjFNn18L/fMybVfqodYKnIWkh3v9O8oi
> sNNxDJ8emhWPaE0oV9VpPocEcq5MbZwerF5iIB+rm9d+R2CuqMKpIkEYv2abIxWJ
> tJsMlp9bXWC66QbQBDc9D+okn9yKzJgYdfAilprk7kKPmnSgIVIagwdcQyg9iUks
> dX1q6rsGonYzPOwWk2sZdXyAB2TleYSPq8ySaShtSt4dZ/DFK38l4hYOcOX/OrG1
> bROwTg3fnjISvFHYAJPx1CCrsdN/fIOPATrCITPQLV0IdTUIhrbi6bgTjDvfr8eQ
> NSuggpdjvif1EtDnCQYv6gSoI2egbFFs92bqzLsfm/gVtJJi25d4JRammHNOzjWt
> 0SBxFBAI64cAuReDkLcqnhSu0dccQRQYUjF88a4dP9ldE6eK4HNo8h6vQxbVJ6Y+
> xPQxBCMwHUoLLKWQt+PLBQXqqZFnFOdPRF6Ns+OHsIC3Go/oH7ynY+yKSQHziTRc
> 6TnLMfg4by2bh1RIsBF1nb1wkXcyV9tZXrriaM4H6wwPoR6IDnZnHU2dTcUn8LLT
> c4FBn743TT0OZbVnMhd7e3PdUe6EVE0ZTKXilKqRk36+yEdBcrRj+ihwS9Vy/gt3
> /u59aDPZpS8gTPWFSzjN
> =KsGq
> -----END PGP SIGNATURE-----
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 14 Jan 2015 15:31:43 +0000
> From: Sandeep Murthy <s.murthy at mykolab.com>
> To: gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <D214C3E8-F22E-416B-9C86-50AAB7BE74C5 at mykolab.com>
> Content-Type: text/plain; charset=utf-8
> 
> I know that all processes have an exit code, what I meant was
> if you invoke gpg interactively like gpg ?edit-key <key ID /email>
> and then execute a wrong subcommand or specify something incorrectly
> then the gpg exit code will not reflect this unless the subcommand
> launches another process.
> 
> Sandeep Murthy
> s.murthy at mykolab.com
> 
>> On 14 Jan 2015, at 13:40, Daniel Kahn Gillmor <dkg at fifthhorseman.net> 
>> wrote:
>> 
>> On Wed 2015-01-14 08:22:45 -0500, Sandeep Murthy wrote:
>>> Exit codes in shells indicate problems relating to completion or 
>>> disruption
>>> of the child process invoked by a parent process.
>>> 
>>> They will not record unsuccessful events inside the child process
>>> related to program functions, i.e. if you inside gpg editing a key
>>> and enter an incorrect subcommand or use it incorrectly then this 
>>> will
>>> not affect the exit code, I don?t think.
>> 
>> This is not the case.  all processes have a return code, whether they
>> are invoked by a shell or by other processes.  The return code is a
>> critical part of the output of a program.
>> 
>> gpg does use the return code to indicate failure of signature
>> verification.
>> 
>> consider the results of:
>> 
>>   echo test1 > test1.txt
>>   echo test2 > test2.txt
>>   gpg --detach-sign --armor test1.txt
>>   gpg --verify test1.txt.asc test1.txt
>>   gpg --verify test1.txt.asc test2.txt
>> 
>> the return value of the first --verify should be 0, but the second
>> --verify invocation should return 1, indicating that the signature
>> cannot be verified over the (different) contents of test2.txt
>> 
>>      --dkg
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 14 Jan 2015 17:18:19 +0100
> From: Werner Koch <wk at gnupg.org>
> To: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> Cc: gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <87wq4p2v5g.fsf at vigenere.g10code.de>
> Content-Type: text/plain; charset=us-ascii
> 
> On Wed, 14 Jan 2015 14:40, dkg at fifthhorseman.net said:
> 
>> gpg does use the return code to indicate failure of signature
>> verification.
> 
> But recall that success does not mean that the signature is good.
> Check the status output or use gpgv.
> 
> Shalom-Salam,
> 
>    Werner
> 
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 14 Jan 2015 16:40:34 +0000
> From: Patrick Schleizer <patrick-mailinglists at whonix.org>
> To: gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <54B69C02.5050905 at whonix.org>
> Content-Type: text/plain; charset=windows-1252
> 
> Werner Koch:
>> On Wed, 14 Jan 2015 14:40, dkg at fifthhorseman.net said:
>> 
>>> gpg does use the return code to indicate failure of signature
>>> verification.
>> 
>> But recall that success does not mean that the signature is good.
>> Check the status output or use gpgv.
> 
> Do you mean, for example, the signature could be valid, but the key 
> that
> signed it could be revoked and gpg would still exit 0?
> 
> Or can you tell another example please where gpg would exit 0, but 
> where
> where the signature is bad?
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 14 Jan 2015 16:44:47 +0000
> From: Patrick Schleizer <patrick-mailinglists at whonix.org>
> To: gnupg-users at gnupg.org
> Subject: Is there a shell script or bash library for parsing gpg's
> 	--status-fd output?
> Message-ID: <54B69CFF.5080506 at whonix.org>
> Content-Type: text/plain; charset=utf-8
> 
> Hi!
> 
> Is there a shell script or bash library for parsing gpg's --status-fd
> output?
> 
> I mean, I could code it myself. But why duplicate effort and risk
> messing up. Maybe there is some existing or even recommended or even
> official library to do this?
> 
> (What I mean by parsing is: to get from lines such as "[GNUPG:] GOODSIG
> 416..." to variables such as goodsig=true, fingerprint=416... and so 
> forth.)
> 
> Cheers,
> Patrick
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 14 Jan 2015 19:23:48 +0100
> From: Johan Wevers <johanw at vulcan.xs4all.nl>
> To: gnupg-users at gnupg.org
> Subject: Re: Vanity Keys
> Message-ID: <54B6B434.6050200 at vulcan.xs4all.nl>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 13-01-2015 21:38, Werner Koch wrote:
> 
>> Well, we could also change the code
>> to trial verify with all key ids but that takes longer than needed and
>> may by itself be used as a DoS.
> 
> You don't need to test all keyID's - just those with the same key ID.
> Assuming this is a rare occasion and someone's keyring is not flooded
> with keys with the same ID (in that case you are probably under some
> kind of attack and might investigate), you can even detect and store
> this condition somewere when importing the key and checking this
> probably very short list if key ID's that appear multiple times.
> 
> I wonder what this would do with the keyserver network. They probably
> need adapting too.
> 
> --
> ir. J.C.A. Wevers
> PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
> 
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 14 Jan 2015 21:15:54 +0100
> From: Werner Koch <wk at gnupg.org>
> To: Patrick Schleizer <patrick-mailinglists at whonix.org>
> Cc: gnupg-users at gnupg.org
> Subject: Re: Are there cases where gpg --verify will exit 0, even if
> 	verification failed?
> Message-ID: <87a91l2k5h.fsf at vigenere.g10code.de>
> Content-Type: text/plain; charset=us-ascii
> 
> On Wed, 14 Jan 2015 17:40, patrick-mailinglists at whonix.org said:
> 
>> Do you mean, for example, the signature could be valid, but the key 
>> that
>> signed it could be revoked and gpg would still exit 0?
> 
> Sure.  It is just to complex to put it into one number.  Consider the
> case for multiple signatures - who is going to decide whether the
> signature is valid.  This has all been discussed about 15 years ago
> with the result of writing the gpgv binary which is suitable for most
> automated signature verification use cases.
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Wed, 14 Jan 2015 15:59:51 -0500
> From: Joey Castillo <jose.castillo at gmail.com>
> To: gnupg-users at gnupg.org
> Subject: Specifying passphrase for batch key generation
> Message-ID:
> 	<CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Reading the manual for batch GPG key generation in GnuPG 2.1, I see
> the following note:
> 
>> Since GnuPG version 2.1 it is not anymore possible to specify a 
>> passphrase for unattended key generation. The passphrase command is 
>> simply ignored and ?%ask-passpharse? is thus implicitly enabled.
> 
> I'm running into an issue now with a module I was using to generate
> keys in a python script (python-gnupg). Its method was to generate a
> set of parameters, including the passphrase parameter, and pass that
> via stdin to gpg --batch --gen-key.
> 
> Now that we cannot specify a passphrase in the batch parameters, what
> is the preferred method for batch key generation with a specified
> passphrase?
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 
> ------------------------------
> 
> End of Gnupg-users Digest, Vol 136, Issue 23
> ********************************************



From temp at janeden.net  Thu Jan 15 10:34:36 2015
From: temp at janeden.net (Jan Eden)
Date: Thu, 15 Jan 2015 10:34:36 +0100
Subject: gpgsm: certificate is not usable for signing
In-Reply-To: <20150115092343.GA1500@mcm-eden.verw.uni-koeln.de>
References: <20150115092343.GA1500@mcm-eden.verw.uni-koeln.de>
Message-ID: <20150115093436.GA1730@mcm-eden.verw.uni-koeln.de>

Hi,

the problem might be related to issue 1644
(http://bugs.g10code.com/gnupg/issue1644), my cert is part of the
DFN-PKI.

- Jan

On 2015-01-15 10:23, Jan Eden wrote:
> Hi,
> 
> I recently installed GnuPG 2.1 and successfully used gpgsm for about a
> week. This morning, signing messages with mutt failed, and the signature
> of received messages cannot be verified. Signing a test file reveals:
> 
> lbox:~ jan$ gpgsm --verbose --sign testfile.txt
> gpgsm: certificate is not usable for signing
> gpgsm: certificate is not usable for signing
> gpgsm: failed to open '/Users/jan/.gnupg/policies.txt': No such file or directory
> gpgsm: Note: non-critical certificate policy not allowed
> gpgsm: certificate not found: Ambiguous name
> gpgsm: certificate [...]
> gpgsm: checking the CRL failed: Not found
> gpgsm: validation model used: shell
> gpgsm: error creating signature: Not found <GpgSM>
> 
> I already tried restoring ~/.gnupg from a backup, without success. It
> looks like gpgsm does not find some intermediate certificate.
> 
> Thanks in advance for any help.
> 
> - Jan


From georgeorwellhardwired at riseup.net  Thu Jan 15 11:42:20 2015
From: georgeorwellhardwired at riseup.net (georgeorwellhardwired at riseup.net)
Date: Thu, 15 Jan 2015 10:42:20 +0000
Subject: Subject: cannot build database in GPA in ubuntu and won't generate
 GPG key.
Message-ID: <70d91272ce3b81fc12a95d88595056c9@riseup.net>


Hey.

Every time I use GPA in ubuntu it says, when I start GPA: "GnuPG is 
rebuilding the trust database.
This might take a few seconds." And I can wait for hours, while nothing 
happens.

And If I try to close the window and try to generate a GPG key, it will 
say: "The GPGME library returned an unexpected error. The error 
was:"General error." This is probably a bug in GPA. GPA will now try to 
recover from this error.

Is there anyone that seen these errors before?



From temp at janeden.net  Thu Jan 15 10:23:43 2015
From: temp at janeden.net (Jan Eden)
Date: Thu, 15 Jan 2015 10:23:43 +0100
Subject: gpgsm: certificate is not usable for signing
Message-ID: <20150115092343.GA1500@mcm-eden.verw.uni-koeln.de>

Hi,

I recently installed GnuPG 2.1 and successfully used gpgsm for about a
week. This morning, signing messages with mutt failed, and the signature
of received messages cannot be verified. Signing a test file reveals:

lbox:~ jan$ gpgsm --verbose --sign testfile.txt
gpgsm: certificate is not usable for signing
gpgsm: certificate is not usable for signing
gpgsm: failed to open '/Users/jan/.gnupg/policies.txt': No such file or directory
gpgsm: Note: non-critical certificate policy not allowed
gpgsm: certificate not found: Ambiguous name
gpgsm: certificate [...]
gpgsm: checking the CRL failed: Not found
gpgsm: validation model used: shell
gpgsm: error creating signature: Not found <GpgSM>

I already tried restoring ~/.gnupg from a backup, without success. It
looks like gpgsm does not find some intermediate certificate.

Thanks in advance for any help.

- Jan


From patrick at enigmail.net  Thu Jan 15 15:59:56 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 15 Jan 2015 15:59:56 +0100
Subject: Specifying passphrase for batch key generation
In-Reply-To: <87r3uw1ky1.fsf__12027.9536386535$1421312545$gmane$org@vigenere.g10code.de>
References: <CAAocvpu_1oe9Rpu-kNmpdDskg9VgOi-sY=2YVPhvujUU_MyDag@mail.gmail.com>
 <87r3uw1ky1.fsf__12027.9536386535$1421312545$gmane$org@vigenere.g10code.de>
Message-ID: <54B7D5EC.7010909@enigmail.net>

On 15.01.15 09:56, Werner Koch wrote:
> On Wed, 14 Jan 2015 21:59, jose.castillo at gmail.com said:
> 
>> Now that we cannot specify a passphrase in the batch parameters, what
>> is the preferred method for batch key generation with a specified
>> passphrase?
> 
> Thanks for this question.  The Enigmail folks also asked on how to do
> this and my answer was to switch to pinentry-mode=loopback.  Revisiting
> the code, it seems that there could be an easier solution.  I see no
> reason why we should not allow passing a passphrase along with the
> parameters for the key generation.  After all if the user wants to work
> around the Pinentry, they should be allowed to do that - at least for
> the key generation.
> 
> It requires a bit of code but I think it is worth to have it in 2.1.2.

Even easier!

Thanks a lot
-Patrick


From anthony at cajuntechie.org  Thu Jan 15 19:51:32 2015
From: anthony at cajuntechie.org (Anthony Papillion)
Date: Thu, 15 Jan 2015 12:51:32 -0600
Subject: Problems when encrypting to a group on MacGPG
In-Reply-To: <54B747B4.4060809@dougbarton.email>
References: <54B72F5B.7010606@cajuntechie.org>
 <54B747B4.4060809@dougbarton.email>
Message-ID: <54B80C34.9030707@cajuntechie.org>

On 01/14/2015 10:53 PM, Doug Barton wrote:
> On 1/14/15 7:09 PM, Anthony Papillion wrote:
>> "gpg: Ohhhh geeee: can't encode a 256 bit key in a 0 bit frame"
>>
>> This happens after I tell the program to accept the final key in the
>> group as valid. But it doesn't seem to be related to a key since I've
>> deleted the final key and it still give me the error.
> 
> You're on the right track .... delete some more keys, test again, repeat
> till you find the key causing problems. Depending on the number of keys
> it may be easier to add/delete a few at a time, do a binary search, etc.

Thanks Doug! It looks like the problem is likely related to two of the
keys in the users keyring containing ECC subkeys which, apparently, that
version of MacGPG can't handle well. I'm going to connect with them
again today and delete those keys and see what happens. Thanks again!

Anthony


From dkg at fifthhorseman.net  Thu Jan 15 22:37:00 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 15 Jan 2015 16:37:00 -0500
Subject: Subject: cannot build database in GPA in ubuntu and won't
 generate GPG key.
In-Reply-To: <70d91272ce3b81fc12a95d88595056c9@riseup.net>
References: <70d91272ce3b81fc12a95d88595056c9@riseup.net>
Message-ID: <871tmv3ev7.fsf@alice.fifthhorseman.net>

On Thu 2015-01-15 05:42:20 -0500, georgeorwellhardwired at riseup.net wrote:

> Every time I use GPA in ubuntu it says, when I start GPA: "GnuPG is 
> rebuilding the trust database.
> This might take a few seconds." And I can wait for hours, while nothing 
> happens.

I'm not seeing this with debian unstable, gpa version 0.9.5-2.  what
version of gpa are you using on what version of ubuntu?

        --dkg


From kardan38 at gmail.com  Fri Jan 16 13:56:06 2015
From: kardan38 at gmail.com (Salih Kardan)
Date: Fri, 16 Jan 2015 14:56:06 +0200
Subject: relationship between primary keys and subkeys
Message-ID: <CAF+udknHJaXXm=bminBeactxGxw1wWJEV7dmJcE3BfQqxQrSVQ@mail.gmail.com>

Hi everyone,

I have two simple questions about subkey mechanism. I search gnupg
documentations and mailing list, but could not find answers to my
questions. I would be so glad, if someone can answer below questions.

1) Is it possible to create a subkey of a subkey ?

2) What are the trust implications between a parent key and a child key? Is
it "Ultimate Trust"? How can we confirm this? Or is this something for us
to determine/interpret?


Thanks in advance.

Salih
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150116/4e8c33d1/attachment.html>

From dshaw at jabberwocky.com  Fri Jan 16 16:45:25 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Fri, 16 Jan 2015 10:45:25 -0500
Subject: relationship between primary keys and subkeys
In-Reply-To: <CAF+udknHJaXXm=bminBeactxGxw1wWJEV7dmJcE3BfQqxQrSVQ@mail.gmail.com>
References: <CAF+udknHJaXXm=bminBeactxGxw1wWJEV7dmJcE3BfQqxQrSVQ@mail.gmail.com>
Message-ID: <74187384-EC44-419E-AB0D-F97DF833D591@jabberwocky.com>

On Jan 16, 2015, at 7:56 AM, Salih Kardan <kardan38 at gmail.com> wrote:
> 
> Hi everyone,
> 
> I have two simple questions about subkey mechanism. I search gnupg documentations and mailing list, but could not find answers to my questions. I would be so glad, if someone can answer below questions. 
> 
> 1) Is it possible to create a subkey of a subkey ?

No.  Primary keys own/parent subkeys.  There is no nesting beyond that.

> 2) What are the trust implications between a parent key and a child key? Is it "Ultimate Trust"? How can we confirm this? Or is this something for us to determine/interpret?

It's not really something that needs interpretation or calculation.  Essentially you trust a subkey exactly the same way you trust the parent key for that subkey.   The interpretation and calculation is done for the parent key.

David



From patrick-mailinglists at whonix.org  Fri Jan 16 19:28:13 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Fri, 16 Jan 2015 18:28:13 +0000
Subject: gpg-bash-lib - parsing gpg's --status-fd - feedback desired - was:
 Is there a shell script or bash library for parsing gpg's --status-fd output?
In-Reply-To: <54B69CFF.5080506@whonix.org>
References: <54B69CFF.5080506@whonix.org>
Message-ID: <54B9583D.4070109@whonix.org>

Hi,

apparently something like gpg-bash-lib didn't exist.

Created one:
https://github.com/Whonix/gpg-bash-lib

Could you leave some feedback please?

Main code file:
https://github.com/Whonix/gpg-bash-lib/blob/master/usr/lib/gpg-bash-lib/modules.d/50_common

No usage instructions yet, see unit test:
https://github.com/Whonix/gpg-bash-lib/blob/master/usr/lib/gpg-bash-lib/unit_test

Specifically, does my status-fd parsing code look sane?
https://github.com/Whonix/gpg-bash-lib/blob/0fc7a02b35f9580502daccf46692988b55961a23/usr/lib/gpg-bash-lib/modules.d/50_common#L172

Anyone else interested to contribute?

Cheers,
Patrick



From rjh at sixdemonbag.org  Sat Jan 17 05:10:37 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 16 Jan 2015 23:10:37 -0500
Subject: Blackhat
Message-ID: <54B9E0BD.3030204@sixdemonbag.org>

Today a new movie came out, _Blackhat_, directed by Michael Mann.  Being
a huge Mann fan -- I've seen every movie he ever directed, yes, even
_The Keep_ -- I saw it tonight.

The good news: GnuPG gets namedropped in it.  Twice.  :)

The bad news: it's Mann's worst film, yes, even worse than _The Keep_.
No matter what you do, do not try and think logically during this film.
 Logic will only betray you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/bb17b4ed/attachment-0001.bin>

From rjh at sixdemonbag.org  Sat Jan 17 23:48:29 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 17 Jan 2015 17:48:29 -0500
Subject: Hash selection failure on 2.1.1
Message-ID: <54BAE6BD.9040709@sixdemonbag.org>

After having tea with a friend, I sent her an email telling her to feel
free to mention it to others if she was so inclined -- and GnuPG seems
to have selected the wrong algorithm.  I'm including the email and
relevant data here.

=====

Subject: Oh, and--
From: "Robert J. Hansen" <rjh at sixdemonbag.org>
Date: 1/17/15, 5:34 PM
To: Raven Alder <raven at oneeyedcrow.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you feel like mentioning our tea on LJ, please, feel free.  Use your
own best judgment as to what things you relate to others.  :)
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJUuuNaAAoJEERqRG+BDbXQWlQH/0VZAfeBmrmwiMqkWwFxhNe5
5hvUjJbXIufQBaz/2DsC/yyPZIWe5DAtuwa4sbKCyvuSkzWJ0gJheqwADgOak1GA
1lOiIzI7xru1Qn6ZYY9qHNpvFW9/OGIkoLf3dZVO7NdW3Uvg7aE9RMah+LF+vCtM
xs3TLQlXMAt4aDliZqyihilxUw7jGEUguVMeEBOP9Nq2s6k2W0oxKVn1i2tHW3u6
knCxCMeWspF1Fs7gnvL6zov2PHPb6DF7K7eYqHlLJo894xQu+NwzCGgGSCu9gmJ8
O8+paerf0fLKtX9FxYSerfkP7eS4dOrF/XHwL6N1WlSghlh4vJMQnWGUFXoostU=
=rJ25
-----END PGP SIGNATURE-----

=====

Note the SHA-1 hash selection.  This seems ... very odd.  Checking her
key I see:

quorra:~ rjh$ gpg --edit-key Raven

pub  dsa1024/3D7489C0
     created: 2002-02-21  expires: never       usage: SC
     trust: unknown       validity: unknown
sub  elg2048/5DD7F638
     created: 2002-02-21  expires: never       usage: E
[ unknown] (1). Raven Alder <raven at oneeyedcrow.net>
[ unknown] (2)  Raven (Key #2) <raven at oneeyedcrow.net>
[ unknown] (3)  Raven Alder <raven at samuraihack.com>

gpg> showpref
[ unknown] (1). Raven Alder <raven at oneeyedcrow.net>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA1, RIPEMD160
     Compression: ZLIB, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
[ unknown] (2)  Raven (Key #2) <raven at oneeyedcrow.net>
     Cipher: AES, TWOFISH, CAST5, BLOWFISH, 3DES
     Digest: RIPEMD160, SHA1
     Compression: ZLIB, ZIP, Uncompressed
     Features: Keyserver no-modify
[ unknown] (3)  Raven Alder <raven at samuraihack.com>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA1, RIPEMD160
     Compression: ZLIB, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify


... okay, so each and every user ID lists RIPEMD160 as a hash algorithm;
that's good.  Now let's look at my preferred algorithms.

quorra:~ rjh$ grep default-pref .gnupg/gpg.conf
default-preference-list SHA256 RIPEMD160 AES256 CAMELLIA256 TWOFISH 3DES


... As I understand the way algorithms are selected, GnuPG uses the
most-preferred algorithm in my list that is also present in the
recipient's capability set.  Since SHA-1 implicitly follows after SHA256
and RIPEMD160, it has the lowest priority.

By my understanding, GnuPG should start by trying SHA256 and discovering
Raven doesn't advertise that as a capability.  It should then try
RIPEMD160 and see Raven advertises that, and thus it should use RIPEMD160.

Instead, it went to SHA-1.

This seems like a bug in the algorithm selection code.




Note: my certificate's primary signing key is DSA2048, which would seem
to require SHA224 or longer.  However, in order to be able to sign
messages for people who don't support anything other than SHA-1 or
RIPEMD160 I added an RSA2048 signing subkey a couple of years ago.  It
only gets used when DSA2048 is unavailable, such as here.  So please,
don't panic when you notice it was signed with a key other than my
primary.  :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150117/73f4f4df/attachment.bin>

From dshaw at jabberwocky.com  Sun Jan 18 02:02:06 2015
From: dshaw at jabberwocky.com (David Shaw)
Date: Sat, 17 Jan 2015 20:02:06 -0500
Subject: Hash selection failure on 2.1.1
In-Reply-To: <54BAE6BD.9040709@sixdemonbag.org>
References: <54BAE6BD.9040709@sixdemonbag.org>
Message-ID: <A6B6857A-208F-4728-9583-C42BA210CE6B@jabberwocky.com>

On Jan 17, 2015, at 5:48 PM, Robert J. Hansen <rjh at sixdemonbag.org> wrote:

> quorra:~ rjh$ grep default-pref .gnupg/gpg.conf
> default-preference-list SHA256 RIPEMD160 AES256 CAMELLIA256 TWOFISH 3DES
> 
> 
> ... As I understand the way algorithms are selected, GnuPG uses the
> most-preferred algorithm in my list that is also present in the
> recipient's capability set.  Since SHA-1 implicitly follows after SHA256
> and RIPEMD160, it has the lowest priority.

That's basically how it works for "personal-digest-preferences", but you're showing your "default-preference-list".  They're very different.  default-preference-list sets the default preferences for new keys and is not part of the digest choice when signing.

> By my understanding, GnuPG should start by trying SHA256 and discovering
> Raven doesn't advertise that as a capability.  It should then try
> RIPEMD160 and see Raven advertises that, and thus it should use RIPEMD160.

Not in this case.  That's a clearsigned message above, and so GnuPG has no way to know who your recipient is.  If you were encrypting & signing, it could know based on the recipient key, but there is no "recipient key" for a signed (only) message.  Without a recipient, there are no preferences for it to consult beyond stuff (personal-digest-preferences, usually) in your config file.

There are a bunch of steps GnuPG follows when selecting a digest for signing without a recipient, but outside of the cases when it is forced to use a particular algorithm (due to DSA size requirements, smartcard capabilities, or the like), the main steps are "If digest-algo is set, use that.  Otherwise, if personal-digest-preferences is set, use that.  Otherwise, use SHA-1."

Do you have a personal-digest-preferences (or even digest-algo) set in your config file?

David



From rjh at sixdemonbag.org  Sun Jan 18 03:27:47 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 17 Jan 2015 21:27:47 -0500
Subject: Hash selection failure on 2.1.1
In-Reply-To: <A6B6857A-208F-4728-9583-C42BA210CE6B@jabberwocky.com>
References: <54BAE6BD.9040709@sixdemonbag.org>
 <A6B6857A-208F-4728-9583-C42BA210CE6B@jabberwocky.com>
Message-ID: <54BB1A23.9000602@sixdemonbag.org>

> That's basically how it works for "personal-digest-preferences", but
> you're showing your "default-preference-list".  They're very
> different.  default-preference-list sets the default preferences for
> new keys and is not part of the digest choice when signing.

D'oh!

[puts on the brown paper bag]

> Do you have a personal-digest-preferences (or even digest-algo) set
> in your config file?

I did until early this afternoon, when while editing my gpg.conf I
foolishly decided to consolidate the personal-*-preferences into
default-preference-list.

My braino, guys.  Oh man.  :)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150117/e8d23a24/attachment.bin>

From mlisten at hammernoch.net  Sun Jan 18 14:12:15 2015
From: mlisten at hammernoch.net (=?windows-1252?Q?Ludwig_H=FCgelsch=E4fer?=)
Date: Sun, 18 Jan 2015 14:12:15 +0100
Subject: More strangeness.
In-Reply-To: <87r3uxagdw.fsf@vigenere.g10code.de>
References: <54B54806.1040205@sixdemonbag.org> <54B58132.902@incenp.org>
 <87r3uxagdw.fsf@vigenere.g10code.de>
Message-ID: <54BBB12F.7020407@hammernoch.net>

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

On 14.01.15 09:57, Werner Koch wrote:
> On Tue, 13 Jan 2015 21:33, dgouttegattat at incenp.org said:
> 
>> [2] https://bugs.g10code.com/gnupg/issue1794
> 
> Right, this is a blocker for a 2.1.2 release.

I have another strange appearance:

1. Generate a key under 2.1.1 (new keybox storage enabled).

pub  rsa2048/2D561BB4
     created: 2015-01-18  expires: 2015-02-15  usage: SC
     trust: ultimate      validity: ultimate
sub  rsa2048/1675A825
     created: 2015-01-18  expires: 2015-02-15  usage: E
[ultimate] (1). Ludwig H?gelsch?fer (Test Validity 2.1.1)
<ludwig at enigmail.net>


2. Sign this key with an older key (in this case my regular key
0959D2E3). Save changes. Quit. Enter into edit-key again, key is
displayed as follows:

pub  rsa2048/2D561BB4
     created: 2015-01-18  expires: 2015-02-15  usage: SC
     trust: ultimate      validity: full
sub  rsa2048/1675A825
     created: 2015-01-18  expires: 2015-02-15  usage: E
[  full  ] (1). Ludwig H?gelsch?fer (Test Validity 2.1.1)
<ludwig at enigmail.net>

Is this another manifestation of the mentioned bug or a different one?

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCgAGBQJUu7EuAAoJEA52XAUJWdLj08oIAJguUUMOQwCww4n/n9knlhQ/
S8U6snmeL7iV9+rtiDcD3OxZQ+WyU4Fu3LIkIVl+PXEM59IoKnKM/iasTjFMZzAv
3Jvv0SIR7+bkwbhDtiKE311kPD8HR3YtlHr0mp32hTm9o9nX8Hl7Y+jvU+6wxcbB
ZSz8lX78ANQ0BinSQA86gAwtP5z3mawLBRNDSPBIst/Caao9ZNBmRqOxUc6YEtk7
R/4987hAPD+FZG6C2nCda+z0tsIMJdbK3LouQOyOspbzO8CVAYn24M33WowV6AOt
IrvhLvbsRRp118yULrhby8Y83+MxaUgSg3x5QM0oBCySdVRVq7cUv+CzH6os050=
=pucW
-----END PGP SIGNATURE-----


From kristian.fiskerstrand at sumptuouscapital.com  Sun Jan 18 18:13:20 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 18 Jan 2015 18:13:20 +0100
Subject: GnuPG BOF (was: Re: Security Devroom @ FOSDEM'15)
In-Reply-To: <87sih642xy.fsf@vigenere.g10code.de>
References: <87sih642xy.fsf@vigenere.g10code.de>
Message-ID: <54BBE9B0.5010400@sumptuouscapital.com>

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

On 11/26/2014 12:27 PM, Werner Koch wrote:
> Hi,
> 
> I have been asked to forward the CFP below.  In case we want to do
> a GnuPG BoF we should ask whether it is possible to share that
> devroom.
> 

The schedule for security devroom seems to be filling up quite quickly
already, but I don't see any GnuPG event there. In fact, the Sunday
seems to be filled up with a lot of interesting security-related talks
already, but how about trying to get a GnuPG BOF on Saturday some time
after 12:00 ?

What items would be interesting to discuss on a potential BOF? To
start off, I personally have the following items to add as potential
discussion points:
 - The state of HKPS in GnuPG 2.1 (The SNI issue pretty much makes the
pool unusable in the current state)
 - LDAP Support in GnuPG 2.1 (currently not implemented, which makes
it difficult to work with systems such as Symantec Encryption Serve)
 - Standardization of the EdDSA I-D by WK (we already support this in
the development branch of SKS, but not in any released version)

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Donec eris sospes, multos numerabis amicos.
Tempora si fuerint nubila, solus eris.
As long as you are wealthy,you will have many friends.
When the tough times come, you will be left alone
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUu+mvAAoJEPw7F94F4TagOvwQAKo/hooOnfzcrv16KG8g4tLR
tPwRnVDgNKrKDz26S8maZ1b+CEq3lZ28JrCOb36azPr/LsRjKIyarjJHfu1Eq9Kb
ZFVa3NZ+cYI3hcdwXWoQop03mSypeUxGbuBq0HQ6jQVEFqLIbaB0XfSexuw1dr+n
VcB/iCuXo/0lJAIGENXqZNOVv+g3njbw/68BnZ/fh/1YoByfcpCGRxFMngtCdccH
hZGh3mbC0OjzgZK3y1nKaS7Te90Zqpcw9xuopQ4TEr0hTL5mPO4Ip4dgW+uPR2HI
S6MP5WSx2xps8qDZhcfn9LSNGyXJopo4x/kl53ouaZG+3AmYDn0kRHebYJ66y9DV
ya9ypEfWTpvorMJNRqFKN4Tnj3N+Z8xrY1/4JS5mAYanFooxSV7Hy4R1D+a49D+K
ePCMVxsLc5/uVG3jLRd45kfBsQrOcchPVAHVTLOsAJdfeGb8fFAKIhBUnpV7lTdV
5exRK0MDWwlGGj6U44PiSiM0I5Pk0f1B9kmU0UgqKAx+R4V8MxfbIJ16SgdENE35
LSCdtEmrR9CXA785gZBDh9YQ2R+whDUhNzLEw4jNiHhGm8NqVwCKgAJ32RvZv3sV
FtGKx1kxRUwr8+F9B/DATrxiTzn46gtpriC9aFdzs0lIJY6IKsNTJxjgDxHINtA+
Rn7H/44vP8ShArXmiM3p
=anr4
-----END PGP SIGNATURE-----


From kristian.fiskerstrand at sumptuouscapital.com  Sun Jan 18 18:21:31 2015
From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand)
Date: Sun, 18 Jan 2015 18:21:31 +0100
Subject: GnuPG BOF
In-Reply-To: <54BBE9B0.5010400@sumptuouscapital.com>
References: <87sih642xy.fsf@vigenere.g10code.de>
 <54BBE9B0.5010400@sumptuouscapital.com>
Message-ID: <54BBEB9B.8070004@sumptuouscapital.com>

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

On 01/18/2015 06:13 PM, Kristian Fiskerstrand wrote:
> On 11/26/2014 12:27 PM, Werner Koch wrote:
>> Hi,
> 
>> I have been asked to forward the CFP below.  In case we want to
>> do a GnuPG BoF we should ask whether it is possible to share
>> that devroom.
> 
> 
> The schedule for security devroom seems to be filling up quite
> quickly already, but I don't see any GnuPG event there. In fact,
> the Sunday seems to be filled up with a lot of interesting
> security-related talks already, but how about trying to get a GnuPG
> BOF on Saturday some time after 12:00 ?
> 
> What items would be interesting to discuss on a potential BOF? To 
> start off, I personally have the following items to add as
> potential discussion points: - The state of HKPS in GnuPG 2.1 (The
> SNI issue pretty much makes the pool unusable in the current
> state)

s/SNI/PTR/

> - LDAP Support in GnuPG 2.1 (currently not implemented, which
> makes it difficult to work with systems such as Symantec Encryption
> Serve)

Extending on this (and sorry for the typo in "Server" above. Would it
be possible to have a per-domain preferred keyserver in dirmngr for
situations where the key is only updated on a corporate keyserver, but
this does not publish a preferred keyserver as part of the
certificate? (and in the case of discarding these using
no-honor-keyserver-url like restrictions)

> - Standardization of the EdDSA I-D by WK (we already support this
> in the development branch of SKS, but not in any released version)
> 
> 

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Ad astra per aspera
To the stars through thorns
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUu+uZAAoJEPw7F94F4TagYkEQAK58xcntwhof1cuFWwyIRwMe
OVXdIHO/rx6NxxYRCX6a40dxzzmA+BtacypZ1cVIsyDJ06aPGuOX80XB/K9wiNHW
DBLiLA3z39f5v8XMVMuXAAGUuKB/RwoP//gNgEC8iuuYyZ10gEf4RvJa1XI8Bio6
fdSeeaTqdx8vvsrhNdfGFl+W6yTqd0mo1mgGr/0QisuK520k3IJXuQ0jM+ACgowf
r7kiEPiTtE0zOrQmLAvzhbG9oSVaIA6xGi3VCzvQEMcU+ZnpBBX9OjuTodmvcDun
0CK6ZjN2imPAo6KDH6dq4zFBINLpsvJXBMh8gDIHalPTvNIfEBKS7ZLhcedgHRsV
oPbAODvEmOOEHmLg6a4NoT4Raw3bTgp0Ty0p/kXREyX+NxWVWDwgdmNSNLIRzH3h
r2/Kxm9LEdRGLCIrjCLZdbYcI3cu+ovKWGGaef2AN4wCp19kp68fIQm3EZPg+0Ki
H460JpQH2IrSnTziflg1upBwcc9Q0aEgG63/N0GpARbaWTe5M5gnoXWZt+CKalLI
Rce2C5OoM/pOotdaRmxivS+IhiV6l5vQJvxIcVbsWwo4HESASk1u2ajPlCAXBEMF
AvGB4hR7fHjm9hYX8llLFx4g1NnVTC12nVbnIc3DCL+ethmkF3ECVSc3ayNurpOa
MIUi0UWRv2HVyqX65IoM
=x7T4
-----END PGP SIGNATURE-----


From post at filias.name  Mon Jan 19 11:29:39 2015
From: post at filias.name (Filias Heidt)
Date: Mon, 19 Jan 2015 11:29:39 +0100
Subject: Using --gen-key --batch doesn't seem to work anymore
Message-ID: <40E6086C-9CB7-4190-8DD7-CA16C698FD01@filias.name>

Hi List,

I have been using a Script which gets the key ID via
/usr/local/bin/gpg --list-keys root@ | grep -B1 'backup-key' | sed -n 's/pub.*\/\([:alnum:]*\)/\1/p' | cut -d' ' -f1

and if there is no key ID found, it tries to generate a key via
/usr/local/bin/gpg --gen-key --batch < /root/gpg_config 2>&1 | cut -d' ' -f3 | tail -n1

the gpg_config file is looking like this:

Key-Type: default
Subkey-Type: default
Name-Real: $hostname
Name-Comment: backup-key for $hostname
Name-Email: root@$hostname
Expire-Date: 0
Passphrase: secret
%commit

Somehow, since the last update, the key Generation does not work anymore. If I try to execute that exact step on the command line, I get:
# gpg -vv --gen-key --batch < gpg_config
gpg: agent_genkey failed: Operation cancelled
gpg: key generation failed: Operation cancelled

I put a line in the .gnupg/gpg-agent.conf, because I thought it might have to do something with the Agent:
allow-loopback-pinentry

I must say, my experiences with gnupg are very limited, so I can simply miss something. Is there an obvious reason why this fails?
Some help would be greatly appreciated.

Greetings,
Filias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150119/e6a22d39/attachment.sig>

From wk at gnupg.org  Mon Jan 19 13:54:01 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 19 Jan 2015 13:54:01 +0100
Subject: Using --gen-key --batch doesn't seem to work anymore
In-Reply-To: <40E6086C-9CB7-4190-8DD7-CA16C698FD01@filias.name> (Filias
 Heidt's message of "Mon, 19 Jan 2015 11:29:39 +0100")
References: <40E6086C-9CB7-4190-8DD7-CA16C698FD01@filias.name>
Message-ID: <87bnlvue1i.fsf@vigenere.g10code.de>

Hi,

[I assume this is about 2.1]

On Mon, 19 Jan 2015 11:29, post at filias.name said:

> Passphrase: secret

That is not supported in 2.1.1 but will be support again in 2.1.2.

> # gpg -vv --gen-key --batch < gpg_config
> gpg: agent_genkey failed: Operation cancelled

Do you have a pinentry installed?  Try adding --pinentry-mode=loopback
to gpg.conf or put it on the command line.


Salam-Shalom,

   Werner


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



From georgeorwellhardwired at riseup.net  Tue Jan 20 09:52:54 2015
From: georgeorwellhardwired at riseup.net (georgeorwellhardwired at riseup.net)
Date: Tue, 20 Jan 2015 08:52:54 +0000
Subject: Not only in GPA, but all GPG client isn't functioning in ubuntu.
Message-ID: <dde1014614c1cdc41160e96d8f017c90@riseup.net>

Dear GPG devs and users.

Like I've posted before, I have had problems with GPA. On Thu 2015-01-15 
05:42:20 -0500, georgeorwellhardwired at riseup.net wrote:

     Every time I use GPA in ubuntu it says, when I start GPA: "GnuPG is 
rebuilding the trust database. This might take a few seconds." And I can 
wait for hours, while nothing happens.

But it is not only the GPA client for GPG that isn't working in ubuntu, 
it's all GnuGpgg clients.

Here is what the other clients is showing me, when opening and trying to 
generate pgp clients:

The Kleopatra GPG UI Server Module could not be initialized.
The error given was: Could not bind to socket: Permission denied
You can use Kleopatra as a certificate manager, but cryptographic 
plugins that rely on a GPG UI Server being present might not work 
correctly, or at all.

Gnupg failed to start. You must fix the GnuPG error first before running 
Kgpg.  Error in Kgpg.

Couldn't generate PGP key. General error. In seahorse GPG manager 
password and keys.

And I know I'm not the only one that have had these problems.


From post at filias.name  Tue Jan 20 10:49:38 2015
From: post at filias.name (Filias Heidt)
Date: Tue, 20 Jan 2015 10:49:38 +0100
Subject: Using --gen-key --batch doesn't seem to work anymore
In-Reply-To: <87bnlvue1i.fsf@vigenere.g10code.de>
References: <40E6086C-9CB7-4190-8DD7-CA16C698FD01@filias.name>
 <87bnlvue1i.fsf@vigenere.g10code.de>
Message-ID: <170882FD-AFE8-4814-96FF-10AFF1051A73@filias.name>


> Am 19.01.2015 um 13:54 schrieb Werner Koch <wk at gnupg.org>:
> 
> Hi,
> 
> [I assume this is about 2.1]

You are right :)

> 
> On Mon, 19 Jan 2015 11:29, post at filias.name said:
> 
>> Passphrase: secret
> 
> That is not supported in 2.1.1 but will be support again in 2.1.2.

Any idea, when 2.1.2 will be ready?

> 
>> # gpg -vv --gen-key --batch < gpg_config
>> gpg: agent_genkey failed: Operation cancelled
> 
> Do you have a pinentry installed?  Try adding --pinentry-mode=loopback
> to gpg.conf or put it on the command line.

I have a pinentry installed, yes. When I add ?pin entry-mode=loopback, it gives
gpg: Sorry, we are in batchmode - can't get input

Cheerio,
Filias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150120/6fa4fec7/attachment.sig>

From wk at gnupg.org  Tue Jan 20 16:34:36 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Jan 2015 16:34:36 +0100
Subject: Not only in GPA, but all GPG client isn't functioning in ubuntu.
In-Reply-To: <dde1014614c1cdc41160e96d8f017c90@riseup.net>
 (georgeorwellhardwired@riseup.net's message of "Tue, 20 Jan 2015
 08:52:54 +0000")
References: <dde1014614c1cdc41160e96d8f017c90@riseup.net>
Message-ID: <871tmpqxdf.fsf@vigenere.g10code.de>

On Tue, 20 Jan 2015 09:52, georgeorwellhardwired at riseup.net said:

>     Every time I use GPA in ubuntu it says, when I start GPA: "GnuPG
> is rebuilding the trust database. This might take a few seconds." And
> I can wait for hours, while nothing happens.

Please run gpg on the command line to see what is going on:

  gpg -v -k >/dev/null

shows just the diagnostics.  Without the ">/dev/null" you will see all
your keys.

Does that work or is there a strange error message?  What is the output
of

  gpg --version

?


Salam-Shalom,

   Werner

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



From 4tmuelle at informatik.uni-hamburg.de  Tue Jan 20 17:39:00 2015
From: 4tmuelle at informatik.uni-hamburg.de (Tobias Mueller)
Date: Tue, 20 Jan 2015 17:39:00 +0100
Subject: Sign key and export for each UID
In-Reply-To: <547DA3E2.1000605@robinmathewrajan.com>
References: <CAN0Qxusqvvq_cD3U=Nazxqhym3E_S26dRw1qAzzbhEMvx9wmoQ@mail.gmail.com>
 <52375480.7020606@dougbarton.us>
 <CAN0QxuvWG+qsH90U4bYTng_CBLctmYoDji_Yq1zOTzHn25CT7w@mail.gmail.com>
 <20141202083551.GA22694@cryptobitch.de>
 <547DA3E2.1000605@robinmathewrajan.com>
Message-ID: <20150120163900.GL4822@cryptobitch.de>

Hi.

On Tue, Dec 02, 2014 at 05:04:58PM +0530, Robin Mathew Rajan wrote:
> This shell script might help you.
> [...]
> http://mirror.roe.ch/rel/scripts/gpg/gpg-sign-keys.sh-25
hm.  I understood that best practises include signing each UID
separately rather than signing all UIDs on the key.  I don't see your
script signing every UID separately.

I was also hoping for less shell script and more of something I could
dictate to my mom over the phone.

Cheers,
  Tobi

> On 02-12-2014 PM 02:05, Tobias Mueller wrote:
> > Hi.
> > 
> > I'm digging up this thread because it asked the same question I have,
> > but it hasn't really been answered:
> > 
> > On Tue, Sep 17, 2013 at 06:23:35AM +0000, atair wrote:
> >> Is there a way to achieve the same signatures from gpg command line?
> >> For example
> >> $ gpg -a --export <uid>
> >> exports the complete key and not just the signature. However, I
> >> understand the gpg-man pages in a way that it's possible to do a
> >> $ gpg -u <my_keyid> --edit-key <other's_keyid>
> >>> sign <other's_first_uid>
> >>> sign <other's_second_uid>
> >>> ...
> >>> q
> > 
> > What are the best practises for signing another person's key (i.e. all the UIDs 
> > on a key)?
> > 
> > And how do you follow those using gnupg?  And is there a batch mode to automate that process?
> > 
> > Cheers,
> >   Tobi
> > 


From dkg at fifthhorseman.net  Wed Jan 21 03:36:49 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 21:36:49 -0500
Subject: different passwords for subkeys of the same masterkey
In-Reply-To: <54B3E4AC.80202@sky-ip.org>
References: <54B3E4AC.80202@sky-ip.org>
Message-ID: <87y4owuaf2.fsf@alice.fifthhorseman.net>

On Mon 2015-01-12 10:13:48 -0500, s7r wrote:
> Is it possible to have one masterkey with two subkeys (sbind), one for
> encrypt only and one for sign only, and each of them to have different
> passphrases?

Yes, it is possible.  with gpg 2.1, you can create new subkeys and give
each of them a different passphrase.  I haven't tested with 1.4 or 2.0.

> Additionally, how can I select in enigmail which userID I want to sign
> when signing a key with multiple UserIDs? I do not want to sign the
> primary one. Enigmail just offers me the ability to 'sign key',
> nothing said about UserID, just lets me select either normal signature
> or local signature not exportable.

The thing that you're signing with is a key.  it's either your primary
key, or a signing-capable subkey.  Your User IDs are all associated with
your primary directly (and with your subkeys indirectly, through the
primary key).

The OpenPGP standard defines a way to embed the preferred user ID in a
given signature using a "signer's user ID" subpacket [0], but it has
several drawbacks:

 * i'm not sure how to do it in GnuPG, which enigmail relies on for the
   OpenPGP parts, and

 * it's not clear what a receiving MUA should do with that information,
   even if it was present.

So i don't think this is a feature request that makes a lot of sense,
really.  Can you explain more what you'd hope to gain from such a
configuration?

   --dkg

[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.22


From dkg at fifthhorseman.net  Wed Jan 21 04:31:34 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 22:31:34 -0500
Subject: gpg-connect-agent querying max-cache-ttl
In-Reply-To: <effa331a9eb84a469bfe9bdb9f41b3fe@RDRE1-PEXCH02.rsd.crumprsd.com>
References: <effa331a9eb84a469bfe9bdb9f41b3fe@RDRE1-PEXCH02.rsd.crumprsd.com>
Message-ID: <87lhkwu7vt.fsf@alice.fifthhorseman.net>

On Fri 2015-01-09 15:24:39 -0500, Rob Fries wrote:

> Basically, I have stand alone system where files are automatically
> encrypted and decrypted for processing. This is currently setup using
> quintuple-agent, but we want to use something which is maintained.  I
> am looking to use gpg-agent to store the passphrase, which is entered
> using gpg-preset-passphrase. This all works perfectly other than
> max-cache-ttl removing the passphrase.
>
> I am looking for a way to query the max-cache-ttl time for gpg-agent
> so I can have an alert as this time approaches.  This will give me a
> heads up before I need to enter a passphrase with
> gpg-preset-passphrase so it can be planned for an optimal time.
>
> I know there are ways to query some information from gpg-agent with
> gpg-connect-agent, but I have not found any central documentation on
> how to query this.

You might be interested the command-line tool gpgconf.

For example:

   gpgconf --list-options gpg-agent | grep '^max-cache-ttl:'


the gpgconf(1) manual page has more details.

hth,

        --dkg


From dkg at fifthhorseman.net  Wed Jan 21 05:52:24 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 20 Jan 2015 23:52:24 -0500
Subject: lock-obj-pub.arm-none-linux-gnueabi.h
In-Reply-To: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
References: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
Message-ID: <874mrku453.fsf@alice.fifthhorseman.net>

On Sun 2015-01-04 08:28:13 -0500, Rajagopal Aravindan wrote:

> I was successfully able to compile libgpg-error-1.17 for my ARM with the
> attached file.
> The attached file was generated by following the instructions in the
> README, which also suggested sharing it back with the group and hence this
> mail.
> PFB the details of my ARM compiler as well as my target platform.
> Please let me know if any more details would be needed from my side, to
> include this in your next release.
>
> Thanks,
> Rajagopal
>
>
> *[root at FriendlyARM ~]# uname -aLinux FriendlyARM 3.5.0-FriendlyARM #1 SMP
> PREEMPT Tue Dec 23 17:38:40 IST 2014 armv7l GNU/Linux*
> *~/Downloads/libgpg-error-1.17$ arm-none-linux-gnueabi-gcc -v*

Interesting.  This seems to be identical to the already-present
src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h -- do we actually
need both?

     --dkg


From wk at gnupg.org  Wed Jan 21 10:11:32 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jan 2015 10:11:32 +0100
Subject: lock-obj-pub.arm-none-linux-gnueabi.h
In-Reply-To: <874mrku453.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's
 message of "Tue, 20 Jan 2015 23:52:24 -0500")
References: <CAEQQSVs9HHkGMTQm=BtxQCHDaaVFAyhj+PRYc+B3HZxo8pbeAQ@mail.gmail.com>
 <874mrku453.fsf@alice.fifthhorseman.net>
Message-ID: <87sif4o5vf.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 05:52, dkg at fifthhorseman.net said:

>> *[root at FriendlyARM ~]# uname -aLinux FriendlyARM 3.5.0-FriendlyARM #1 SMP
>> PREEMPT Tue Dec 23 17:38:40 IST 2014 armv7l GNU/Linux*
>> *~/Downloads/libgpg-error-1.17$ arm-none-linux-gnueabi-gcc -v*
>
> Interesting.  This seems to be identical to the already-present
> src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h -- do we actually
> need both?

config.sub from 2015-01-01 does not yet know

  arm-none-linux-gnueabi

thus we should first get support for it in config.{guess,sub}


Salam-Shalom,

   Werner

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



From s7r at sky-ip.org  Wed Jan 21 11:58:40 2015
From: s7r at sky-ip.org (s7r)
Date: Wed, 21 Jan 2015 12:58:40 +0200
Subject: different passwords for subkeys of the same masterkey
In-Reply-To: <87y4owuaf2.fsf@alice.fifthhorseman.net>
References: <54B3E4AC.80202@sky-ip.org>
 <87y4owuaf2.fsf@alice.fifthhorseman.net>
Message-ID: <54BF8660.7060700@sky-ip.org>

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

Thank you very much for your reply.
Please see my comments below in the replied text:

On 1/21/2015 4:36 AM, Daniel Kahn Gillmor wrote:
> On Mon 2015-01-12 10:13:48 -0500, s7r wrote:
>> Is it possible to have one masterkey with two subkeys (sbind),
>> one for encrypt only and one for sign only, and each of them to
>> have different passphrases?
> 
> Yes, it is possible.  with gpg 2.1, you can create new subkeys and
> give each of them a different passphrase.  I haven't tested with
> 1.4 or 2.0.
> 
Understood. I guess this has to be done via console commands, since
the pour enigmail thundebird addon has very limited options when
creating/editing a GPG key.

I have 2 masterkeys, each with a subkey. Any way I can merge them
together so I would have one primary key and 3 subkeys?

>> Additionally, how can I select in enigmail which userID I want to
>> sign when signing a key with multiple UserIDs? I do not want to
>> sign the primary one. Enigmail just offers me the ability to
>> 'sign key', nothing said about UserID, just lets me select either
>> normal signature or local signature not exportable.
> 
> The thing that you're signing with is a key.  it's either your
> primary key, or a signing-capable subkey.  Your User IDs are all
> associated with your primary directly (and with your subkeys
> indirectly, through the primary key).
> 

I guess my question was not clear - sorry about it. I can see multiple
flags for the keys: Sign, Encrypt, Certify. I guess the Certify flag
matters when signing another GPG key and Sign is used for signing text?

I have the public key of John Doe <john.doe at example.com> . He has more
UserIDs associated with the same masterkey, as follows:
John Doe <john.doe at example.com>
John Smith <john.smith at foo.com>
Bob Jones <bob.jones at test.net>
Primary UserID is John Doe <john.doe at example.com>

I want to sign this key, but just to confirm the UserID John Smith
<john.smith at foo.com> and not sign/certify his other UserIDs belonging
to the same key. Is this possible?

> The OpenPGP standard defines a way to embed the preferred user ID
> in a given signature using a "signer's user ID" subpacket [0], but
> it has several drawbacks:
> 
> * i'm not sure how to do it in GnuPG, which enigmail relies on for
> the OpenPGP parts, and
> 
> * it's not clear what a receiving MUA should do with that
> information, even if it was present.
> 
> So i don't think this is a feature request that makes a lot of
> sense, really.  Can you explain more what you'd hope to gain from
> such a configuration?
> 
> --dkg
> 
> [0] https://tools.ietf.org/html/rfc4880#section-5.2.3.22
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJUv4ZgAAoJEIN/pSyBJlsR8GoH/A+cX/JTltpd684ihWMdPPAD
RkUJIqRaf5EWv4PZuNRbtSzL52ZFmi46dYRkiEUvg0PUeLo8so3Qoi4SEAzIL6Qf
+k59YyfiSM3hX658PGgJLwBGTAIZ/ggULuJ3/5tJbfgfxKStCJeNZBzxnJGuImTr
+q9j1NcJCjqe3FbOOSl0HYbh7agCh2WYTbdD8KrhcukHuRnzkTXim6QZlEWGBwJ5
MLKBJjELb2lVsE5WSoVtu4SdbIaSNTY07NgKl5wGykZ+2NofQzvJ1DI9VEbwl9h/
vXJQQjXN1J+d7jHHPyLvIraOd006hvbiqJvm5Bzi5+BobHwr8QGzhA0bluG3Yk8=
=ra6A
-----END PGP SIGNATURE-----


From wk at gnupg.org  Wed Jan 21 16:34:56 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 21 Jan 2015 16:34:56 +0100
Subject: different passwords for subkeys of the same masterkey
In-Reply-To: <54BF8660.7060700@sky-ip.org> (s7r@sky-ip.org's message of "Wed, 
 21 Jan 2015 12:58:40 +0200")
References: <54B3E4AC.80202@sky-ip.org>
 <87y4owuaf2.fsf@alice.fifthhorseman.net> <54BF8660.7060700@sky-ip.org>
Message-ID: <874mrkno4f.fsf@vigenere.g10code.de>

On Wed, 21 Jan 2015 11:58, s7r at sky-ip.org said:

> I have 2 masterkeys, each with a subkey. Any way I can merge them
> together so I would have one primary key and 3 subkeys?

With < 2.1 this is quite some work.  With 2.1 it is easier.  Here is an
example.  First list the key with the subkey you want to copy:

--8<---------------cut here---------------start------------->8---
   $ gpg -K --with-keygrip 13
   sec   rsa2048/F72E9C69 2015-01-21
         Keygrip = ED60EEB08BEA7EFF7DD9E177576BA748CD65A932
   uid       [ unknown] Test user 13
   ssb   rsa2048/3CA551D2 2015-01-21
         Keygrip = B511C4A66607FC68CDD382BC8A5024AED8BBE89F
--8<---------------cut here---------------end--------------->8---
   
Then edit the other key:
   
--8<---------------cut here---------------start------------->8---
   $ gpg --edit-key 12
   Secret key is available.
   
   pub  rsa2048/002D4B6C
        created: 2015-01-21  expires: never       usage: SC  
        trust: ultimate      validity: unknown
   sub  rsa2048/0C099D87
        created: 2015-01-21  expires: never       usage: E   
   [ unknown] (1). Test user 12
--8<---------------cut here---------------end--------------->8---

Now enter the addkey command and select "Existing key"
   
--8<---------------cut here---------------start------------->8---
   gpg> addkey
   Please select what kind of key you want:
      (3) DSA (sign only)
      (4) RSA (sign only)
      (5) Elgamal (encrypt only)
      (6) RSA (encrypt only)
      (7) DSA (set your own capabilities)
      (8) RSA (set your own capabilities)
     (10) ECC (sign only)
     (11) ECC (set your own capabilities)
     (12) ECC (encrypt only)
     (13) Existing key
   Your selection? 13
   Enter the keygrip: B511C4A66607FC68CDD382BC8A5024AED8BBE89F
--8<---------------cut here---------------end--------------->8---

The keygrip you entered is the one from the subkey.  Now gpg-agent does
not store the key flags - you have set them yourself:
   
--8<---------------cut here---------------start------------->8---
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Sign Encrypt 
   
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   
   Your selection? s
   
   Possible actions for a RSA key: Sign Encrypt Authenticate 
   Current allowed actions: Encrypt 
   
      (S) Toggle the sign capability
      (E) Toggle the encrypt capability
      (A) Toggle the authenticate capability
      (Q) Finished
   
   Your selection? q
   Please specify how long the key should be valid.
            0 = key does not expire
         <n>  = key expires in n days
         <n>w = key expires in n weeks
         <n>m = key expires in n months
         <n>y = key expires in n years
   Key is valid for? (0) 
   Key does not expire at all
   Is this correct? (y/N) y
   Really create? (y/N) y
   
   pub  rsa2048/002D4B6C
        created: 2015-01-21  expires: never       usage: SC  
        trust: ultimate      validity: unknown
   sub  rsa2048/0C099D87
        created: 2015-01-21  expires: never       usage: E   
   sub  rsa2048/B348AB71
        created: 2015-01-21  expires: never       usage: E   
   [ unknown] (1). Test user 12
   
   gpg> save
--8<---------------cut here---------------end--------------->8---

After the "save" command you are done.  Now check what happened:
   
--8<---------------cut here---------------start------------->8---
   $ gpg -K --with-keygrip 12 13                    
   sec   rsa2048/002D4B6C 2015-01-21
         Keygrip = 1CEAA2DB62271554D78F62CC9B0F1DBB261A059C
   uid       [ unknown] Test user 12
   ssb   rsa2048/0C099D87 2015-01-21
         Keygrip = 80142CB717FABD2924F8B27B37779FF557B82D38
   ssb   rsa2048/B348AB71 2015-01-21
         Keygrip = B511C4A66607FC68CDD382BC8A5024AED8BBE89F
   
   sec   rsa2048/F72E9C69 2015-01-21
         Keygrip = ED60EEB08BEA7EFF7DD9E177576BA748CD65A932
   uid       [ unknown] Test user 13
   ssb   rsa2048/3CA551D2 2015-01-21
         Keygrip = B511C4A66607FC68CDD382BC8A5024AED8BBE89F
   

--8<---------------cut here---------------end--------------->8---

The key of test user 12 now has an additional subkey and that subkey is
the same as the subkey from key 13 (compare the keygrips).

Note that the keyids are still different.  The reasons for this is that
the key id also depends on the creation date.  To fix this you could
have figured out the full creation time of the key (using --with-colons)
and invoked gpg like

  gpg --faked-system-time 20150121T123456 --edit-key 12


> flags for the keys: Sign, Encrypt, Certify. I guess the Certify flag
> matters when signing another GPG key and Sign is used for signing text?

It is basically ignored.  Only the primary key can be used to sign
(certify) user ids or subkeys.


Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Wed Jan 21 16:50:56 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 21 Jan 2015 10:50:56 -0500
Subject: different passwords for subkeys of the same masterkey
In-Reply-To: <54BF8660.7060700@sky-ip.org>
References: <54B3E4AC.80202@sky-ip.org>
 <87y4owuaf2.fsf@alice.fifthhorseman.net> <54BF8660.7060700@sky-ip.org>
Message-ID: <87h9vkrv33.fsf@alice.fifthhorseman.net>

On Wed 2015-01-21 05:58:40 -0500, s7r wrote:
> Understood. I guess this has to be done via console commands, since
> the pour enigmail thundebird addon has very limited options when
> creating/editing a GPG key.

yes, what you're trying to do is rather unusual; enigmail intends to
deliver a smooth and easy experience for the common use case.  It would
be a mistake for enigmail to try to expose something like this.

> I have 2 masterkeys, each with a subkey. Any way I can merge them
> together so I would have one primary key and 3 subkeys?

I don't recommend doing so directly, no.  Your best bet is to simply
choose one of your keys that you want to use going forward; add two new
subkeys to that key; and then set a short expiration date on the other
one or explicitly revoke it.

>>> Additionally, how can I select in enigmail which userID I want to
>>> sign when signing a key with multiple UserIDs? I do not want to
>>> sign the primary one. Enigmail just offers me the ability to
>>> 'sign key', nothing said about UserID, just lets me select either
>>> normal signature or local signature not exportable.
>> 
>> The thing that you're signing with is a key.  it's either your
>> primary key, or a signing-capable subkey.  Your User IDs are all
>> associated with your primary directly (and with your subkeys
>> indirectly, through the primary key).
>> 
>
> I guess my question was not clear - sorry about it. I can see multiple
> flags for the keys: Sign, Encrypt, Certify. I guess the Certify flag
> matters when signing another GPG key and Sign is used for signing text?

yes, this is right.  Sorry that i misunderstood your question.

> I have the public key of John Doe <john.doe at example.com> . He has more
> UserIDs associated with the same masterkey, as follows:
> John Doe <john.doe at example.com>
> John Smith <john.smith at foo.com>
> Bob Jones <bob.jones at test.net>
> Primary UserID is John Doe <john.doe at example.com>
>
> I want to sign this key, but just to confirm the UserID John Smith
> <john.smith at foo.com> and not sign/certify his other UserIDs belonging
> to the same key. Is this possible?

This is a really good point, and i hadn't looked at the enigmail
keysigning experience that way.  I note that you're mailing the
gnupg-users mailing list about this, though, and it's really a question
of the enigmail interface.  GnuPG itself does let the user select which
User IDs to certify during keysigning.

It's probably best to continue this discussion on the enigmail mailing
list (cc'ed here).

I've just filed https://sourceforge.net/p/enigmail/bugs/388/ to track
the problem.  Feel free to follow up there as well.

Regards,

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

From faramir.cl at gmail.com  Wed Jan 21 23:46:29 2015
From: faramir.cl at gmail.com (Faramir)
Date: Wed, 21 Jan 2015 19:46:29 -0300
Subject: different passwords for subkeys of the same masterkey
In-Reply-To: <54BF8660.7060700@sky-ip.org>
References: <54B3E4AC.80202@sky-ip.org>
 <87y4owuaf2.fsf@alice.fifthhorseman.net> <54BF8660.7060700@sky-ip.org>
Message-ID: <54C02C45.8060804@gmail.com>

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

Hello,

El 21-01-2015 a las 7:58, s7r escribi?:
> Thank you very much for your reply.

...
> I have the public key of John Doe <john.doe at example.com> . He has
> more UserIDs associated with the same masterkey, as follows: John
> Doe <john.doe at example.com> John Smith <john.smith at foo.com> Bob
> Jones <bob.jones at test.net> Primary UserID is John Doe
> <john.doe at example.com>
> 
> I want to sign this key, but just to confirm the UserID John Smith 
> <john.smith at foo.com> and not sign/certify his other UserIDs
> belonging to the same key. Is this possible?

  Yes, using the command line, but I'm not sure what are the commands
involved, since I use a GUI that lets me select the key I want to
sign, and the key I want to use to issue the signature (after that,
the GUI invokes GPG, gives it the command and parameters and let you
continue the process using GPG on the command line), you will have to
check the manual to figure out how to do that from command line. Once
you get there, you will get a screen asking if you are sure you want
to sign all the UIDs, if you say NO, it will suggest you to select the
UIDs you want to sign (you will notice each UID is numbered from 1 to
n). Enter the number of a UID to select it, press enter, and then you
can either select another, or enter the sign (or lsign for local
signatures, or tsign for trust signatures) command and follow the
dialog to complete the signature process. I don't remember, but I
think you may need to end with the SAVE command to save the changes to
the key. It's been a long time since I signed a key.

  Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJUwCxFAAoJEMV4f6PvczxAr1AH/jQA69wZb9IMDt9k2hvGq/5B
zjC32PtYL8doLM8O9KwBdKPMTS7GulaZCKLKgcMqe/vvCnY3imhBs6cST+vVIjvI
+saqkwA2yu28V1cjw1ncBFvopTvdiT8MIDwv30wusrYMEq+iL6gLuZSPmUnnFQxB
Nx+r3gf6sEnI45HHPaeyMleCUIw/aPMzkRtjJMYgfYJ247HvvDzUPk2ho/n8dn75
fAudm1HmXav4nvZvs9FmoMttLLx4P+j9BrJZKdIVtbzqwanAbJBOukP87BGsvUiE
yj3pn7RwhKPHYXbNgz/8yDQvIrDt9csCn2blyP7lU8b6owUxPGCpVBZ687D4zSw=
=htf7
-----END PGP SIGNATURE-----


From Rrouse at mwe.com  Wed Jan 21 22:59:55 2015
From: Rrouse at mwe.com (Rouse, Robert)
Date: Wed, 21 Jan 2015 21:59:55 +0000
Subject: excavating an existing installation
Message-ID: <1BD5DA3E04602845B1C5B5459CBB20EBFFD996@LISMBX18.na.lan.mwe.com>

I have taken over administration of a system that uses GnuPG to encrypt a few data feeds sent to outside vendors. The person who set it up is long gone, so I have no idea what was used for secret keys. The only public keys I am aware of are because they used via the "-recipient" option.

We are moving this to a new server, so I need to be able to set this up "as is" on a new server. I also need to create new keys.

What can I do to "reverse engineer" the current setup?

Thanks,

Bob


*******************************************************************************************************************
This message is a PRIVILEGED AND CONFIDENTIAL communication. This message and all attachments are a private communication sent by a law firm and may be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you.
*******************************************************************************************************************

Please visit http://www.mwe.com/ for more information about our Firm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150121/8378bb3b/attachment-0001.html>

From hidekis at gmail.com  Thu Jan 22 01:00:38 2015
From: hidekis at gmail.com (Hideki Saito)
Date: Wed, 21 Jan 2015 16:00:38 -0800
Subject: Can't import private key to GnuPG 2.1.1 on Windows 8 x64
In-Reply-To: <54A6A2F8.4050203@graffen.dk> (Jesper Hess Nielsen's message of
 "Fri, 02 Jan 2015 14:54:00 +0100")
References: <54A673EB.3060907@graffen.dk> <87h9w9fjwo.fsf@vigenere.g10code.de>
 <54A6A2F8.4050203@graffen.dk>
Message-ID: <87zj9b1y6x.fsf@madoka.hidekisaito.com>

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

Also I'd like to add that this seems to affect when generating new key
as well. Here's the log below. (Seen on Windows 8.1 on x64)

It prompts for passphrases, however gives up on me with the mesage below
after continuing after entering passphrases:

gpg: agent_genkey failed: End of file
Key generation failed: End of file

What left on Windows event viewer is consistent with what Jesper stated earlier.

2015-01-21 15:53:08 gpg-agent[404] listening on socket 'C:/Users/hsaito/AppData/Roaming/gnupg/S.gpg-agent'
2015-01-21 15:53:08 gpg-agent[404] gpg-agent (GnuPG) 2.1.1 started
2015-01-21 15:53:10 gpg-agent[404] handler 0x2 for fd 320 started
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK Pleased to meet you
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- RESET
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- OPTION allow-pinentry-notify
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- OPTION agent-awareness=2.1.0
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- AGENT_ID
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> ERR 67109139 Unknown IPC command <GPG Agent>
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- RESET
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- GENKEY
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> S INQUIRE_MAXLEN 1024
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> INQUIRE KEYPARAM
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- D (genkey(rsa(nbits 4:2048)))
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:10 gpg-agent[404] starting a new PIN Entry
2015-01-21 15:53:10 gpg-agent[404] DBG: connection to PIN entry established
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> INQUIRE PINENTRY_LAUNCHED 2920
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:16 gpg-agent[404] starting a new PIN Entry
2015-01-21 15:53:16 gpg-agent[404] DBG: connection to PIN entry established
2015-01-21 15:53:16 gpg-agent[404] DBG: chan_00000140 -> INQUIRE PINENTRY_LAUNCHED 5744
2015-01-21 15:53:16 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:20 gpg-agent[404] S2K calibration: 4904960 -> 93ms


- -- 
Hideki Saito
OpenPGP Key: http://hidekisaito.com/aff2e40b.txt
1066 3928 7B0B E7CD A0CB  3686 1FDF D937 AFF2 E40B
http://hidekisaito.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIiBAEBCAAMBQJUwD2yBYMSzAMAAAoJEOIIPMPrC7kZ8mUP/0K0aiK6FYVYQdgA
l14UknEmmZJ7T5sRCaii/2JITNS9UIMjEx14fGkHkA7WY5bFxg+sTIDc7roZBaM5
DcBqE+T0epSQoM/a0yLce9/usx2L4iDOtk/Zd+0XPAOfDraKSMAlrtADQ+se53lg
jE3mIF19dDVNBjfHc46FYbhtEWlQ2Fyrk51OQlpfNRnndjPhMld9+ciS0TDgW2mP
XTj7s2t2VJsNjhI1XPlVTK4PckEUWXMYfB1hKFznZIYTcj37oBEVuZ0peIbj3c0H
pCbKxaREm4UqhiFjIwcXdk0KbycgQ1jPR2EQNdv/t+lczb8xv/6f7ZgUeeUWs79k
+s9ZwU6v0mdHWLkhmXO4GRs32Hq26ojF8alcFjQ/i16Pr6bmcaH81WNl8Y2fneqF
U/2s6924c43xEJG5diCShlyR0LqBW1NN8SddciIlXw70uXCirEPalbngmHornDj5
KYEt5r660qGJutxxr4RzC45MPr/gKIfi/ISpsXqF1OZ/87j0r6p3BUipN1P4lU8y
v2Ycbz5ugjiMRGnYVwdr3WkpAkLqzDenzKRF4drmuTt4HKtcy/7kOUXEBVlRDTPu
COuO/cBvs2/PydzB2QKfeVf2IUElWoNGWUpaLH8UbMKSj6+fUls8IhRl0+HBNzuL
hBwD/CUm859cW+Ozr+vZuLOnAR7X
=vqRZ
-----END PGP SIGNATURE-----


From jesper at graffen.dk  Thu Jan 22 09:01:22 2015
From: jesper at graffen.dk (jesper at graffen.dk)
Date: Thu, 22 Jan 2015 08:01:22 +0000
Subject: =?utf-8?Q?Re:_Can't_import_private_key_to_GnuPG_2.1.1_on_Windows_8_x64?=
In-Reply-To: <87zj9b1y6x.fsf@madoka.hidekisaito.com>
References: <54A673EB.3060907@graffen.dk> <87h9w9fjwo.fsf@vigenere.g10code.de>
 <54A6A2F8.4050203@graffen.dk>,<87zj9b1y6x.fsf@madoka.hidekisaito.com>
Message-ID: <20150122080210.BED536015E1@mail.ffen.dk>

I?ve been having the same problem. No solution yet ?






/Jesper





From: Hideki Saito
Sent: ?Thursday?, ?January? ?22?, ?2015 ?01?:?00
To: gnupg-users at gnupg.org
Cc: Jesper Hess Nielsen





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

Also I'd like to add that this seems to affect when generating new key
as well. Here's the log below. (Seen on Windows 8.1 on x64)

It prompts for passphrases, however gives up on me with the mesage below
after continuing after entering passphrases:

gpg: agent_genkey failed: End of file
Key generation failed: End of file

What left on Windows event viewer is consistent with what Jesper stated earlier.

2015-01-21 15:53:08 gpg-agent[404] listening on socket 'C:/Users/hsaito/AppData/Roaming/gnupg/S.gpg-agent'
2015-01-21 15:53:08 gpg-agent[404] gpg-agent (GnuPG) 2.1.1 started
2015-01-21 15:53:10 gpg-agent[404] handler 0x2 for fd 320 started
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK Pleased to meet you
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- RESET
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- OPTION allow-pinentry-notify
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- OPTION agent-awareness=2.1.0
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- AGENT_ID
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> ERR 67109139 Unknown IPC command <GPG Agent>
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- RESET
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> OK
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- GENKEY
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> S INQUIRE_MAXLEN 1024
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> INQUIRE KEYPARAM
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- D (genkey(rsa(nbits 4:2048)))
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:10 gpg-agent[404] starting a new PIN Entry
2015-01-21 15:53:10 gpg-agent[404] DBG: connection to PIN entry established
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 -> INQUIRE PINENTRY_LAUNCHED 2920
2015-01-21 15:53:10 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:16 gpg-agent[404] starting a new PIN Entry
2015-01-21 15:53:16 gpg-agent[404] DBG: connection to PIN entry established
2015-01-21 15:53:16 gpg-agent[404] DBG: chan_00000140 -> INQUIRE PINENTRY_LAUNCHED 5744
2015-01-21 15:53:16 gpg-agent[404] DBG: chan_00000140 <- END
2015-01-21 15:53:20 gpg-agent[404] S2K calibration: 4904960 -> 93ms


- -- 
Hideki Saito
OpenPGP Key: http://hidekisaito.com/aff2e40b.txt
1066 3928 7B0B E7CD A0CB  3686 1FDF D937 AFF2 E40B
http://hidekisaito.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIiBAEBCAAMBQJUwD2yBYMSzAMAAAoJEOIIPMPrC7kZ8mUP/0K0aiK6FYVYQdgA
l14UknEmmZJ7T5sRCaii/2JITNS9UIMjEx14fGkHkA7WY5bFxg+sTIDc7roZBaM5
DcBqE+T0epSQoM/a0yLce9/usx2L4iDOtk/Zd+0XPAOfDraKSMAlrtADQ+se53lg
jE3mIF19dDVNBjfHc46FYbhtEWlQ2Fyrk51OQlpfNRnndjPhMld9+ciS0TDgW2mP
XTj7s2t2VJsNjhI1XPlVTK4PckEUWXMYfB1hKFznZIYTcj37oBEVuZ0peIbj3c0H
pCbKxaREm4UqhiFjIwcXdk0KbycgQ1jPR2EQNdv/t+lczb8xv/6f7ZgUeeUWs79k
+s9ZwU6v0mdHWLkhmXO4GRs32Hq26ojF8alcFjQ/i16Pr6bmcaH81WNl8Y2fneqF
U/2s6924c43xEJG5diCShlyR0LqBW1NN8SddciIlXw70uXCirEPalbngmHornDj5
KYEt5r660qGJutxxr4RzC45MPr/gKIfi/ISpsXqF1OZ/87j0r6p3BUipN1P4lU8y
v2Ycbz5ugjiMRGnYVwdr3WkpAkLqzDenzKRF4drmuTt4HKtcy/7kOUXEBVlRDTPu
COuO/cBvs2/PydzB2QKfeVf2IUElWoNGWUpaLH8UbMKSj6+fUls8IhRl0+HBNzuL
hBwD/CUm859cW+Ozr+vZuLOnAR7X
=vqRZ
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150122/3baba340/attachment.html>

From felix.klee at inka.de  Thu Jan 22 18:00:44 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Thu, 22 Jan 2015 17:00:44 +0000
Subject: Crypto device where I need to confirm every operation?
Message-ID: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>

I currently use GnuPG with an OpenPGP Card V2.0 in a smart card reader
with PIN pad. Surely, that adds a certain layer of security, as all
encryption and signing operations happen on the card. However, there
is one attack which I think could be easily prevented: With the card
in the reader, the PIN entered, and Eve having remote access to my
machine, she could sign and decrypt documents.

To prevent such an attack, I imagine a device where I have to confirm
every transaction with a simple push on a hardware button.

Does that exist?


From pete at heypete.com  Thu Jan 22 19:24:40 2015
From: pete at heypete.com (Pete Stephenson)
Date: Thu, 22 Jan 2015 19:24:40 +0100
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
Message-ID: <CA+4dSw5Bi7etkPMpyOK_e0_wpDDFmqSmiXJga6y7r8G_k88sPQ@mail.gmail.com>

On Thu, Jan 22, 2015 at 6:00 PM, Felix E. Klee <felix.klee at inka.de> wrote:
> I currently use GnuPG with an OpenPGP Card V2.0 in a smart card reader
> with PIN pad. Surely, that adds a certain layer of security, as all
> encryption and signing operations happen on the card. However, there
> is one attack which I think could be easily prevented: With the card
> in the reader, the PIN entered, and Eve having remote access to my
> machine, she could sign and decrypt documents.

You can always enable the "forcesig" option, which requires that the
PIN be entered for every signature operation (you can enable by
inserting the card and then running'gpg --card-edit', then entering
'toggle', 'admin', 'forcesig').

I'm not aware of any similar option in regards to decryption.

-- 
Pete Stephenson


From rjh at sixdemonbag.org  Thu Jan 22 19:44:12 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 22 Jan 2015 13:44:12 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
Message-ID: <54C144FC.9060606@sixdemonbag.org>

> To prevent such an attack, I imagine a device where I have to
> confirm every transaction with a simple push on a hardware button.

This attack can't be prevented.

Once the attacker has control over your hardware, you're done.  Game
over.  People keep on trying to invent ways to do crypto even on
compromised hardware, but it's a completely lost cause.  The attacker
has too many options at that point for you to make any sort of effective
defense.

If I were Eve and I wanted to defeat your pushbutton setup, here's what
I'd do:


1.  Figure out exactly your operating system
2.  Figure out which forums you look for help on
3.  Start posting messages on forums for your operating system, saying I
was having problems with your specific card reader and how it wasn't
responding to a pushbutton
4.  Post answers, under a different name, saying this was a known
problem with your model of card reader under the most recent USB driver
update, and that unplugging and replugging the device was usually enough
to reboot the card reader and make it work
5.  Under yet more fake account names, upvote the answer and talk about
how it works for me
6.  Repeat #s 3-5 over several different web forums
7.  A couple of weeks later, subvert your machine
8.  Replace your copy of GnuPG with one that caches the PIN.  When you
enter your PIN and push the button, it silently substitutes my message
for yours.  You sign it, and this compromised GnuPG deposits the signed
message in some hidden file/directory somewhere awaiting my later collection
9.  You'd be understandably concerned.  You'd check web forums and see,
"ah, this bug has been reported by five different people, and a lot of
people are confirming that unplugging and replugging the USB device
solves the problem."
10. You unplug and replug the card reader.  My malware detects the
unplug/replug and uses that as its "clean up and get out of there"
trigger.  It erases itself and leaves behind a clean GnuPG in its wake.
11. You re-try signing your message.  It works correctly.  However,
you've already signed a message of my choosing, and I can pick it up off
your machine at my leisure.


... I understand the wish to make a system that's secure even if the
underlying hardware is compromised.  I really do.  But it's a fantasy.
Can't be done.  Once you lose control over the hardware the attacker has
a near-limitless number of possible attacks, and there's absolutely no
way for you to defend against all of them, or even to effectively
anticipate what it will be.

Please don't tell me how, "well, to defend against your attack I'd
just..."; that misses the point.  The point is there are literally
*hundreds*, if not *thousands*, of attacks like this that could be
levied against you, and there is absolutely no way for you to anticipate
or defend against even a significant fraction of them.

Once you lose control of the hardware, you're done.


From dkg at fifthhorseman.net  Thu Jan 22 21:08:31 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 22 Jan 2015 15:08:31 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
Message-ID: <873872o9xc.fsf@alice.fifthhorseman.net>

On Thu 2015-01-22 12:00:44 -0500, Felix E. Klee wrote:
> I currently use GnuPG with an OpenPGP Card V2.0 in a smart card reader
> with PIN pad. Surely, that adds a certain layer of security, as all
> encryption and signing operations happen on the card. However, there
> is one attack which I think could be easily prevented: With the card
> in the reader, the PIN entered, and Eve having remote access to my
> machine, she could sign and decrypt documents.
>
> To prevent such an attack, I imagine a device where I have to confirm
> every transaction with a simple push on a hardware button.

Yes, this is certainly possible.  I think some of the yuibkey devices
[0] may support this feature, and it should also be possible (with a bit
of hardware hacking) to do it with the FST-01, which is the platform for
the gnuk [1].

[0] https://www.yubico.com/products/yubikey-hardware/yubikey-neo/ -- i
    haven't tested, though!

[1] http://www.fsij.org/category/gnuk.html

If anyone is considering adding this kind of feature to the FST-01, i'd
be happy to test and debug it with them.

   --dkg


From johannes at zarl.at  Thu Jan 22 19:34:51 2015
From: johannes at zarl.at (Johannes Zarl)
Date: Thu, 22 Jan 2015 19:34:51 +0100
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
Message-ID: <2030060.eh0tmPdXvE@mani>

On Thursday 22 January 2015 17:00:44 Felix E. Klee wrote:
> However, there
> is one attack which I think could be easily prevented: With the card
> in the reader, the PIN entered, and Eve having remote access to my
> machine, she could sign and decrypt documents.

Are you sure? On my setup, the smartcard seems to only allow one sign 
operation per pin-entry. Decryption, on the other hand seems to be allowed 
without re-authorisation until the card has been removed from the reader (or 
until it has been reset by another means).




From ndk.clanbo at gmail.com  Thu Jan 22 22:28:06 2015
From: ndk.clanbo at gmail.com (NdK)
Date: Thu, 22 Jan 2015 22:28:06 +0100
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <873872o9xc.fsf@alice.fifthhorseman.net>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <873872o9xc.fsf@alice.fifthhorseman.net>
Message-ID: <54C16B66.5030602@gmail.com>

Il 22/01/2015 21:08, Daniel Kahn Gillmor ha scritto:

> If anyone is considering adding this kind of feature to the FST-01, i'd
> be happy to test and debug it with them.
I proposed to add a button to FST-01 ages ago (IIRC it still was just a
project on Seeedstudio...), as "user presence test", and am having a
look at implementing it. But I received the programmer too late and now
I have a more demanding (and really high priority!) project: my son! :)

But I'll try to implement it, even if really slowly.

BYtE,
 Diego.


From s.murthy at mykolab.com  Thu Jan 22 22:36:09 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Thu, 22 Jan 2015 21:36:09 +0000
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C144FC.9060606@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
Message-ID: <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>

There are degrees of ?control over your hardware? and
complete control hardware is rarely going to happen.

If the concerns voiced by some developers about the
randomness quality of Intel?s hardware random
number generator (RNG) around the time of the
Snowden leaks are true

http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/

then we are all compromised, so why are we even
bothering to use tools like GnuPG, which according
to the documentation uses Intel?s RDRAND CPU
instruction (which calls its hardware RNG) among its
entropy sources?  Because it is using other ones, like
dev/random, so there is no one point of weakness and
from a practical point of view there is little risk.

Sandeep Murthy
s.murthy at mykolab.com

> On 22 Jan 2015, at 18:44, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> To prevent such an attack, I imagine a device where I have to
>> confirm every transaction with a simple push on a hardware button.
> 
> This attack can't be prevented.
> 
> Once the attacker has control over your hardware, you're done.  Game
> over.  People keep on trying to invent ways to do crypto even on
> compromised hardware, but it's a completely lost cause.  The attacker
> has too many options at that point for you to make any sort of effective
> defense.
> 
> If I were Eve and I wanted to defeat your pushbutton setup, here's what
> I'd do:
> 
> 
> 1.  Figure out exactly your operating system
> 2.  Figure out which forums you look for help on
> 3.  Start posting messages on forums for your operating system, saying I
> was having problems with your specific card reader and how it wasn't
> responding to a pushbutton
> 4.  Post answers, under a different name, saying this was a known
> problem with your model of card reader under the most recent USB driver
> update, and that unplugging and replugging the device was usually enough
> to reboot the card reader and make it work
> 5.  Under yet more fake account names, upvote the answer and talk about
> how it works for me
> 6.  Repeat #s 3-5 over several different web forums
> 7.  A couple of weeks later, subvert your machine
> 8.  Replace your copy of GnuPG with one that caches the PIN.  When you
> enter your PIN and push the button, it silently substitutes my message
> for yours.  You sign it, and this compromised GnuPG deposits the signed
> message in some hidden file/directory somewhere awaiting my later collection
> 9.  You'd be understandably concerned.  You'd check web forums and see,
> "ah, this bug has been reported by five different people, and a lot of
> people are confirming that unplugging and replugging the USB device
> solves the problem."
> 10. You unplug and replug the card reader.  My malware detects the
> unplug/replug and uses that as its "clean up and get out of there"
> trigger.  It erases itself and leaves behind a clean GnuPG in its wake.
> 11. You re-try signing your message.  It works correctly.  However,
> you've already signed a message of my choosing, and I can pick it up off
> your machine at my leisure.
> 
> 
> ... I understand the wish to make a system that's secure even if the
> underlying hardware is compromised.  I really do.  But it's a fantasy.
> Can't be done.  Once you lose control over the hardware the attacker has
> a near-limitless number of possible attacks, and there's absolutely no
> way for you to defend against all of them, or even to effectively
> anticipate what it will be.
> 
> Please don't tell me how, "well, to defend against your attack I'd
> just..."; that misses the point.  The point is there are literally
> *hundreds*, if not *thousands*, of attacks like this that could be
> levied against you, and there is absolutely no way for you to anticipate
> or defend against even a significant fraction of them.
> 
> Once you lose control of the hardware, you're done.
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150122/83354961/attachment.sig>

From dkg at fifthhorseman.net  Thu Jan 22 22:55:53 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 22 Jan 2015 16:55:53 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C144FC.9060606@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
Message-ID: <87fvb2mqdy.fsf@alice.fifthhorseman.net>

On Thu 2015-01-22 13:44:12 -0500, Robert J. Hansen wrote:
>> To prevent such an attack, I imagine a device where I have to
>> confirm every transaction with a simple push on a hardware button.
 [...]
>
> Once you lose control of the hardware, you're done.

The attack you describe is significantly more complex and more visible
than the attack the original poster outlined.

Yes, in the long run, if you can't trust your endpoint, you can be
compromised.

But this is a game of defense in depth, and the proposed changes seem
like a useful step in raising the bar for an attacker.

     --dkg


From rjh at sixdemonbag.org  Fri Jan 23 00:37:30 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 22 Jan 2015 18:37:30 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
 <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>
Message-ID: <54C189BA.6050501@sixdemonbag.org>

> There are degrees of ?control over your hardware? and complete
> control hardware is rarely going to happen.

That's not what the original poster was positing, though: the original
poster was positing *someone else* had complete control -- and trying to
make a system that works in that environment is a fool's errand.

> then we are all compromised, so why are we even bothering to use
> tools like GnuPG...

Excellent question.  Vint Cerf has said that in his estimate one of five
desktop PCs is completely pwn3d by malware.  We don't pay enough
attention to that.  We tend to assume the security of the endpoints, and
that's simply not a supportable assumption nowadays.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150122/57b19616/attachment.bin>

From rjh at sixdemonbag.org  Fri Jan 23 00:43:08 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 22 Jan 2015 18:43:08 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <87fvb2mqdy.fsf@alice.fifthhorseman.net>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org> <87fvb2mqdy.fsf@alice.fifthhorseman.net>
Message-ID: <54C18B0C.6060401@sixdemonbag.org>

> The attack you describe is significantly more complex and more
> visible than the attack the original poster outlined.

Right: that's because the original poster outlined an attack which was,
in my opinion, naive.

If Eve can read arbitrary memory locations on your desktop PC without
your knowledge, then Eve's got root access.  At that point you need to
start thinking like a clever person with root access.

The alternative is to say, "well, assume Eve's got some exotic side
channel that only allows her a limited ability to monitor..."  Okay,
great: what's the side channel?  Defending against a side channel that
you don't know exists is pretty suboptimal, too, since you can always
imagine another hypothetical side channel.

> Yes, in the long run, if you can't trust your endpoint, you can be 
> compromised.

This isn't about not trusting the endpoint: this is about a security
system built on the assumption the endpoint is already compromised.
There is no "in the long run" here.  If your endpoint is compromised and
you're using it to do crypto operations, you're living in sin.

Smartcards exist to keep private keys safe(r) from being stolen.  They
do a pretty good job of that.  But when we expect smartcards to be able
to somehow make a compromised environment safe to operate in, then we've
crossed the line and turned them into magic crypto fairy dust.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150122/2314d0f9/attachment-0001.bin>

From dkg at fifthhorseman.net  Fri Jan 23 02:20:39 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 22 Jan 2015 20:20:39 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C16B66.5030602@gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <873872o9xc.fsf@alice.fifthhorseman.net> <54C16B66.5030602@gmail.com>
Message-ID: <878ugumgwo.fsf@alice.fifthhorseman.net>

On Thu 2015-01-22 16:28:06 -0500, NdK wrote:
> I proposed to add a button to FST-01 ages ago (IIRC it still was just a
> project on Seeedstudio...), as "user presence test", and am having a
> look at implementing it. But I received the programmer too late and now
> I have a more demanding (and really high priority!) project: my son! :)
>
> But I'll try to implement it, even if really slowly.

Awesome.  the expansion port should be usable for wiring up the button:

http://www.seeedstudio.com/wiki/FST-01#Extension_port_of_VDD.2FGND.2FPort0.2FPort1

We might also want an independent LED to signal that the "user presence
test" is demanded -- so that LED indicators for device activity aren't
confused with the request for user presence.

I haven't looked into what it will take to make the "user presence test"
a part of the signing process, though.  Maybe NIIBE Yutaka can chime in
about the best way to do that?

      --dkg


From s.murthy at mykolab.com  Fri Jan 23 02:55:18 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Fri, 23 Jan 2015 01:55:18 +0000
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C189BA.6050501@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
 <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>
 <54C189BA.6050501@sixdemonbag.org>
Message-ID: <A50C77DD-C7EB-468A-B0F2-EBD67FC75777@mykolab.com>

> That's not what the original poster was positing, though: the original
> poster was positing *someone else* had complete control -- and trying to
> make a system that works in that environment is a fool's errand.


I was referring to exactly that - *somebody else* having "complete
control" over your hardware, remotely.  There are degrees of that,
and it just seems like an uninteresting abstraction here - what does it
look like?

The original question was:

>> I currently use GnuPG with an OpenPGP Card V2.0 in a smart card reader
>> with PIN pad.
>> 
>> However, there is one attack which I think could be easily
>> prevented: With the card in the reader, the PIN entered, and
>> Eve having remote access to my machine, she could sign and
>> decrypt documents.
>> 
>> To prevent such an attack, I imagine a device where I have to confirm
>> every transaction with a simple push on a hardware button.

An even simpler solution would be to disable all remote sharing
services via the OS.  What else does remote access mean?  After
Shellshock anyone with a Unix like OS enabling such services, e.g.
like SFTP or SSH, is recommended to either upgrade their Bash shell, or
turn off these services completely, which is easy to do.

Sandeep Murthy
s.murthy at mykolab.com

> On 22 Jan 2015, at 23:37, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> There are degrees of ?control over your hardware? and complete
>> control hardware is rarely going to happen.
> 
> That's not what the original poster was positing, though: the original
> poster was positing *someone else* had complete control -- and trying to
> make a system that works in that environment is a fool's errand.
> 
>> then we are all compromised, so why are we even bothering to use
>> tools like GnuPG...
> 
> Excellent question.  Vint Cerf has said that in his estimate one of five
> desktop PCs is completely pwn3d by malware.  We don't pay enough
> attention to that.  We tend to assume the security of the endpoints, and
> that's simply not a supportable assumption nowadays.
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150123/20a4b575/attachment.sig>

From faramir.cl at gmail.com  Fri Jan 23 03:56:41 2015
From: faramir.cl at gmail.com (Faramir)
Date: Thu, 22 Jan 2015 23:56:41 -0300
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C18B0C.6060401@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org> <87fvb2mqdy.fsf@alice.fifthhorseman.net>
 <54C18B0C.6060401@sixdemonbag.org>
Message-ID: <54C1B869.3030405@gmail.com>

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

El 22-01-2015 a las 20:43, Robert J. Hansen escibi?:

> Smartcards exist to keep private keys safe(r) from being stolen.
> They do a pretty good job of that.  But when we expect smartcards
> to be able to somehow make a compromised environment safe to
> operate in, then we've crossed the line and turned them into magic
> crypto fairy dust.

  Yes, but maybe you are missing an interesting point: if a smartcard
requires the user to push a button each time it has to issue a
signature (maybe the pin can be cached for a while, but still require
pushing a button means physical access to the device, not just some
remotely controled malware), and the card flashes a message saying "I
need you to push the button", when you are not requesting the card to
issue a signature, then you can realize your computer has been
compromized. Or if you issue a signature and then you get a message
about "do it again", ok, you can fall once, but not 500 times.

   Some years ago, I got malware in my computer, and I detected it
when the firewall warned me about some program attempting to connect
to internet. The firewall was not intended to be a malware detector,
but when it requested me to create a rule for that unknown app, I got
aware about the problem and could take steps to solve it.

   By the way, here (at Chile), the law recognizes 2 lvls of digital
signatures: the "advanced" digital signature, that is considered like
a handwritten signature (and requires a certificate in a smartcard,
issued by one of the 3 or 4 approved companies), and the "normal"
digital signature, which means the judge will determine the value of
that evidence (so, my signatures issued with GnuPG are in the same
level as a scanned picture of my handwritting... a bit unfair, IMHO).
   In that context, I would not only want the smartcard to prevent my
private key from being stolen, I'd also like to know malware won't be
able to start signing 1000s of things without my approval.

  Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJUwbhpAAoJEMV4f6PvczxAO3QH/33wV8O/7KG73enX4edcnVfA
YCVHF5VIMyi11o/ZX24hpeMdEW0ZM6T2I74TUw+gECkG+3Icci6uaVBlNsTLSW/v
TWPzQJI6ahc1ATZlFCfWZ1BiUneBMoQSMxItp/BEJ22XKw2oaNSzQqsZ4fXRXHAO
uq0UtY/VtXSovhp0+4KEQe21c92Ko0RxiI1u4z1ihz0ytJhtDivzmJR7QpHQrbCE
Y7dKuoRUqv0jPu4AG+DzZBdwu3kRh5jz6ONU84bC0Y4HfPwJ83QXAfBDv0BOOnK+
uo18J1Xs9FOmWDRKgwOw2DYq8lMPFMakHI6DHO6yTT2EQutTe2xKk1bXHdwP+GA=
=yJ8z
-----END PGP SIGNATURE-----


From rjh at sixdemonbag.org  Fri Jan 23 04:15:11 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 22 Jan 2015 22:15:11 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <A50C77DD-C7EB-468A-B0F2-EBD67FC75777@mykolab.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
 <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>
 <54C189BA.6050501@sixdemonbag.org>
 <A50C77DD-C7EB-468A-B0F2-EBD67FC75777@mykolab.com>
Message-ID: <54C1BCBF.6030507@sixdemonbag.org>

> I was referring to exactly that - *somebody else* having "complete 
> control" over your hardware, remotely.  There are degrees of that...

There aren't.  It's like saying someone's a "little bit pregnant".  You
have complete control, or you have less-than-complete control.  There
are degrees of less-than-complete, but not complete.

The name of the game is prevention, detection, and recovery: prevent
compromises from occurring, detect them when prevention fails, and
recovery to a known-good state.  In electronic voting we liked to have
multiple orthogonal PDR; the idea of somehow persisting in operations
after complete compromise was always seen as a fool's errand.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150122/4370c74c/attachment.bin>

From rjh at sixdemonbag.org  Fri Jan 23 04:29:46 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 22 Jan 2015 22:29:46 -0500
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C1B869.3030405@gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org> <87fvb2mqdy.fsf@alice.fifthhorseman.net>
 <54C18B0C.6060401@sixdemonbag.org> <54C1B869.3030405@gmail.com>
Message-ID: <54C1C02A.9030806@sixdemonbag.org>

>> Smartcards exist to keep private keys safe(r) from being stolen. 
>> They do a pretty good job of that.  But when we expect smartcards 
>> to be able to somehow make a compromised environment safe to 
>> operate in, then we've crossed the line and turned them into magic 
>> crypto fairy dust.
> 
> Yes, but maybe you are missing an interesting point...

You're changing the subject slightly.  :)  The thread is about letting a
legitimate user continue to safely use the system; you're talking about
limiting the damage an attacker can do.  The two are related but different.

The idea might be good for damage mitigation; but for permitting
continued normal operation, it's IMO a non-starter on every level.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150122/be2372d2/attachment-0001.bin>

From faramir.cl at gmail.com  Fri Jan 23 04:25:46 2015
From: faramir.cl at gmail.com (Faramir)
Date: Fri, 23 Jan 2015 00:25:46 -0300
Subject: Talking about Cryptodevices... which one?
Message-ID: <54C1BF3A.2040903@gmail.com>

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

Hello,
      Well, some months ago I wanted to take a look at existing
smartcards and/or readers that hopefully support both OpenPGP and x503
certificates, but my Google-Fo failed me, I couldn't figure out where
to buy something that works on Windows and can be shipped to Chile.
Any advice? I'm not planning to buy "right now", but the first step is
to know what to buy, where to buy, and how much does it cost.

      Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJUwb86AAoJEMV4f6PvczxAWE8H+wav12mzITZwDOc15OAEnG2b
RvW1jQ9/VXwHMbAl3b/pgLv9AHdd2vcqULRhqUW3HdCwNj9/14xDB8IQ51ogBoTk
1Xyr56e3DVzHjK3c6V4lyrtBbue8GPlU0rMh/uKutOEBzmrAT6wO1/vwicC/zV0s
QLjN3uNrk7DubIYWfEicWPBKm1icu4YzgIHoBjOzX/NPCnALEwjcRdLqxMInLjVA
sAT61l0ojvbwC64KSMQ1yu7gMrK5h2MF+F1ODWzdXuDvdQ1RrIG2NUW2ZS8SHCHW
nF+mtkEiy1Rutl+TfgaebSxSJ+sQHoT/EKX2ebu4GX7Ko4gO0Capx4hH3aZn/u4=
=Cbrr
-----END PGP SIGNATURE-----


From s.murthy at mykolab.com  Fri Jan 23 04:37:21 2015
From: s.murthy at mykolab.com (Sandeep Murthy)
Date: Fri, 23 Jan 2015 03:37:21 +0000
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C1BCBF.6030507@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org>
 <73C37F8F-6253-41D4-B214-07761B43F19B@mykolab.com>
 <54C189BA.6050501@sixdemonbag.org>
 <A50C77DD-C7EB-468A-B0F2-EBD67FC75777@mykolab.com>
 <54C1BCBF.6030507@sixdemonbag.org>
Message-ID: <E0C674A2-D59A-4692-A90C-BA4AB3E156DD@mykolab.com>

I didn?t mean to include the word ?complete? in there - true, there are degrees of
control that somebody else can have over your computer.  I don?t
think this tells us anything in relation to the original problem, and besides from
a practical point of view there are some simple steps people can take to
reduce risks, for example, of unauthorised or malicious remote access.

I didn?t state any opinions about somebody continuing to use their
compromised system to counteract further efforts.

Hardware compromise again is an abstraction.  There are many
imaginable ways in which your computer could be compromised, the
question only becomes interesting when it relates to particular attacks /
exploits.

Sandeep Murthy
s.murthy at mykolab.com

> On 23 Jan 2015, at 03:15, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
> 
>> I was referring to exactly that - *somebody else* having "complete
>> control" over your hardware, remotely.  There are degrees of that...
> 
> There aren't.  It's like saying someone's a "little bit pregnant".  You
> have complete control, or you have less-than-complete control.  There
> are degrees of less-than-complete, but not complete.
> 
> The name of the game is prevention, detection, and recovery: prevent
> compromises from occurring, detect them when prevention fails, and
> recovery to a known-good state.  In electronic voting we liked to have
> multiple orthogonal PDR; the idea of somehow persisting in operations
> after complete compromise was always seen as a fool's errand.
> 
> _______________________________________________
> 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: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20150123/68b61b22/attachment.sig>

From faramir.cl at gmail.com  Fri Jan 23 06:29:32 2015
From: faramir.cl at gmail.com (Faramir)
Date: Fri, 23 Jan 2015 02:29:32 -0300
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C1C02A.9030806@sixdemonbag.org>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org> <87fvb2mqdy.fsf@alice.fifthhorseman.net>
 <54C18B0C.6060401@sixdemonbag.org> <54C1B869.3030405@gmail.com>
 <54C1C02A.9030806@sixdemonbag.org>
Message-ID: <54C1DC3C.9080506@gmail.com>

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

El 23-01-2015 a las 0:29, Robert J. Hansen escibi?:
>>> Smartcards exist to keep private keys safe(r) from being
>>> stolen. They do a pretty good job of that.  But when we expect
>>> smartcards to be able to somehow make a compromised environment
>>> safe to
...
>> 
>> Yes, but maybe you are missing an interesting point...
> 
> You're changing the subject slightly.  :)  The thread is about
> letting a legitimate user continue to safely use the system; you're
> talking about limiting the damage an attacker can do.  The two are
> related but different.

  Oh, yes, you are right. After all, if the attacker can "steal" a
signature, then each time we try to sign something legitimate, the
attacker may be able to hijack it and sign something we don't want to
sign, and the thing we want so sign will remain unsigned. And even if
the attacker can't hijack the signature, malware may very well hijack
the email account, etc.

> The idea might be good for damage mitigation; but for permitting 
> continued normal operation, it's IMO a non-starter on every level.

  Yes, compromised machine must be cleaned ASAP. BTW, if somebody is
willing to develope such safety device, I hope it is designed to have
a "go ahead" button to press, but not to require entering a pin-code
each time. If entering the password to unlock GPG key too often is
unpleasant, doing that in a tiny pin-pad that maybe is not in a
comfortable place would be unusable.

  Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJUwdw8AAoJEMV4f6PvczxAFa8IAJSTu/uHY2tE71cTMgfjD2Rm
uZG0BFbTF1Ypurz0TxoHxBNfiSjwo+o41gm0+bqV6M24V5hGMAIKBfcpx8GUFZf9
YQrl0Vv7VbffUjcRao96ikkstisU/utzQpn06wbd5hLlEAAl6MAvINg0laqeay3u
gjdtgpEQESivsedQm1yFIPy7xvEJ7bT3qmuZ+V8hYnsFA/v/iJilZNRQzZVubmB0
wy8v5HN0PXYuOKCGo+XJTu5I02YKfOhKPEu1gpEY5VpQ7Prl4IeMGr45bM7TXv54
kC0gtv7i4Bmulkg30VeJgdTf7bktmQV5Wx7MgErVGDAIvgJTst2X0e/Q0a5A3zA=
=X8pm
-----END PGP SIGNATURE-----


From felix.klee at inka.de  Fri Jan 23 12:19:38 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Fri, 23 Jan 2015 11:19:38 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C1BF3A.2040903@gmail.com>
References: <54C1BF3A.2040903@gmail.com>
Message-ID: <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>

On Fri, Jan 23, 2015 at 3:25 AM, Faramir <faramir.cl at gmail.com> wrote:
> Any advice?

I bought an OpenPGP smart card at [cryptoshop][1]. Whether they ship to
Chile, I don?t know. The cards are actually distributed by [kernel
concepts][2]. I called them, and they told me:

  * Currently they don?t have cards in stock.

  * The shop will be back IIRC next month, or in March.

  * There will be a new batch of cards, with the same functionality but
    updated print: On the back of the current cards, it says ?RSA with
    up to 3072 bit? when in fact the cards support up to 4096 bit.

Also: You can get that card, if you become an [FSFE fellow][3].

As for the reader, I got a Reiner SCT cyberJack RFID standard. The RFID
functionality allows me to use it with the German ID card as well. If
you don?t need that, there is a smaller device, the cyberJack go plus.

I?m running the setup with Win7 X64, with Gpg4win, which works fine:

  * PIN entry is via the pinpad on the reader.

  * 4096 bit RSA

  * Decryption of a 30 kB file takes one or two seconds.

[1]: http://www.cryptoshop.com/checkout/cart/
[2]: http://shop.kernelconcepts.de/
[3]: https://fsfe.org/fellowship/card.en.html


From felix.klee at inka.de  Fri Jan 23 12:28:28 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Fri, 23 Jan 2015 11:28:28 +0000
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <2030060.eh0tmPdXvE@mani>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <2030060.eh0tmPdXvE@mani>
Message-ID: <CA+m_8J1V1ePby2jZmzK2ihXBQEffHSHPhceqUT4jvSARXWnWKg@mail.gmail.com>

On Thu, Jan 22, 2015 at 6:34 PM, Johannes Zarl <johannes at zarl.at> wrote:
> On my setup, the smartcard seems to only allow one sign operation per
> pin-entry.

Right, for signing I am always asked for the PIN. I didn't check that
before posting.


From dkg at fifthhorseman.net  Fri Jan 23 16:22:52 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Jan 2015 10:22:52 -0500
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C1BF3A.2040903@gmail.com>
References: <54C1BF3A.2040903@gmail.com>
Message-ID: <87lhktldwz.fsf@alice.fifthhorseman.net>

On Thu 2015-01-22 22:25:46 -0500, Faramir wrote:

>       Well, some months ago I wanted to take a look at existing
> smartcards and/or readers that hopefully support both OpenPGP and x503
> certificates, but my Google-Fo failed me, I couldn't figure out where
> to buy something that works on Windows and can be shipped to Chile.
> Any advice? I'm not planning to buy "right now", but the first step is
> to know what to buy, where to buy, and how much does it cost.

I don't know that it supports x.509 certificates explicitly right now,
but the gnuk (running on the FST-01) has free firmware and is under
active development.  gniibe (who i think is active on this list, but i'm
cc'ing here anyway) is lead on development for that project.

"Certificate support" is a bit of an odd question, because the cards
specifically deal with secret key material, which isn't any sort of
certificate at all -- the certificate is a wrapper around a public key
that happens to be associated with the secret key.

You can have a secret key that is associated with both an OpenPGP
certificate and an X.509 certificate if you like.

the FST-01 is available for a little under $40 USD, depending on the
physical form factor you want:

 http://www.seeedstudio.com/wiki/FST-01

            --dkg


From wk at gnupg.org  Fri Jan 23 21:31:46 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 23 Jan 2015 21:31:46 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 (Felix E. Klee's message of "Fri, 23 Jan 2015 11:19:38 +0000")
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
Message-ID: <87iofxck7h.fsf@vigenere.g10code.de>

On Fri, 23 Jan 2015 12:19, felix.klee at inka.de said:

>   * There will be a new batch of cards, with the same functionality but
>     updated print: On the back of the current cards, it says ?RSA with
>     up to 3072 bit? when in fact the cards support up to 4096 bit.

The code for the card and the specs will also have some minor updates.
This has been done mostly on requests from the Nitrokey (aka
CryptoStick) folks.  Nothing to worry about.  Achim already send me the
specs and I will put them online soon.

> As for the reader, I got a Reiner SCT cyberJack RFID standard. The RFID

If you do not use Windows I would strongly advise against Rainer
products.

I never achieved to make them work for me, requests for technical
support were never answered, all requests for a sample were rejected or
they quoted unacceptable prices.  Further, the Cyberjack readers run a
lot of code not necessary for accessing the card and the firmware can
easily be updated from the host (if you know how to do that).  Granted,
other vendors also have easy changeable firmware but their
microcontrollers are smaller and writing malware for them is harder.  I
won't trust such devices - we don't know whether the BND has an
agreement with them not to fix exploitable bugs so to allow them
inserting code to track PINs.

Time to build our own pinpad equipped reader?


>   * Decryption of a 30 kB file takes one or two seconds.

The size of the file does not matter.  The card only sees the public key
encrypted session key.


Salam-Shalom,

   Werner

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



From robertc at broadcom.com  Fri Jan 23 22:53:25 2015
From: robertc at broadcom.com (Bob (Robert) Cavanaugh)
Date: Fri, 23 Jan 2015 21:53:25 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <87iofxck7h.fsf@vigenere.g10code.de>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de>
Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com>

Werner,
What set would you recommend for us Linux types (Fedora 20 in my case) ?

Thanks,
 
Bob Cavanaugh

 

-----Original Message-----
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Werner Koch
Sent: Friday, January 23, 2015 12:32 PM
To: Felix E. Klee
Cc: gnupg-users at gnupg.org; Faramir
Subject: Re: Talking about Cryptodevices... which one?

On Fri, 23 Jan 2015 12:19, felix.klee at inka.de said:

>   * There will be a new batch of cards, with the same functionality but
>     updated print: On the back of the current cards, it says ?RSA with
>     up to 3072 bit? when in fact the cards support up to 4096 bit.

The code for the card and the specs will also have some minor updates.
This has been done mostly on requests from the Nitrokey (aka
CryptoStick) folks.  Nothing to worry about.  Achim already send me the
specs and I will put them online soon.

> As for the reader, I got a Reiner SCT cyberJack RFID standard. The RFID

If you do not use Windows I would strongly advise against Rainer
products.

I never achieved to make them work for me, requests for technical
support were never answered, all requests for a sample were rejected or
they quoted unacceptable prices.  Further, the Cyberjack readers run a
lot of code not necessary for accessing the card and the firmware can
easily be updated from the host (if you know how to do that).  Granted,
other vendors also have easy changeable firmware but their
microcontrollers are smaller and writing malware for them is harder.  I
won't trust such devices - we don't know whether the BND has an
agreement with them not to fix exploitable bugs so to allow them
inserting code to track PINs.

Time to build our own pinpad equipped reader?


>   * Decryption of a 30 kB file takes one or two seconds.

The size of the file does not matter.  The card only sees the public key
encrypted session key.


Salam-Shalom,

   Werner

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


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

From ott at mirix.org  Sat Jan 24 00:05:17 2015
From: ott at mirix.org (Matthias-Christian Ott)
Date: Sat, 24 Jan 2015 00:05:17 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <87iofxck7h.fsf@vigenere.g10code.de>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de>
Message-ID: <54C2D3AD.9080608@mirix.org>

On 2015-01-23 21:31, Werner Koch wrote:
> On Fri, 23 Jan 2015 12:19, felix.klee at inka.de said:
> 
>>   * There will be a new batch of cards, with the same functionality but
>>     updated print: On the back of the current cards, it says ?RSA with
>>     up to 3072 bit? when in fact the cards support up to 4096 bit.
> 
> The code for the card and the specs will also have some minor updates.
> This has been done mostly on requests from the Nitrokey (aka
> CryptoStick) folks.  Nothing to worry about.  Achim already send me the
> specs and I will put them online soon.
> 
>> As for the reader, I got a Reiner SCT cyberJack RFID standard. The RFID
> 
> If you do not use Windows I would strongly advise against Rainer
> products.
> 
> I never achieved to make them work for me, requests for technical
> support were never answered, all requests for a sample were rejected or
> they quoted unacceptable prices.  Further, the Cyberjack readers run a
> lot of code not necessary for accessing the card and the firmware can
> easily be updated from the host (if you know how to do that).  Granted,
> other vendors also have easy changeable firmware but their
> microcontrollers are smaller and writing malware for them is harder.  I
> won't trust such devices - we don't know whether the BND has an
> agreement with them not to fix exploitable bugs so to allow them
> inserting code to track PINs.

The same is true for the OpenPGP smart card or for almost any other
smart card available on the market. They could all contain a secret key
escrow mechanism and some probably do. Proprietary smart cards are hard
to audit and verify and are easy targets for backdoors and bugdoors.
Moreover, I would like to see a realistic threat model under which
compromising the host system does not render the smart card useless
(that doesn't mean smart cards aren't useful from a usability
perspective for some types of users). From a security perspective it's
yet another mitigation technique to try to work around insecure
operating systems and applications.

There are some smart cards with PIC and AVR microcontroller available on
the market that seem to be used to decode scrambled/encrypted satellite
broadcasts (starting keyword: Funcard, Goldcard). They have limited
memory but there are models that should suffice for a minimal
implementation of the OpenPGP Card specification. There are also similar
microcontrollers of the size of a USB flash drive. Both have fuses to
prevent changing the bootloader which in turn could verify firmware
uploaded to the device.

As already mentioned in this discussion, there is also Gnuk which is a
USB device without proprietary firmware and there are USB connected
computers of the size of a USB flash drive that run GNU/Linux and could
be used as a HSM (there are several software based Free Software HSM
implementations).

Moreover, you should be able to use any card supported by OpenSC
(including MuscleCard and derived Java Card applets) with gnupg-pkcs11.
As far as I know OpenSC does not support any hardware that is entirely
based on Free Software.

That being said, really think about your threat model and whether smart
cards would help you to prevent attacks in your threat model. If they
don't, save the money or give it to people in need.

- Matthias-Christian


From ott at mirix.org  Sat Jan 24 00:27:06 2015
From: ott at mirix.org (Matthias-Christian Ott)
Date: Sat, 24 Jan 2015 00:27:06 +0100
Subject: Crypto device where I need to confirm every operation?
In-Reply-To: <54C1B869.3030405@gmail.com>
References: <CA+m_8J3cQPoCeJ73zu5jkj2SihtfKJYtQtwR+bev2-Q5Vp_Sbg@mail.gmail.com>
 <54C144FC.9060606@sixdemonbag.org> <87fvb2mqdy.fsf@alice.fifthhorseman.net>
 <54C18B0C.6060401@sixdemonbag.org> <54C1B869.3030405@gmail.com>
Message-ID: <54C2D8CA.1080201@mirix.org>

On 2015-01-23 03:56, Faramir wrote:
> compromized. Or if you issue a signature and then you get a message
> about "do it again", ok, you can fall once, but not 500 times.

Twice is enough: once to generate a revocation certificate and once to
sign a new key created by the attacker.

- Matthias-Christian


From gniibe at fsij.org  Sat Jan 24 05:05:44 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 24 Jan 2015 13:05:44 +0900
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <87lhktldwz.fsf@alice.fifthhorseman.net>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net>
Message-ID: <54C31A18.4040100@fsij.org>

Hello,

Thanks to dkg for Cc-ing me explicitly, it helps me to catch this
message.

Perhaps, my answer would be a bit too technical for gnupg-users (and a
bit Zen-ish because of my background/culture), sorry in advance for
that.  It is not that I want to be unfriendly or unkind, but I
sincerely would like to share technical points and hopefully invite
more users and engineers to this field, and encourage its development.

On Thu 2015-01-22 22:25:46 -0500, Faramir wrote:
>       Well, some months ago I wanted to take a look at existing
> smartcards and/or readers that hopefully support both OpenPGP and x503
> certificates, but my Google-Fo failed me, I couldn't figure out where
> to buy something that works on Windows and can be shipped to Chile.
> Any advice? I'm not planning to buy "right now", but the first step is
> to know what to buy, where to buy, and how much does it cost.

Availability is one of important factors.  Good.  Furthermore, please
also consider other factors, when you put your own private key(s) onto
some device.  Imagine some cases where computing on the device is not
under your control, specifically, the possibility of honeypot device
to spy your private key and/or your crypto operations.

In my opinion, reproducible hardware product is a condition for such a
device, as well as a condition that whole firmware is Free Software
(not only glue code to access crypto engine).

Reproducible hardware product naturally would have good availability.
And I have expected that for my FST-01.  Unfortunately, our world is
not that simple, or it takes some time for the world to catch up.

			*	*	*

I don't think there is an existing product which matches your exact
need/expectation.  But, something similar are there, and it would
be some way to seek future possibility.

Here we go.

(a) OpenPGPcard compatible device

With those devices which conform to OpenPGPcard specification, it is
possible to offer its users following features, using GnuPG and
related tools.

   (1) OpenPGP support
   (2) SSH support thorough gpg-agent
   (3) X.509 support
       S/MIME
       SSL/TLS client certificate authentication

Because those devices are intended to be used for OpenPGP, OpenPGP
support is superior.

But the support for #3 is somehow experimental.  Honestly, I don't use
those features with my device, but just do experiments time to time.

For OpenPGPcard compatible, we can check existing (or existed)
"manufacturer" list in the source code, specifically, the function
get_manufacturer in gnupg/g10/card-util.c.


(b) (Ab)using other devices with GnuPG

GnuPG has support of some existing smartcard/token not designed for
OpenPGP.

With those devices, I guess that OpenPGP support would be secondary,
but X.509 support could be considered superior.

We can check the source code, gnupg/scd/app-*.c (other than openpgp)
for those support.  There are:

	DINSIG (DIN V 66291-1) card
	German Geldkarte
	Telesec NKS card
	pkcs#15 card
	SmartCard-HSM card

... but I think that most are outdated, except the last one.

And when you use those devices, you should know that each application
has tendency to grab smartcard/token access exclusively.  At least,
GnuPG assumes access to smartcard/token exclusively, and when it grabs
its access, you can't use the device from other application (of X.509).

On 01/24/2015 12:22 AM, Daniel Kahn Gillmor wrote:
> I don't know that it supports x.509 certificates explicitly right now,
> but the gnuk (running on the FST-01) has free firmware and is under
> active development.  gniibe (who i think is active on this list, but i'm
> cc'ing here anyway) is lead on development for that project.
[...]
> You can have a secret key that is associated with both an OpenPGP
> certificate and an X.509 certificate if you like.

Yes.

I don't use X.509 much.  I think that it's easily possible for us to
use gpgsm with scdaemon.  I maintain scute for Debian (not that
active, though) and its for SSL/TLS client certificate authentication.
I don't use scute daily, but I do some experiments occasionally.

> "Certificate support" is a bit of an odd question, because the cards
> specifically deal with secret key material, which isn't any sort of
> certificate at all -- the certificate is a wrapper around a public key
> that happens to be associated with the secret key.

Sometimes, people expect the device to have all.  I mean, not only
private keys, but also, public keys of higher layer.  In OpenPGP
public keys of higher layer = OpenPGP public keys (with signs), and
it's called "certificate" in X.509.

I'd understand such an expectation, which the device could be a sort
of portable ".gnupg".  But, existing technology is that mature, yet.


OpenPGPcard (and its compatible) usually doesn't have any public keys
of higher layer, because of its limited storage.

But, in the past, there was an experiment, to let have X.509
client certificate onto the OpenPGPcard v2.

We can find "CERT-3" data object in the souce code of
gnupg/scd/app-openpgp.c, and the functions like
do_readcert/do_writecert.  However, we don't use this data object at
all, by any GnuPG tools, any more.  The inted usage of this data
object was by scute for X.509 client certificate authentication (Thus,
the name CERT-3, "3" means authentication key in OpenPGPcard).
It seemed that poldi (PAM module with OpenPGP auth) also tried
to use it, but it's not now.

>From the viewpoint of firmware implementation, this data object is
difficult to support, because of its length.  Because of that,
Gnuk has configure time option --enable-certdo, which encourage
not to use this feature of certificate data object support.

Once in the past, I also thought that it would be good idea to have
support of non confidential data onto a device.  Thus, FST-01 has a
chip of serial ROM on the board, which size is 4MiB.  But the size is
marginal to store OpenPGP public keys.  And I haven't implemented any
code to access this particular chip yet.  I also though that it would
be good to put the text of GPL onto this serial ROM to conform GPL
itself, but I realized that it costs when I ask doing that in the
production process.

> the FST-01 is available for a little under $40 USD, depending on the
> physical form factor you want:
> 
>  http://www.seeedstudio.com/wiki/FST-01

It's design is free (as in freedom) to be reproducible.  When/if you
care some possibility of malicious/fake hardware, you can build it by
yourselves.  And it's encouraged.

Gnuk doesn't use any crypto accelerator, on purpose, but use general
purpose MCU.  In my theory, using general purpose small MCU would be
superior to avoid malicious/fake hardware features by semiconductor
vendor.  If it's very expensive hardware, specific for "crypto", there
would be more possibility, pressure from outside, or enough room of
silicon to have spy feature (and I don't have technology to check no
spy feature on hardware device).

Besides, Gnuk also supports board other than FST-01.  If it's
difficult for some country to import FST-01 or you like DIY
electronics, my article would help:

  Make Gnuk USB Token by STM8S Discovery Kit:
  http://www.fsij.org/gnuk/howto-make-gnuk-usb-token-by-stm32-part-of-stm8s-discovery-kit.html

Newest experimental version of Gnuk 1.1.4 doesn't support this
particular board officially because of its small flash size (of
64KiB), but, if you manually configure and limit its capability of key
algorithms, Gnuk can run on this board still.

Happy Hacking,
-- 


From andreas.schwier.ml at cardcontact.de  Sat Jan 24 18:14:01 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Sat, 24 Jan 2015 18:14:01 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C31A18.4040100@fsij.org>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
Message-ID: <54C3D2D9.8040900@cardcontact.de>

> Here we go.
> 
> (a) OpenPGPcard compatible device
> 
> With those devices which conform to OpenPGPcard specification, it is
> possible to offer its users following features, using GnuPG and
> related tools.
> 
>    (1) OpenPGP support
>    (2) SSH support thorough gpg-agent
>    (3) X.509 support
>        S/MIME
>        SSL/TLS client certificate authentication
> 
> Because those devices are intended to be used for OpenPGP, OpenPGP
> support is superior.
> 
> But the support for #3 is somehow experimental.  Honestly, I don't use
> those features with my device, but just do experiments time to time.
> 
> For OpenPGPcard compatible, we can check existing (or existed)
> "manufacturer" list in the source code, specifically, the function
> get_manufacturer in gnupg/g10/card-util.c.
> 
> 
> (b) (Ab)using other devices with GnuPG
> 
> GnuPG has support of some existing smartcard/token not designed for
> OpenPGP.
> 
> With those devices, I guess that OpenPGP support would be secondary,
> but X.509 support could be considered superior.
> 
> We can check the source code, gnupg/scd/app-*.c (other than openpgp)
> for those support.  There are:
> 
> 	DINSIG (DIN V 66291-1) card
> 	German Geldkarte
> 	Telesec NKS card
> 	pkcs#15 card
> 	SmartCard-HSM card
> 
> ... but I think that most are outdated, except the last one.
And I would love to use that last device to store my PGP keys as well.
Unfortunately there is a certain resistance to support other devices
than cards conforming with the OpenPGPCard specification.

I want a device that can store all my keys independently of whether it's
a GNUPG key, a SSH key, a X.509 key, a DNSSEC key, a OpenVPN key,
because at the end it's just a private key - there is nothing special in
a GNUPG key that prevents me from storing it on a device other that a
OpenPGPCard.

And I don't want to be limited in the number and types of keys on that
device. And I want a secure key escrow scheme where I can backup and
restore sensitive key material - functions the OpenPGPCard specification
does not provide for.

Andreas


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From andreas.schwier.ml at cardcontact.de  Sat Jan 24 17:57:15 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Sat, 24 Jan 2015 17:57:15 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C2D3AD.9080608@mirix.org>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org>
Message-ID: <54C3CEEB.7030406@cardcontact.de>

On 01/24/2015 12:05 AM, Matthias-Christian Ott wrote:
> The same is true for the OpenPGP smart card or for almost any other
> smart card available on the market. They could all contain a secret key
> escrow mechanism and some probably do. Proprietary smart cards are hard
> to audit and verify and are easy targets for backdoors and bugdoors.
Can you provide any evidence for that claim or is this just paranoia ?

Working in the smart card industry for close to 30 years now, I've never
come across an incident where a smart card was deliberately backdoor'ed.

Most smart cards used today in security sensitive mass applications like
banking cards, signature cards, national id cards or passports must be
independently evaluated and certified under the Common Criteria scheme.
I can not image a way to introduce a backdoor without being detected
during evaluation or in the secure delivery procedure. I can hardly
imagine a smart card manufacturer or evaluator that has to take
liability for a security product with a deliberately introduced backdoor.

I agree, that we've seen bad implementations in smart cards. We've even
seen certified products, that generated not so random numbers (Even
though this was the classical case of a developer trying to be smarter
than the user guidance allowed him to be).

Still smart cards have a case: They link the private key to a protective
and controllable piece of hardware. I can disconnect the card from the
PC and I can rest assured that no copies of the key exist and the key
can not be misused (Unless someone steals card and PIN). That is an
important security attribute that no software keys can provide for - at
some point in time the software key must be somewhere in memory.

Andreas

-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From philip.jackson at nordnet.fr  Sat Jan 24 20:05:02 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sat, 24 Jan 2015 20:05:02 +0100
Subject: GPA fails to verify certain .asc files
Message-ID: <54C3ECDE.8080806@nordnet.fr>

Using GPA 0.9.4 in linux.

I downloaded a file and its signature as a .asc from a website that I have used
many times.  While looking at the spelling of the filename, I accidentally
clicked on the signature file and launched GPA so decided to use it to verify
the download.  GPA gave me a 'bad' status.

The file verified as a good signature at the command line.

When I checked, I found that a signature "filename.asc" could be generated by
several means using gpg and gpg2 :

gpg --clearsign test1.txt
gpg --clearsign -a test1.txt
gpg --sign -a test1.txt
gpg --detach-sign -a test1.txt

each command/option gave a signature file test1.txt.asc

The last one, generated using '--detach-sign -a' could not be verified in GPA,
giving a 'bad' status.  All four could be verified correctly in the command line.

When opened in a text editor, the downloaded signature file had a similar
structure to the one made using the -ba command/option.

So it appears to be a bit hit and miss trying to use GPA to verify downloaded
.asc signatures.

Philip

-------------- 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/20150124/aa46d628/attachment.sig>

From peter at digitalbrains.com  Sat Jan 24 20:19:33 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 24 Jan 2015 20:19:33 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C3CEEB.7030406@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org>
 <54C3CEEB.7030406@cardcontact.de>
Message-ID: <54C3F045.2080101@digitalbrains.com>

On 24/01/15 17:57, Andreas Schwier wrote:
> Can you provide any evidence for that claim or is this just paranoia ?

One man's paranoia is another man's common sense, I suppose. Since those
smartcards are pretty much exclusively used for security purposes, i.e., private
key storage, they're a likely target for an intelligence agency to try to subvert.

> Most smart cards used today in security sensitive mass applications like
> banking cards, signature cards, national id cards or passports must be
> independently evaluated and certified under the Common Criteria scheme.
> I can not image a way to introduce a backdoor without being detected
> during evaluation or in the secure delivery procedure.

I've replied to this statement earlier, I won't repeat myself other than to say
I disagree.

> I can disconnect the card from the
> PC and I can rest assured that no copies of the key exist and the key
> can not be misused (Unless someone steals card and PIN).

Assuming it's not backdoored, yes. In the presence of backdoors this is
obviously not the case.

> That is an
> important security attribute that no software keys can provide for - at
> some point in time the software key must be somewhere in memory.

Yes, I agree.

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 peter at digitalbrains.com  Sat Jan 24 20:25:25 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sat, 24 Jan 2015 20:25:25 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C3ECDE.8080806@nordnet.fr>
References: <54C3ECDE.8080806@nordnet.fr>
Message-ID: <54C3F1A5.6020200@digitalbrains.com>

On 24/01/15 20:05, Philip Jackson wrote:
> Using GPA 0.9.4 in linux.
> 
> I downloaded a file and its signature as a .asc from a website that I have
> used many times.  While looking at the spelling of the filename, I
> accidentally clicked on the signature file and launched GPA so decided to
> use it to verify the download.  GPA gave me a 'bad' status.

I think this might be related to this:

http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051430.html

Quoting that mail:

> Now waiting which tools or scripts will break.  I checked a few (including
> dpkg) and they do the Right Thing.

Did the tool GPA just break? :). What is the proper solution anyways? A file
picker dialog for the signed data?

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 mailinglisten at hauke-laging.de  Sat Jan 24 20:27:46 2015
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Sat, 24 Jan 2015 20:27:46 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C3D2D9.8040900@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com> <54C31A18.4040100@fsij.org>
 <54C3D2D9.8040900@cardcontact.de>
Message-ID: <7296266.EQA0l8rLmz@inno>

Am Sa 24.01.2015, 18:14:01 schrieb Andreas Schwier:

> And I want a secure key escrow scheme where I can backup and
> restore sensitive key material - functions the OpenPGPCard
> specification does not provide for.

The OpenPGP card does provide the opportunity to backup the on the card 
generated key material.


Hauke
-- 
Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20150124/4cb94f5e/attachment.sig>

From philip.jackson at nordnet.fr  Sat Jan 24 22:23:41 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sat, 24 Jan 2015 22:23:41 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C3F1A5.6020200@digitalbrains.com>
References: <54C3ECDE.8080806@nordnet.fr> <54C3F1A5.6020200@digitalbrains.com>
Message-ID: <54C40D5D.4070500@nordnet.fr>

On 24/01/15 20:25, Peter Lebbing wrote:
> On 24/01/15 20:05, Philip Jackson wrote:
>> Using GPA 0.9.4 in linux.
>>
>> I downloaded a file and its signature as a .asc from a website that I have
>> used many times.  While looking at the spelling of the filename, I
>> accidentally clicked on the signature file and launched GPA so decided to
>> use it to verify the download.  GPA gave me a 'bad' status.
> 
> I think this might be related to this:
> 
> http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051430.html
> 
> Quoting that mail:
> 
>> Now waiting which tools or scripts will break.  I checked a few (including
>> dpkg) and they do the Right Thing.
> 
> Did the tool GPA just break? :). What is the proper solution anyways? A file
> picker dialog for the signed data?
> 

I doubt the failure is anything caused by gnupg 2.1 (unless maybe the file I
downloaded was signed under 2.1.

I am using 2.0.26 and 1.4.16 and I have signed and tested quite a few files
trying to find out why GPA will verify some but not others.

The only ones I can sign (with cli)  and then fail to verify with GPA are when I
use the  "gpg --detach-sign -a" command and option.  Such signature files will
verify perfectly well with the command line but not with the GPA gui.

--batch doesn't come into the question either.  And in every case, the matching
data file.txt was in the same directory together with the signature file.txt.asc
file.

Other signature files (.sig, .gpg) were not affected.

My point was that when a file with name like filename.tar.xz.asc is downloaded
with its data file of similar name and someone tries to verify it using GPA,
they could get a false 'bad' signature response from GPA.

Philip

Philip


-------------- 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/20150124/5c60a3c9/attachment.sig>

From peter at digitalbrains.com  Sun Jan 25 11:05:10 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jan 2015 11:05:10 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C40D5D.4070500@nordnet.fr>
References: <54C3ECDE.8080806@nordnet.fr> <54C3F1A5.6020200@digitalbrains.com>
 <54C40D5D.4070500@nordnet.fr>
Message-ID: <54C4BFD6.1060504@digitalbrains.com>

I was postulating that the breakage might be related to the fact that GnuPG in
batch mode no longer verifies a detached signature as valid when it is only
given the detached signature, instead of the pair of signed file and detached
signature. This security fix was backported to 2.0 and 1.4, so it does apply.

On 24/01/15 22:23, Philip Jackson wrote:
> --batch doesn't come into the question either. 

I refer you to line 857 of src/engine-gpg.c in GPGME[1], which is used by GPA:

argv[argc] = strdup ("--batch");

I think it's quite likely --batch comes into play in your scenario, although I'm
not well acquainted with the source code.

By the way, I think it'd be helpful if you could indicate your distribution and
the version of GPA you use. Also, if you don't use the packages from your
distribution but instead compile yourself, that would of course be very valuable
information.

HTH,

Peter.

[1]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=src/engine-gpg.c;h=30c3bfbe2389c8d7475e449f4e6d863772661dcb;hb=HEAD#l857

-- 
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 dgouttegattat at incenp.org  Sun Jan 25 11:48:55 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 25 Jan 2015 11:48:55 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C3ECDE.8080806@nordnet.fr>
References: <54C3ECDE.8080806@nordnet.fr>
Message-ID: <54C4CA17.2060306@incenp.org>

On 01/24/2015 08:05 PM, Philip Jackson wrote:
> Using GPA 0.9.4 in linux.  [...]
> So it appears to be a bit hit and miss trying to use GPA to verify downloaded
> .asc signatures.

It looks like bug 1637 [1], which indeed affected gpa-0.9.4 but has been 
fixed in gpa-0.9.5 and later versions.

[1] https://bugs.g10code.com/gnupg/issue1637

-------------- 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/20150125/3966bf57/attachment.sig>

From peter at digitalbrains.com  Sun Jan 25 12:05:58 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jan 2015 12:05:58 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C4CA17.2060306@incenp.org>
References: <54C3ECDE.8080806@nordnet.fr> <54C4CA17.2060306@incenp.org>
Message-ID: <54C4CE16.6040905@digitalbrains.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/01/15 11:48, Damien Goutte-Gattat wrote:
> It looks like bug 1637 [1], which indeed affected gpa-0.9.4 but has been
> fixed in gpa-0.9.5 and later versions.

So GPA never verified detached signatures in the first place? I read the
report by Philip as it being a regression, but when I reread, it doesn't say
so explicitly. The "hit and miss" doesn't actually say that it ever verified
/detached/ signatures.

It seems Philip is confusing signed files and detached signatures, by the way:

> gpg --clearsign test1.txt gpg --clearsign -a test1.txt gpg --sign -a
> test1.txt

The first two are exactly equivalent. Neither three produce a detached
signature, which was the problematic case. The signed data is included in the
.asc file, not kept as a separate file.

> gpg --detach-sign -a test1.txt

This is the only one likely mimicking the files downloaded from the website:
an ASCII-armoured, detached signature.

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 coyo at darkdna.net  Sat Jan 24 20:34:46 2015
From: coyo at darkdna.net (Coyo)
Date: Sat, 24 Jan 2015 13:34:46 -0600
Subject: OpenSSL Library Call Redirection, OpenPGP, DANE
Message-ID: <54C3F3D6.7060202@darkdna.net>

I have three separate questions, and I apologize in advance for posting
to multiple newsgroups and mailservs.

But I was taught two things by some very smart individuals:

1) The only dumb question is an unasked one, and
2) When dealing with serious cryptography, do not guess, ask an actual
cryptographer.

So I have a few separate but related questions:

Is is possible to use OpenPGP in DANE? What do I need to do this?

Can I redirect applications that rely specifically on OpenSSL to use NSS
or GnuTLS instead somehow?

My understanding of external library calls is severely limited, but my
understanding is that there's such a thing as DLL/SO injection, which
renames the library and then places an imposter library in its place so
that calls to that library are intercepted, and either handled by the
imposter or transparently forwarded to the real library.

This happens all of the time in the PC gaming world, and is a critical
tool in cheating on multiplayer games. It is a method to manipulate the
game client's internal binary logic.

It follows logically that such a technique SHOULD be possible with
OpenSSL, NSS and GnuTLS. It may be that there are wrappers or special
programs or tools that already do this, but I am unaware of any that
work universally.

Are calls to OpenSSL standardized in some what? Could a simple symlink work?

DANE is a fascinating system, and some applications I am interested in
optionally use DANE to verify the authenticity of certificates/keys. Is
it possible to use DANE locally to indirectly use GnuTLS or NSS as
backend cryptographic libraries?

Does PowerDNS or any of the common DANE-supporting nameservers
explicitly support cryptographic libraries other than OpenSSL? I made
several attempts to divine this knowledge, and was unsucessful. Perhaps
my Google-fu is not enough.

I fail to grok how I should this.

While applications like Pidgin use NSS, which is refreshing, most
applications I take an interest in specifically link to OpenSSL, rather
than being written as cryptographic library agnostic.

As a mere padawan, I do not know what I can do about this.

The project I have in mind uses PostFix and INN on a private LAN/VPN to
exchange files amongst a group. This group is a set of local
neighborhoods connected by explicit links.

These links use CJDNS for IP addresss allocation and NameCoin for name
allocation. However, NameCoin does not necessarily provide DANE
emulation. NameCoin does support arbitrary extensions, because it can
use any prefix:key=value binding by "spending" a NameCoin.

This should be trivial enough to write with a simple Bash Shell Script.
I am competent enough to write Bash Shell Scripts. However, I am too
smart to attempt mucking about with cryptographic libraries without
consulting a cryptography guru.

I realize I could somehow get PowerDNS to serve NameCoin .bit records
using the local DNS cache or perhaps a script, but I'm not sure how to
inject OpenPGP certs into DANE records.

I do know I can bind OpenPGP keys into NameCoin .bit addresses in the
same manner as regular DNS records, but I'm not sure if this is
cryptographically sound. Thus why I'm asking people who DO know what
they are doing.

So by manually posting OpenPGP keys along with names into .bit records,
then using a PowerDNS authoritative server to serve the .bit records
from a local DNS cache (somehow), i could provide DANE records to bind
.bit names to CJDNS IPv6 addresses.

This would provide a completely decentralized network, both at the IP
addressspace and DNS namespace levels, IF it works.

However, some of the servers I'd host on this infrastructure relies
specifically on OpenSSL, and I suspect OpenSSL does not support
verifying keys using OpenPGP, and perhaps not DANE. I'm honestly not sure.

But INN and PostFix would have problems with server-to-server TLS links
if the certs don't validate. I really want to use TLS, even though CJDNS
does use NACL cryptography for its peering links.

I don't like relying on only one cryptographic library for security. I
want both underlying NACL cryptography and TLS cryptography to help
protect sensitive data.

But the idea of using NameCoin + CJDNS -> PowerDNS + GnuPG + NSS/GnuTLS
-> Nginx + INN + PostFix + ... stack seems a little precarious to me.

Thank you very much for you patience, time and attention.

Thank you very much in advance for any help, advice, instruction,
protips, hints or references you may give me.

Thank you.

-- Alex Maurin <coyo AT darkdna DOT net>


From philip.jackson at nordnet.fr  Sun Jan 25 14:27:46 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sun, 25 Jan 2015 14:27:46 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C4BFD6.1060504@digitalbrains.com>
References: <54C3ECDE.8080806@nordnet.fr> <54C3F1A5.6020200@digitalbrains.com>
 <54C40D5D.4070500@nordnet.fr> <54C4BFD6.1060504@digitalbrains.com>
Message-ID: <54C4EF52.9030306@nordnet.fr>

On 25/01/15 11:05, Peter Lebbing wrote:
> I think it's quite likely --batch comes into play in your scenario, although I'm
> not well acquainted with the source code.
> 
> By the way, I think it'd be helpful if you could indicate your distribution and
> the version of GPA you use. Also, if you don't use the packages from your
> distribution but instead compile yourself, that would of course be very valuable
> information.

I'm using GPA 0.9.4 which was available within my distro which is UbuntuStudio
14.04.

I use gnupg 1.4.16 which is the standard issue with my distro.
I tried gnupg 2.0.22 which was the standard offered by my distro but I couldn't
get their installation to work at all and I concluded that there must be
something wrong with it so I downloaded and compiled/installed myself 2.0.26
last summer (ish) and this worked fine with Thunderbird/enigmail (so far).

Philip

-------------- 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/20150125/5c52e106/attachment-0001.sig>

From philip.jackson at nordnet.fr  Sun Jan 25 14:32:35 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sun, 25 Jan 2015 14:32:35 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C4CA17.2060306@incenp.org>
References: <54C3ECDE.8080806@nordnet.fr> <54C4CA17.2060306@incenp.org>
Message-ID: <54C4F073.8000508@nordnet.fr>

On 25/01/15 11:48, Damien Goutte-Gattat wrote:
> On 01/24/2015 08:05 PM, Philip Jackson wrote:
>> Using GPA 0.9.4 in linux.  [...]
>> So it appears to be a bit hit and miss trying to use GPA to verify downloaded
>> .asc signatures.
> 
> It looks like bug 1637 [1], which indeed affected gpa-0.9.4 but has been fixed
> in gpa-0.9.5 and later versions.
> 
> [1] https://bugs.g10code.com/gnupg/issue1637
> 
Thanks Damien - this looks like the issue I was facing.  I don't habitually use
GPA.  I did on this occasion because I accidentally opened GPA when I clicked
inadvertently on the downloaded signature file - so I decided to use GPA to
verify and got the 'bad' signature.

I'll try and upgrade the GPA.

Philip


-------------- 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/20150125/3ee72aa8/attachment.sig>

From philip.jackson at nordnet.fr  Sun Jan 25 14:49:58 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Sun, 25 Jan 2015 14:49:58 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C4CE16.6040905@digitalbrains.com>
References: <54C3ECDE.8080806@nordnet.fr> <54C4CA17.2060306@incenp.org>
 <54C4CE16.6040905@digitalbrains.com>
Message-ID: <54C4F486.30702@nordnet.fr>

On 25/01/15 12:05, Peter Lebbing wrote:
> It seems Philip is confusing signed files and detached signatures, by the way:
> 
>> > gpg --clearsign test1.txt gpg --clearsign -a test1.txt gpg --sign -a
>> > test1.txt
> The first two are exactly equivalent. Neither three produce a detached
> signature, which was the problematic case. The signed data is included in the
> .asc file, not kept as a separate file.

>> > gpg --detach-sign -a test1.txt
> This is the only one likely mimicking the files downloaded from the website:
> an ASCII-armoured, detached signature.

You are right, Peter, about the signed and detached being different cases.  I
did not know then that GPA 0.9.4 couldn't tell the difference between signed
files and detached signature files all having same .asc extension.

Normally I verify the download with the command line but to avoid typos in a
lengthy and complicated file name, I was copying and pasting the name from the
file manager display and I accidentally clicked on the name and caused GPA to open.

This is an indicator of the risks of having out of date versions of an
application that you don't normally use anyway still remaining on your system.

I'm sorry if I've wasted people's time with a worry from the past that no longer
exists.

Philip

-------------- 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/20150125/ef1c8dbe/attachment.sig>

From peter at digitalbrains.com  Sun Jan 25 17:25:04 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jan 2015 17:25:04 +0100
Subject: GPA fails to verify certain .asc files
In-Reply-To: <54C4F486.30702@nordnet.fr>
References: <54C3ECDE.8080806@nordnet.fr> <54C4CA17.2060306@incenp.org>
 <54C4CE16.6040905@digitalbrains.com> <54C4F486.30702@nordnet.fr>
Message-ID: <54C518E0.8090602@digitalbrains.com>

On 25/01/15 14:49, Philip Jackson wrote:
> I'm sorry if I've wasted people's time with a worry from the past that no
> longer exists.

It was totally reasonable to bring this to the list, so no need to apologise
as far as I'm concerned.

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 ott at mirix.org  Sun Jan 25 17:31:06 2015
From: ott at mirix.org (Matthias-Christian Ott)
Date: Sun, 25 Jan 2015 16:31:06 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C3CEEB.7030406@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org>
 <54C3CEEB.7030406@cardcontact.de>
Message-ID: <54C51A4A.8060403@mirix.org>

On 01/24/15 16:57, Andreas Schwier wrote:
> On 01/24/2015 12:05 AM, Matthias-Christian Ott wrote:
>> The same is true for the OpenPGP smart card or for almost any other
>> smart card available on the market. They could all contain a secret key
>> escrow mechanism and some probably do. Proprietary smart cards are hard
>> to audit and verify and are easy targets for backdoors and bugdoors.
> Can you provide any evidence for that claim or is this just paranoia ?
> 
> Working in the smart card industry for close to 30 years now, I've never
> come across an incident where a smart card was deliberately backdoor'ed.

This is just paranoia and pure speculation for which I have no evidence.
I just replied to an email that speculated that an intelligence agency
has an agreement with a card reader manufacturer to leave security
vulnerabilities unpatched. If you assume this, you also have to assume
that the proprietary OpenPGP card is also subject to such an agreement.

I also remarked that it would be technically feasible to deliberately
insert a key escrow mechanism or some other backdoor or bugdoor into a
smartcard. In the current global threat model we have to assume that
there are forces with enough power and resources to pursue anything that
is technically feasible. Whether you assume this threat model is up to
you and subject to your level of paranoia.

I don't think that such discussion belongs on this mailing list but I
felt that I had to intervene to stop portraying the OpenPGP card as a
secure solution. Any secure software has to be Free Software. Otherwise
it is very difficult to verify its security.

I think we could go on and on about threat models, security usability
and so on. Such a discussion would lead nowhere and is highly
speculative. In fact a smartcard with backdoor would probably be more
secure than the an average Windows computer or an unpatched Android
phone because it's more difficult to exploit. However, I think that it
is not healthy and dangerous to look at computer security from such
perspective and apply security economics and so on because it is
speculative and you compare people to money.

> Most smart cards used today in security sensitive mass applications like
> banking cards, signature cards, national id cards or passports must be
> independently evaluated and certified under the Common Criteria scheme.

EJBCA is also Common Criteria EAL4+ certified but still has bugs so such
certification is not a guarantee but merely an indicator. In a public
presentation an EJBCA developer also mentioned that the certification
organization only looked at the software at a conceptual level and never
audited the source code. So such certification does not prevent
backdoors or bugdoors and is essentially worthless if you assume such
threat model. With your experience you probably know more about Common
Criteria certification. I just repeated what happened in the case of EJBCA.

>From my experience as a software developer and Java Card in particular
I'm confident that it is very difficult if not impossible to develop a
secure implementation a specification of the complexity level of
GlobalPlatform or similar even if you use formal verification. There
will always be attacks that you did not anticipate. Without many eyes
looking at the source code you will never know if your software is secure.

So without repeating a discussion that is being repeating over and over
again about whether Free Software is more secure or applying a
perspective on security that only considers something to be secure or
insecure without somethin in between, I think it everyone on this
mailing list would agree that it is important for security that software
is Free Software and that proprietary smartcards are problematic.

> I can not image a way to introduce a backdoor without being detected
> during evaluation or in the secure delivery procedure. I can hardly
> imagine a smart card manufacturer or evaluator that has to take
> liability for a security product with a deliberately introduced backdoor.

I can imagine this. What do we do now? There is no mechanism to verify
this. If the smartcard manufacturer uses deterministic builds and
provided access to the source code, you could verify that to the extent
that you feel assured that the source code does not contain backdoors
and that the software on the smartcard is indeed the software that you
think it is.

> I agree, that we've seen bad implementations in smart cards. We've even
> seen certified products, that generated not so random numbers (Even
> though this was the classical case of a developer trying to be smarter
> than the user guidance allowed him to be).

A recent example would be the Taiwanese national ID cards. I could not
find the exact model and certificate for the card but I'm sure that they
were somehow certified and they are indeed used in "security sensitive
mass applications" without being "secure". I'm certain that the weak
random number generator would have been found if the source code had
been available and there had been a competition with reasonable prices
to comprise the cards before they were rolled out.

> Still smart cards have a case: They link the private key to a protective
> and controllable piece of hardware. I can disconnect the card from the
> PC and I can rest assured that no copies of the key exist and the key
> can not be misused (Unless someone steals card and PIN). That is an
> important security attribute that no software keys can provide for - at
> some point in time the software key must be somewhere in memory.

As already mentioned, under a certain threat model a successful attack
only needs two signatures: one for the revocation certificate and one to
sign the key of the attacker. And again I don't think we can discuss the
security or effectiveness of smartcards without a concrete thread model
because without that you can always argue that something is secure or
insecure if you assume X, Y and Z and the discussion leads nowhere. So
if you want to make this discussion fact-based and continue on, propose
a threat model that satisfies the needs of the person asking the
original question and we can carry on the discussion.

- Matthias-Christian


From peter at digitalbrains.com  Sun Jan 25 17:51:59 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jan 2015 17:51:59 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C51A4A.8060403@mirix.org>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org>
 <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org>
Message-ID: <54C51F2F.6000304@digitalbrains.com>

On 25/01/15 17:31, Matthias-Christian Ott wrote:
> [...] but I felt that I had to intervene to stop portraying the OpenPGP card 
> as a secure solution.

I suppose you and I read the following statement from that mail by Werner
quite differently:

On 23/01/15 21:31, Werner Koch wrote:
> Granted, other vendors also have easy changeable firmware but their 
> microcontrollers are smaller and writing malware for them is harder.

I don't see anybody in this thread saying the OpenPGP card is "secure", whatever
that is. In fact, the statement about Cyberjack is quantified in terms of ease
of implementation of a hack.

And I think the uncooperative attitude alone is a good reason to advise against
Cyberjack.

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 peter at digitalbrains.com  Sun Jan 25 22:44:27 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 25 Jan 2015 22:44:27 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de>
 <8F0B09FC6339FA439524099BFCABC11F2D3AA7F9@IRVEXCHMB11.corp.ad.broadcom.com>
Message-ID: <54C563BB.7060200@digitalbrains.com>

On 23/01/15 22:53, Bob (Robert) Cavanaugh wrote:
> Werner, What set would you recommend for us Linux types (Fedora 20 in my
> case) ?

Werner has posted on this mailing list what he uses himself; I suppose a good
search term should turn it up rather quickly from the archives.

SCM is pretty okay; I use two of SCM myself (SPR532 and I believe SCR3310; not
sure of the latter type number). I forgot what that reader Werner
uses is called.

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 wk at gnupg.org  Mon Jan 26 15:47:18 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Jan 2015 15:47:18 +0100
Subject: PGP and BeID
In-Reply-To: <54A5750F.9000308@telenet.be> (gabriel rosseel's message of "Thu, 
 01 Jan 2015 17:25:51 +0100")
References: <54A5750F.9000308@telenet.be>
Message-ID: <87fvax8uq1.fsf@vigenere.g10code.de>

On Thu,  1 Jan 2015 17:25, gabriel.rosseel at telenet.be said:

> As smartcard I use my Belgian EiD card with the the ACR38U as cardreader.

I never made that reader work for me under Linux.

> Additional software installed:
> 1. middleware (4.0.7 7453)
> 2. OpenPGP Smartcard Minidriver (OpenPGPmdrv-1.0.0.0)

If you run this there is a conflict with GnuPG which requires exclusve
access to the card.  You should try again after disabling above
software.  Note that you may use the card with GnupG only for S/MIME or
for ssh access - there is no OpenPGP support.

> I suspect that the OpenPGP software is the culprit and doesn't support
> my smartcard.

GnuPG _used_ to support it just fine on Unix systems and probably also
on Windows (never tested it).  In fact the BeID was the first card after
the OpenPGP card which I made work for ssh access.  Back then they
provided free samples and a full testing environment.  I have not looked
at it for many years, though.


Shalom-Salam,

   Werner

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



From patrick-mailinglists at whonix.org  Mon Jan 26 18:14:27 2015
From: patrick-mailinglists at whonix.org (Patrick Schleizer)
Date: Mon, 26 Jan 2015 17:14:27 +0000
Subject: gpg-bash-lib - parsing gpg's --status-fd - feedback desired -
 was: Is there a shell script or bash library for parsing gpg's --status-fd
 output?
In-Reply-To: <54B9583D.4070109@whonix.org>
References: <54B69CFF.5080506@whonix.org> <54B9583D.4070109@whonix.org>
Message-ID: <54C675F3.5090509@whonix.org>

Patrick Schleizer:
> apparently something like gpg-bash-lib didn't exist.
> 
> Created one:
> https://github.com/Whonix/gpg-bash-lib
> 
> Could you leave some feedback please?
> 
> Main code file:
> https://github.com/Whonix/gpg-bash-lib/blob/master/usr/lib/gpg-bash-lib/modules.d/50_common
> 
> No usage instructions yet, see unit test:
> https://github.com/Whonix/gpg-bash-lib/blob/master/usr/lib/gpg-bash-lib/unit_test
> 
> Specifically, does my status-fd parsing code look sane?
> https://github.com/Whonix/gpg-bash-lib/blob/0fc7a02b35f9580502daccf46692988b55961a23/usr/lib/gpg-bash-lib/modules.d/50_common#L172
> 
> Anyone else interested to contribute?

Comprehensive documentary and examples have been written.

https://github.com/Whonix/gpg-bash-lib

Please leave feedback.



From jernej at kos.mx  Mon Jan 26 22:09:38 2015
From: jernej at kos.mx (Jernej Kos)
Date: Mon, 26 Jan 2015 22:09:38 +0100
Subject: Manually changing smartcard state
Message-ID: <54C6AD12.1060808@kos.mx>

Hello!

Is it possible to change the smartcard state after PIN is entered, so it
would be back in the same state as it was when first inserted into the
reader (and would require the PIN to be entered again also for
decryption)? So without removing and re-inserting the card, possibly
using some APDU instructions.


Jernej

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

From 2014-667rhzu3dc-lists-groups at riseup.net  Tue Jan 27 00:48:39 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Mon, 26 Jan 2015 23:48:39 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C51A4A.8060403@mirix.org>
References: <54C1BF3A.2040903@gmail.com>
 <CA+m_8J13yyE=fH+iUu5FOd5uG9kNTziOTLEW+Zd0R0Kh-0cyzw@mail.gmail.com>
 <87iofxck7h.fsf@vigenere.g10code.de> <54C2D3AD.9080608@mirix.org>
 <54C3CEEB.7030406@cardcontact.de> <54C51A4A.8060403@mirix.org>
Message-ID: <1772039107.20150126234839@my_localhost>

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



On Sunday 25 January 2015 at 4:31:06 PM, in
<mid:54C51A4A.8060403 at mirix.org>, Matthias-Christian Ott wrote:



> As already mentioned, under a certain threat model a
> successful attack only needs two signatures: one for
> the revocation certificate and one to sign the key of
> the attacker.


Surely you only need the revocation certificate.

- --
Best regards

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

During an eruption - move away from the volcano - not towards it
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJUxtJaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwXrUH/2DfSpnUXWhwyfKChVyki/lK
h03eFw1Sx8DapFw3HnQb7Sjr0KbklUoAT5Tz/2Vp4caRZJlhW6/UprOPV00RpOOm
ILX9e9R/RdKciugZ88WE+dPZJHqaVZJ6FL1mCqHmjCMeH15ZJpIbp7zplqljcQt9
+1NxY+vbrt9wRvsdrkDRtCSnuAhTauPkP8S9on9mWhtF7I7ernA7cEf7/0oJ530P
e6gxGU8tkpHIUAgUQ+PUfkfeUBYxkBhfD/WK4BHkZZW0YGN0sfKECe3z2YFSLAmx
QmIu7Om4Rkp6Wj+N7Losn96uIinIJBmlYC9/Om+CFIbJyToqmZEL0EJGy8cq/VyI
vgQBFgoAZgUCVMbSZV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45NAQAQAYPGv55kDtny0bjkRyF2lnzFz5
rogINvu/PSAI2iK73wEANJ3uKkDdQpGx5zB1FVPHoakuFd1RnQdIBnH8hIcVNwA=
=4UB2
-----END PGP SIGNATURE-----



From johannes at zarl.at  Tue Jan 27 01:00:13 2015
From: johannes at zarl.at (Johannes Zarl)
Date: Tue, 27 Jan 2015 01:00:13 +0100
Subject: Manually changing smartcard state
In-Reply-To: <54C6AD12.1060808@kos.mx>
References: <54C6AD12.1060808@kos.mx>
Message-ID: <1781730.KMerevOVTH@mani>


> Is it possible to change the smartcard state after PIN is entered, so it
> would be back in the same state as it was when first inserted into the
> reader (and would require the PIN to be entered again also for
> decryption)? So without removing and re-inserting the card, possibly
> using some APDU instructions.

You can tell gpg-agent to lock the card using the following command[1]:

gpg-connect-agent 'SCD RESET' /bye

[1] http://lists.gnupg.org/pipermail/gnupg-users/2011-January/040478.html


From jernej at kos.mx  Tue Jan 27 09:12:47 2015
From: jernej at kos.mx (Jernej Kos)
Date: Tue, 27 Jan 2015 09:12:47 +0100
Subject: Manually changing smartcard state
In-Reply-To: <1781730.KMerevOVTH@mani>
References: <54C6AD12.1060808@kos.mx> <1781730.KMerevOVTH@mani>
Message-ID: <54C7487F.6000603@kos.mx>

Hello!

On 27. 01. 2015 01:00, Johannes Zarl wrote:
> You can tell gpg-agent to lock the card using the following command[1]:
> 
> gpg-connect-agent 'SCD RESET' /bye

Nice, this works, thank you!


Jernej

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

From felix.klee at inka.de  Tue Jan 27 17:24:32 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Tue, 27 Jan 2015 16:24:32 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C31A18.4040100@fsij.org>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net>
 <54C31A18.4040100@fsij.org>
Message-ID: <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>

On Sat, Jan 24, 2015 at 4:05 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> gnuk (running on the FST-01)

How does that store the private key? Password encrypted?

A smart card stores the key unencrypted, right?


From andreas.schwier.ml at cardcontact.de  Tue Jan 27 18:19:52 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Tue, 27 Jan 2015 18:19:52 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
Message-ID: <54C7C8B8.8050901@cardcontact.de>

On 01/27/2015 05:24 PM, Felix E. Klee wrote:
> A smart card stores the key unencrypted, right?
Quite typically not. The platform we use for the SmartCard-HSM generates
a random AES key during platform initialization and encrypts all key
material in EEPROM under this key. The only time the key is handled in
plain (plain meaning within the protected enclosure of the secure
microcontroller) is when the crypto unit performs a private key operation.

While the device is at rest, key material in EEPROM is encrypted, the
AES key is stored in a CPU memory area separate from the main EEPROM.

The same should be try for OpenPGP cards based on a JavaCard applet.
Can't tell how it is done on other OpenGPG compliant cards.

Of course a more important aspect is resistance to various side channel
attacks (DFA/DPA and a like). Mitigating that risk is quite challenging.

Andreas

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


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From andreas.schwier.ml at cardcontact.de  Tue Jan 27 18:23:45 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Tue, 27 Jan 2015 18:23:45 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <7296266.EQA0l8rLmz@inno>
References: <54C1BF3A.2040903@gmail.com> <54C31A18.4040100@fsij.org>
 <54C3D2D9.8040900@cardcontact.de> <7296266.EQA0l8rLmz@inno>
Message-ID: <54C7C9A1.8030701@cardcontact.de>

On 01/24/2015 08:27 PM, Hauke Laging wrote:
> The OpenPGP card does provide the opportunity to backup the on the card 
> generated key material.
Yes, but that uses a plain import/export of private keys, which defeats
the purpose of using a smart card to protect confidentiality of the keys.

I'd rather want a proper key escrow scheme were private keys are never
exposed at any interface.
> 
> 
> Hauke
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From felix.klee at inka.de  Tue Jan 27 18:34:56 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Tue, 27 Jan 2015 17:34:56 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C7C8B8.8050901@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net>
 <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C7C8B8.8050901@cardcontact.de>
Message-ID: <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>

On Tue, Jan 27, 2015 at 5:19 PM, Andreas Schwier
<andreas.schwier.ml at cardcontact.de> wrote:
> The platform we use for the SmartCard-HSM generates a random AES key
> during platform initialization and encrypts all key material in EEPROM
> under this key. The only time the key is handled in plain (plain
> meaning within the protected enclosure of the secure microcontroller)
> is when the crypto unit performs a private key operation.

Good! What PIN length do you recommend? (for the case that there is a
backdoor to get the *encrypted* key off the card)


From andreas.schwier.ml at cardcontact.de  Tue Jan 27 19:14:23 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Tue, 27 Jan 2015 19:14:23 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C7C8B8.8050901@cardcontact.de>
 <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>
Message-ID: <54C7D57F.4040907@cardcontact.de>

> Good! What PIN length do you recommend? (for the case that there is a
> backdoor to get the *encrypted* key off the card)
The encryption on the card is unrelated to the PIN. It's rather an
authentication object that blocks private key operations until the user
has entered the correct PIN.

With a retry counter of 3, I'd recommend a 6 digit PIN.

Andreas


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From felix.klee at inka.de  Tue Jan 27 19:35:37 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Tue, 27 Jan 2015 18:35:37 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C7D57F.4040907@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net>
 <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C7C8B8.8050901@cardcontact.de>
 <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>
 <54C7D57F.4040907@cardcontact.de>
Message-ID: <CA+m_8J2RcOJFsT1O9-WZsb7gCTMfA-oBYRe8R-qbtqxbHeq2OA@mail.gmail.com>

On Tue, Jan 27, 2015 at 6:14 PM, Andreas Schwier
<andreas.schwier.ml at cardcontact.de> wrote:
> The encryption on the card is unrelated to the PIN.

So the private key is encrypted with an AES key that is also stored on
the card? Then why encrypt the private key at all? Against what attack
does encryption of the private key on the card protect?


From andreas.schwier.ml at cardcontact.de  Tue Jan 27 21:01:02 2015
From: andreas.schwier.ml at cardcontact.de (Andreas Schwier)
Date: Tue, 27 Jan 2015 21:01:02 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <CA+m_8J2RcOJFsT1O9-WZsb7gCTMfA-oBYRe8R-qbtqxbHeq2OA@mail.gmail.com>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C7C8B8.8050901@cardcontact.de>
 <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>
 <54C7D57F.4040907@cardcontact.de>
 <CA+m_8J2RcOJFsT1O9-WZsb7gCTMfA-oBYRe8R-qbtqxbHeq2OA@mail.gmail.com>
Message-ID: <54C7EE7E.7020703@cardcontact.de>

On 01/27/2015 07:35 PM, Felix E. Klee wrote:
> On Tue, Jan 27, 2015 at 6:14 PM, Andreas Schwier
> <andreas.schwier.ml at cardcontact.de> wrote:
>> The encryption on the card is unrelated to the PIN.
> 
> So the private key is encrypted with an AES key that is also stored on
> the card? Then why encrypt the private key at all? Against what attack
> does encryption of the private key on the card protect?
Against certain hardware attacks that try to extract information from
EEPROM cells on the chip. The AES key is not stored in main EEPROM area
of the chip.

Encrypting keys at rest is just an additional measure beside all kind of
other tamper protection mechanisms implemented in modern smart card
micro controller.
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Sch?lerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com



From david at x00.at  Tue Jan 27 21:29:29 2015
From: david at x00.at (David Url)
Date: Tue, 27 Jan 2015 21:29:29 +0100
Subject: Publickey Algorithm IDs for --command-fd
Message-ID: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at>

Hello,

I was trying to automate the generation of subkeys, using the --command-fd option like this:
gpg --homedir /tmp/gnupgtest --status-fd 2 --no-tty --command-fd 0 --with-colons --edit-key E458A481 addkey

But i could not find the public key algorithm ids for ?GET_LINE keygen.algo? anywhere in the documentation.
It looks like the integers from the commandline interface without --command-fd, but is there any documentation on that?

Regards,
David

From wk at gnupg.org  Tue Jan 27 23:32:20 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jan 2015 23:32:20 +0100
Subject: Publickey Algorithm IDs for --command-fd
In-Reply-To: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at> (David Url's
 message of "Tue, 27 Jan 2015 21:29:29 +0100")
References: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at>
Message-ID: <87mw53yhvv.fsf@vigenere.g10code.de>

On Tue, 27 Jan 2015 21:29, david at x00.at said:

> But i could not find the public key algorithm ids for ?GET_LINE
> keygen.algo? anywhere in the documentation.  It looks like the
> integers from the commandline interface without --command-fd, but is
> there any documentation on that?

No.  And worse this is not a stable interface.  I have an idea on how to
solve this for 2.1 and it can also be backported to 1.4 and 2.0.  Please
give me some time until tomorrow.


Salam-Shalom,

   Werner

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



From peter at digitalbrains.com  Wed Jan 28 00:27:10 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 28 Jan 2015 00:27:10 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C7EE7E.7020703@cardcontact.de>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C7C8B8.8050901@cardcontact.de>
 <CA+m_8J1avAqoQ-Tm3t3ngvo9qgSVA2f1sEPsibf+v8LSpgg0DA@mail.gmail.com>
 <54C7D57F.4040907@cardcontact.de>
 <CA+m_8J2RcOJFsT1O9-WZsb7gCTMfA-oBYRe8R-qbtqxbHeq2OA@mail.gmail.com>
 <54C7EE7E.7020703@cardcontact.de>
Message-ID: <54C81ECE.7050400@digitalbrains.com>

On 27/01/15 21:01, Andreas Schwier wrote:
> Against certain hardware attacks that try to extract information from
> EEPROM cells on the chip. The AES key is not stored in main EEPROM area
> of the chip.

To put it in slightly different terms:

The AES key is only 16 or 32 bytes long (16 most likely). An RSA private key is
much longer. The 16 bytes holding the AES key are super well protected against
extraction, but this is expensive to produce on chip. The AES-encrypted private
key is stored in less protected memory, but the data is useless without
extracting the very well protected AES 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>


From gniibe at fsij.org  Wed Jan 28 02:46:59 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 28 Jan 2015 10:46:59 +0900
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
Message-ID: <54C83F93.3040904@fsij.org>

Thank you for your question.

On 01/28/2015 01:24 AM, Felix E. Klee wrote:
> On Sat, Jan 24, 2015 at 4:05 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
>> gnuk (running on the FST-01)
> 
> How does that store the private key? Password encrypted?

Gnuk stores private keys encrypted by AES.  The data encryption key
(DEK) of AES is generated by a TRNG routine named NeuG.  This DEK is
then encrypted by another AES KEY generated by S2K (string to key)
function with passphrase.  Gnuk's S2K function is taken from OpenPGP
specification (and with SHA256).  It's default s2kcount is 192 as the
MCU is slow enough, but you can configure it at compile time (like
65535 for host PC, or more).

>From the viewpoint of getting unencrypted private key, it's like:

     On flash ROM: Private key encrypted ------\
                                                \
     On flash ROM: DEK encrypted --\           [AES]--> Private key
                                  [AES]-> DEK --/
   Passphrase --[S2K]--------------/

It's much like OpenPGP, but Gnuk has additional step, because
OpenPGPcard specification also allows admin to access user's private
key.  This would be a weak point of OpenPGPcard specification, so,
Gnuk has its original feature to disable "admin" role.

			*	*	*

When we evaluate possible attacks, I think that it is very important
for us, OpenPGP users, who value the users control of their computing,
to understand the difference between:

	the structure of traditional smartcard industry

	the specific usage of OpenPGP with smartcard/token

For smartcard industry, "user" is actually the entity who purchases
the smartcard, and most of the cases, it's *not* the end user, but
it's a company who forces using smartcard to its customer/employee.
In this structure, "user" cares about the attacks by its
customer/employee.

On the other hand, typical usage of OpenPGPcard is by the end user of
GnuPG.  I realized that people tend to talk with the assumption of
smartcard industry, without considering our specific usage.


For Gnuk, serious threat would be software vulnerabilities of itself.

There would be a possible hole to circumvent "three time failures" of
passphrase.  Even if we had such a hole, slow enough S2K function
tries to prevent access to raw private key.  There would be a possible
hole to access MCU's internal flash directly.  In this case,
dictionary attack would be most effective (Gnuk allows passphrase
length up to 127, though).  Given the NeuG's randomness is good
enough, breaking encrypted private key directly would be difficult.

There would be a possible hole to get access to raw private key when
it's loaded to MCU's internal RAM, or by its computation side channel.
Well, I do my best not to have such a hole.  It's not for Gnuk, but I
fixed some in libgcrypt/GnuPG, you can evaluate those, say, changes in
the RSA implementation.

			*	*	*

The important point of using smartcard/token is to put your private
key under better control (as well as other points like portability,
etc.).  I think that it's better to use smartcard/token, than storing
the private key on disk of host PC.  Because it could be more simple
and solid.

>From this point, it is better for smartcard/token, not to have other
"useful features".  I'm afraid that something like that simply means
inviting more vulnerabilities or risks.

People might like "powerful" processor.  But, "slow enough" is an
important factor in my own threat model.  It's interesting that card
readers tend to have more powerful MCU than FST-01, these days.
-- 


From wk at gnupg.org  Wed Jan 28 09:27:31 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jan 2015 09:27:31 +0100
Subject: Publickey Algorithm IDs for --command-fd
In-Reply-To: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at> (David Url's
 message of "Tue, 27 Jan 2015 21:29:29 +0100")
References: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at>
Message-ID: <87egqfxqbw.fsf@vigenere.g10code.de>

Hi,

You will be able to do that with the next 2.1 and 2.0 release
For 2.1 this is commit b1d5ed6 and for 2.0 it is commit b2359db.

>From the 2.1 doc/DETAILS:

  When using a --command-fd controlled key generation or "addkey"
  there is way to know the number to enter on the "keygen.algo"
  prompt.  The displayed numbers are for human reception and may
  change with releases.  To provide a stable way to enter a desired
  algorithm choice the prompt also accepts predefined names for the
  algorithms, which will not change.

   | Name    | No | Description                     |
   |---------+----+---------------------------------|
   | rsa+rsa |  1 | RSA and RSA (default)           |
   | dsa+elg |  2 | DSA and Elgamal                 |
   | dsa     |  3 | DSA (sign only)                 |
   | rsa/s   |  4 | RSA (sign only)                 |
   | elg     |  5 | Elgamal (encrypt only)          |
   | rsa/e   |  6 | RSA (encrypt only)              |
   | dsa/*   |  7 | DSA (set your own capabilities) |
   | rsa/*   |  8 | RSA (set your own capabilities) |
   | ecc+ecc |  9 | ECC and ECC                     |
   | ecc/s   | 10 | ECC (sign only)                 |
   | ecc/*   | 11 | ECC (set your own capabilities) |
   | ecc/e   | 12 | ECC (encrypt only)              |
   | keygrip | 13 | Existing key                    |

   If one of the "foo/*" names are used a "keygen.flags" prompt needs
   to be answered as well.  Instead of toggling the predefined flags,
   it is also possible to set them direct: Use a "=" character
   directly followed by a comination of "a" (for authentication), "s"
   (for signing), or "c" (for certification).

ecc and keygrip are not available in 2.0.


Shalom-Salam,

   Werner


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



From felix.klee at inka.de  Wed Jan 28 10:14:48 2015
From: felix.klee at inka.de (Felix E. Klee)
Date: Wed, 28 Jan 2015 09:14:48 +0000
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C83F93.3040904@fsij.org>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net>
 <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C83F93.3040904@fsij.org>
Message-ID: <CA+m_8J1KOp6kwc9mtUESF2DW2kteU5Wso=CnhAr=U+eSqaPXmA@mail.gmail.com>

On Wed, Jan 28, 2015 at 1:46 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
> From the viewpoint of getting unencrypted private key, it's like:
>
>      On flash ROM: Private key encrypted ------\
>                                                 \
>      On flash ROM: DEK encrypted --\           [AES]--> Private key
>                                   [AES]-> DEK --/
>    Passphrase --[S2K]--------------/

Thanks a lot for this explanation!

> From this point, it is better for smartcard/token, not to have other
> "useful features".

I still would feel more comfortable with a pinpad, or some hardware
button (see thread ?crypto device where I need to confirm every
operation??).


From david at x00.at  Wed Jan 28 14:50:17 2015
From: david at x00.at (David Url)
Date: Wed, 28 Jan 2015 14:50:17 +0100
Subject: Publickey Algorithm IDs for --command-fd
In-Reply-To: <87egqfxqbw.fsf@vigenere.g10code.de>
References: <EE7B7FCF-F969-4B55-9592-E791EA2ABA1D@x00.at>
 <87egqfxqbw.fsf@vigenere.g10code.de>
Message-ID: <D3447AB4-F449-4CE0-AD14-FC0CE23BFEEC@x00.at>

Thank you for your fast response.
Thats exactly what i need.


From ndk.clanbo at gmail.com  Thu Jan 29 20:39:36 2015
From: ndk.clanbo at gmail.com (NdK)
Date: Thu, 29 Jan 2015 20:39:36 +0100
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54C83F93.3040904@fsij.org>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C83F93.3040904@fsij.org>
Message-ID: <54CA8C78.7020106@gmail.com>

Il 28/01/2015 02:46, NIIBE Yutaka ha scritto:

[...]
> specification (and with SHA256).  It's default s2kcount is 192 as the
> MCU is slow enough, but you can configure it at compile time (like
> 65535 for host PC, or more).
Uh, I think this exposes a weakness: if the attacker "somehow" accesses
the EEPROM and reads encrypted key material, a low s2k count means he
can recover plain key material quite faster than with more iterations.
Luckily it's configurable. :) Power of open source!

BYtE,
 Diego.



From gniibe at fsij.org  Fri Jan 30 01:26:13 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 30 Jan 2015 09:26:13 +0900
Subject: Talking about Cryptodevices... which one?
In-Reply-To: <54CA8C78.7020106@gmail.com>
References: <54C1BF3A.2040903@gmail.com>
 <87lhktldwz.fsf@alice.fifthhorseman.net> <54C31A18.4040100@fsij.org>
 <CA+m_8J2GCVVh1Cd=dZ_pyO_dsvphqNiqbyaBR7z=1amXjnDLzA@mail.gmail.com>
 <54C83F93.3040904@fsij.org> <54CA8C78.7020106@gmail.com>
Message-ID: <54CACFA5.80605@fsij.org>

On 2015-01-30 10:46 +0900, NIIBE Yutaka wrote:
> specification (and with SHA256).  It's default s2kcount is 192 as the
> MCU is slow enough, but you can configure it at compile time (like
> 65535 for host PC, or more).

On 01/30/2015 04:39 AM, NdK wrote:
> Uh, I think this exposes a weakness: if the attacker "somehow" accesses
> the EEPROM and reads encrypted key material, a low s2k count means he
> can recover plain key material quite faster than with more iterations.

You know (unconsciously, perhaps) and wrote "EEPROM", while it's Flash
ROM for Gnuk on FST-01.

192 is low.  That's somehow intentional artifact by me, so that people
can catch it to consider.  In our culture, it's not deliberately mean,
but a kind of communication tool.

Should we have configure time option for that, so that a person won't
need to edit manually?  Let's discuss on the gnuk-users mailing list.

For the data on some EEPROM, weaker key derivation function is on
active service, or even there is no key derivation function, I
believe.
--