what is the proper way to load gpg-agent with systemd

[Paulo Lopes]

Hello,

I've been using my gpg card with success in Ubuntu for a while but as
everyone knows the init system is switching from upstart to systemd as it
is happening on Debian and the vast majority of other distributions.

In the "past" one could start gpg-agent from the script that boots Xorg or
even the gnome-keyring and we could "inject" a couple of variables into the
session like

GPG_AGENT_INFO
SSH_AGENT_PID
SSH_AUTH_SOCK

and all applications spawned from that process inherit those vars, however
systemd does not inherit vars from its unit files (and my experience with
systemd is extremely low so i could be saying something wrong here).

It would be nice to have some documentation on gnupg site describing the
best way to work with systemd...
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Making the case for smart cards for the average user

[Daniel Kahn Gillmor]

On Mon 2015-03-16 20:55:51 -0400, MFPA wrote:

> Although I don't really like email addresses in the UIDs of my keys, I
> quite like the simplicity of your "email address only" simplified UID
> format. However, I would urge you to reconsider your decision to drop
> the angle brackets. At least one MUA (the MUA I am using to write this
> message) sends the email address enclosed in angle brackets as the
> search string for GnuPG to locate the key. No angle brackets around
> the email address means no key found.

This might be a bug (or at least a well-warranted feature enhancement)
in GnuPG.

I've just opened https://bugs.g10code.com/gnupg/issue1927 to track it.

 --dkg

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

Copy Current GPG Installation to Another Server

[Clark Rivard]

I currently have GPG 1.4.8 installed on a Windows server.  Can the c:\Programs 
Files (x86)\GNU\ directory simply be copied to another server and used or do I 
need to go through the "download and installation" process on the new server?   
Thanks.



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

Re: possible sshcontrol flag for ssh key comment?

[Peter Lebbing]

On 2015-03-16 14:36, Donavan-Ross Costaras wrote:
> Hi,

Hi!

I don't fully understand what you're trying to accomplish, or what you
exactly need. Sorry about that. I hope my reply might help you though.

> To present the correct key I use .ssh/confg to define the 
> identityFile (ssh key) used for that user.

I don't think "identityFile" still does anything when you use an agent,
or at least with GnuPG as an agent. Because it is the agent's
responsibility to keep keys, and you're changing the config for the ssh
program, which merely asks the agent what it has. I think.

> The problem is I cant add an ssh comment if I dont put the key 
> through something like monkeyshere or gpgkey2ssh.

With SSH2 keys, the comment is simply appended to the public key.
There's nothing more to it.

So I went with the following workflow:

First, I added the key in ~/.ssh/id_rsa to the gpg-agent. The public key
for that is already in ~/.ssh/id_rsa.pub, so I didn't need to extract
that from the agent.

Then, I inserted my OpenPGP smartcard with an authentication key. I
understand you're probably not using a smartcard, but I'm talking about
what I did :). It hopefully allows you to adapt it to your situation.

The smartcard key is automatically added to the ssh agent component of
gpg-agent. But, like you, I still need it's public key in SSH format to
paste in ~/.ssh/authorized_keys on the machines I want to login to, like
you need it to give to gitolite.

I do:

$ ssh-add -L
ssh-rsa B3N[...]TrnoZzZdHJ cardno:00050241
ssh-rsa B3N[...]TAiuL0Iw== /home/peter/.ssh/id_rsa
$

Now gpg-agent was kind enough to provide a comment that allows me to
distinguish them on sight. If there is no comment field, simply look at
the actual base64 key to see which one you're /not/ interested in, by
comparing to ~/.ssh/id_rsa.pub, for instance.

Now I copy the line ending in "cardno:[...]241" to the clipboard, and
open an editor for the new file ~/.ssh/id_card.pub. I paste from the
clipboard, but change the end:

ssh-rsa B3N[...]TrnoZzZdHJ peter@OpenPGPCard

All my SSH keys are of the form peter@hostname, and usually stored in
~/.ssh/id_rsa.pub. The filename and comment form are just to fit in with
the rest. It's free-format.

Now whenever I need to add that public key to a ~/.ssh/authorized_keys,
I don't use ssh-add -L, I simply open ~/.ssh/id_card.pub and copy it
from there. As I said, in SSH2 public keys, the comment is just text
appended to the key; there's nothing relating to it in that blob of
base64. You can just edit it with a text editor and store the result
wherever you like.

HTH,

Peter.

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

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 7:23 AM, Clark Rivard wrote:

I currently have GPG 1.4.8 installed on a Windows server.  Can the
c:\Programs Files (x86)\GNU\ directory simply be copied to another
server and used or do I need to go through the “download and
installation” process on the new server? Thanks.


1.4.8 is dangerously old. You should download the new version and 
install in both locations.


ftp://ftp.gnupg.org/gcrypt/binary/

hope this helps,

Doug


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

Re: what is the proper way to load gpg-agent with systemd

[Doug Barton]

On 3/17/15 7:48 AM, Paulo Lopes wrote:

Hello,

I've been using my gpg card with success in Ubuntu for a while but as
everyone knows the init system is switching from upstart to systemd as
it is happening on Debian and the vast majority of other distributions.

In the "past" one could start gpg-agent from the script that boots Xorg


Are you using the ssh-agent capabilities? If not, you don't need to do 
anything special to start the agent, it will use the socket method by 
default.


Also, do you have any evidence that the method you are currently using 
won't work with systemd? X starts well after the low-level system stuff 
is up and running, I'm having a hard time imagining why you couldn't 
continue doing what you're doing.


Doug


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

Re: what is the proper way to load gpg-agent with systemd

[Doug Barton]

Are you using gpg-agent to handle ssh agent responsibilities, yes or no?


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

Re: Making the case for smart cards for the average user

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Tuesday 17 March 2015 at 5:38:03 PM, in
, Daniel Kahn Gillmor
wrote:




> This might be a bug (or at least a well-warranted
> feature enhancement) in GnuPG.

> I've just opened
> https://bugs.g10code.com/gnupg/issue1927 to track it.

Thanks.

- --
Best regards

MFPA  

Take my advice - I don't use it anyway.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVCIEoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwAVYIAKYbEhLI9Iuiy87J7iuyPXWz
67f+oq8iiBq2V6/CcuS+5u5LJKhKhdeBbnSZLwXrEv6C7uRNAbvS3uLa0um2kQ3s
6L9rTmmsbuVURYcAsYsRdYSnPjB2G2t6ocCc9FwZMnsv6H5TCskrnsO82PcvjWjo
wlTzU/ESlujVirFYZKe0Cx+bhSb1FVG4kRcc657RoV6/HE6+kKEudIXn4JExyHmJ
8uNbsY6b2HEj8wxjEoTa54b0lSpb1XWQawolyxk7fVwqgKcpxBizvgqHEVWzuhH+
7skCdSZpX+bjBSb5ZyFA3dWanjc184zh+SH/oEWOsJ7VmcGuwPg3hJy8Kg5hhguI
vgQBFgoAZgUCVQiBRV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AG5AQBAJJysXSkrs+kxTsXOf5dFzG7y
+Tvzagn5cESWj7KSggEAs+rcnGKH9b6AY3eduOVKJ4vwUGgmn6vujD6yOUZs7Qw=
=b48P
-END PGP SIGNATURE-


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

RE: what is the proper way to load gpg-agent with systemd

[Clark Rivard]

I am running gpg command so I believe yes is the answer.  (I am a novice at 
this so still learning.)  

-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Doug 
Barton
Sent: Tuesday, March 17, 2015 2:21 PM
To: Paulo Lopes
Cc: gnupg-users@gnupg.org
Subject: Re: what is the proper way to load gpg-agent with systemd

Are you using gpg-agent to handle ssh agent responsibilities, yes or no?


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

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

Re: what is the proper way to load gpg-agent with systemd

[Doug Barton]

Ok, then you need to start the agent prior to or during the X startup, 
so that the variables are available to your environment (as you were 
doing previously).


So, why are you trying to start the agent with systemd? What method were 
you using previously, and did you try it in the new OS version?


Doug


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

Re: what is the proper way to load gpg-agent with systemd

[Paulo Lopes]

On Tue, Mar 17, 2015 at 7:19 PM, Doug Barton  wrote:

> On 3/17/15 7:48 AM, Paulo Lopes wrote:
>
>> Hello,
>>
>> I've been using my gpg card with success in Ubuntu for a while but as
>> everyone knows the init system is switching from upstart to systemd as
>> it is happening on Debian and the vast majority of other distributions.
>>
>> In the "past" one could start gpg-agent from the script that boots Xorg
>>
>
> Are you using the ssh-agent capabilities? If not, you don't need to do
> anything special to start the agent, it will use the socket method by
> default.
>

So what I did was to create a user unit file like this on ~/.local/:

[Unit]
Description=gpg-agent
ConditionFileIsExecutable=/usr/bin/gpg-agent

[Service]
ExecStart=/usr/bin/gpg-agent --daemon --enable-ssh-support
--scdaemon-program /usr/libexec/scdaemon --use-standard-socket --log-file
~/.gnupg/gpg-agent.log --write-env-file %h/$
ExecStop=/usr/bin/pkill gpg-agent
Type=forking
Restart=always

[Install]
WantedBy=default.target


Now what happens is that i start a java application "IntelliJ" and when i
try to get git to fetch some code it complains that the it cannot sign the
key. However if i use "pass" then the pinentry popup shows i enter my pin
and from there the git stuff works from intellij.

So it feels quite strange that i need to do all this juggling to get it
working :/

But i read about socket activation in your message so i guess my unit file
is wrong, could you share how to use socket activation? And if does that
how do you set the SSH agent variables?




>
> Also, do you have any evidence that the method you are currently using
> won't work with systemd? X starts well after the low-level system stuff is
> up and running, I'm having a hard time imagining why you couldn't continue
> doing what you're doing.
>
> Doug
>
>


-- 
Paulo Lopes
www.jetdrone.com
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Defaults

[Robert J. Hansen]

Given that 2.1 introduces a lot of new capabilities (mostly with respect
to ECC), I think now, early on in the 2.1 series, would be a good time
to discuss changing the defaults for newly-generated certificates.

In a nutshell:

* Offer Brainpool-512 and RSA-3072 as options for
  newly-generated certificates
* Use AES256 for a symmetric cipher
* Raise a warning if the user attempts to encrypt more
  than 4 GiB with an old (64-bit block) cipher
* Only use CAST5 if the user explicitly requests it via
  default-cipher-preferences: prefer 3DES over CAST5
* Only use IDEA if the user explicitly requests it via
  default-cipher-preferences: prefer 3DES over IDEA
* Use SHA256 for RSA-3072/-4096 signatures and SHA512
  for Brainpool-512

Rationale:

* Although there's nothing per se *wrong* with the current
  default of RSA-2048, realistically, 112 shannons of
  uncertainty is not enough to inspire long-term confidence
* Originally, a lot of smart cards couldn't support more
  than RSA-2048.  While this is still true on some platforms
  (it's hard to find RSA-3072 JavaCards), this does not
  appear to be generally true any more.
* AES256 is a world standard for symmetric encryption and
  appears to be resisting cryptanalysis better than AES128[*]
* A good rule of thumb is, "have twice as many bits of hash
  as there are shannons of uncertainty in the key."  RSA-3072
  provides ~128 shannons of uncertainty, hence SHA256.
  Brainpool-512 provides ~256 shannons of uncertainty, hence
  the recommendation for SHA512.
* CAST5 is not in good health: as was recently mentioned in
  the IETF WG mailing list, the Canadians themselves still
  allow it to be used for applications requiring 128 shannons
  of uncertainty... but not for secrets that need to be kept
  for more than a week.  That doesn't inspire much confidence
  in the long-term prospects of CAST5.
* Attacks on IDEA haven't been getting much better, but IDEA's
  been giving me the heebie-jeebies for about fifteen years
  now.  I'd *really* prefer it if we got rid of it altogether.
  Barring that, "only allow it to be used by explicit command"
  will work for me.
* 3DES is still the Rock of Gibraltar.  Big, slow, ungainly,
  and strong.  It's nobody's idea of a good modern cipher, but
  I still think it's a better bet than IDEA or CAST5 today.
* CFB modes will potentially recycle internal states after
  2**(blocksize/2) blocks [**].  For a 64-bit block cipher,
  that's 32GiB of data.  Given that we now have thumb drives
  larger than that, we need to consider the possibility users
  will be using GnuPG as a bulk encryption tool and warn them
  about potentially unsafe uses.  If 2**32 blocks (32 GiB)
  tends to be about the point at which we recycle state,
  let's declare 4 GiB to be the point at which we warn users
  against using a 64-bit block cipher.
* We've needed to make all these changes for years now.  I've
  always said we should defer on making big changes to the
  defaults until we had ECC in place for users to migrate to.
  Well, we've got ECC: let's start encouraging users to use it.
  And while we're at it, let's see about making these other
  overdue changes.


[*] As I read the tea leaves, I'm more convinced of AES256's long-term
strength than I am of AES128's.  However, the idea that either one of
them is somehow 'weak' is just ludicrous.  If you use AES128, don't
panic.  :)

[**] Don't believe me, though.  I haven't done any serious crypto work
in years and my memory could be off.  I vividly recall this warning in
both _Applied Cryptography_ and the _Handbook of Applied Cryptography_,
and I think it was also given in _Practical Cryptography_ and maybe
_Security Engineering_.  Check this before you believe it!



Thoughts?



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

Re: what is the proper way to load gpg-agent with systemd

[Doug Barton]

That question was for Paulo, not you. :)  And FWIW, since you're using 
GnuPG 1.x the answer is no.


Doug


On 3/17/15 12:32 PM, Clark Rivard wrote:

I am running gpg command so I believe yes is the answer.  (I am a novice at 
this so still learning.)

-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Doug 
Barton
Sent: Tuesday, March 17, 2015 2:21 PM
To: Paulo Lopes
Cc: gnupg-users@gnupg.org
Subject: Re: what is the proper way to load gpg-agent with systemd

Are you using gpg-agent to handle ssh agent responsibilities, yes or no?



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

RE: what is the proper way to load gpg-agent with systemd

[Clark Rivard]

OK - thanks.

-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email] 
Sent: Tuesday, March 17, 2015 3:08 PM
To: Clark Rivard; Paulo Lopes
Cc: gnupg-users@gnupg.org
Subject: Re: what is the proper way to load gpg-agent with systemd

That question was for Paulo, not you. :)  And FWIW, since you're using GnuPG 
1.x the answer is no.

Doug


On 3/17/15 12:32 PM, Clark Rivard wrote:
> I am running gpg command so I believe yes is the answer.  (I am a 
> novice at this so still learning.)
>
> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of 
> Doug Barton
> Sent: Tuesday, March 17, 2015 2:21 PM
> To: Paulo Lopes
> Cc: gnupg-users@gnupg.org
> Subject: Re: what is the proper way to load gpg-agent with systemd
>
> Are you using gpg-agent to handle ssh agent responsibilities, yes or no?

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

Article in Forbes.

[Eric F]

Perhaps not directly gnupg related, more OS X related. But, with both
GPGtools an GnuPG for OS X I'll post it here... (and there was this OS X
sec. discussion the other week) :)

It's seem like “Gatekeeper” is only using http if I read it correctly.

Ex-NSA Researcher Finds Sneaky Way Past Apple Mac's Gatekeeper
http://www.forbes.com/sites/thomasbrewster/2015/03/17/apple-mac-gatekeeper-bypass-exacerbated-by-unencrypted-av-downloads/

“He found around 150 on his own machine, including hugely popular
software like Microsoft Word and Excel, Apple’s own iCloud Photos and
Dropbox. The list also included Apple’s developer tool *XCODE and email
encryption key management software GPG Keychain, both of which he abused
in his proof of concept attacks*.”


I have no idea how this works, but one question that came in mind was if
a hijacked “GPG Keychain” on a Mac computer could form a threat to gpg
on other platforms?

Anyway, interesting reading. Just wanted to share.

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

Please keep things on the list so that the most users can be helped.

You need to run the --recv-key command first, or the --verify command 
will continue to fail.


Try this:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-key 4F25E3B6

Doug


On 3/17/15 1:23 PM, Clark Rivard wrote:

Doug

I ran the verify command and then tried the recv-key command but it came back 
with these messages

"no keyserver known "
"keyserver receive failed: bad URI"

I looked up the keyserver option but don’t know what keyserver name to use?

Thanks.


-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email]
Sent: Tuesday, March 17, 2015 3:07 PM
To: Clark Rivard
Subject: Re: Copy Current GPG Installation to Another Server

You need to download the key referenced in the first message:

gpg --recv-key 4F25E3B6

then do your verify command again:

gpg --verify gnupg-w32cli-1.4.19.exe.sig gnupg-w32cli-1.4.19.exe

and you should get a result like this:

gpg: Signature made Fri Feb 27 00:55:58 2015 PST using RSA key ID 4F25E3B6
gpg: Good signature from "Werner Koch (dist sig)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.

You can safely ignore the warning, it simply means that you have not validated 
the key yourself, which when it comes to signed packages is not really a 
necessity.

hope this helps,

Doug


On 3/17/15 12:17 PM, Clark Rivard wrote:

Thanks for your fast response, Doug.

I am new to this so am struggling through for the first time.

I downloaded Version 1.4.19 and am "Checking the Integrity".  I have a version 
of gpg installed (by someone else a long time ago).
I ran the "gpg" command to check whether the signature file matches
the source file.  I get two messages back

"Signature made 02/27/15 03:55:58 using RSA key ID...  
"Can't check signature: public key not found"

The ID shown with the first message is a valid ID for Werner Koch per the 
documentation I have.
The second line confuses me - makes me wonder if the integrity has been checked.

Has the integrity been properly checked or do I need to do more?   Any help you 
can provide is much appreciated.

Clark


-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email]
Sent: Tuesday, March 17, 2015 1:16 PM
To: Clark Rivard; gnupg-users@gnupg.org
Subject: Re: Copy Current GPG Installation to Another Server

On 3/17/15 7:23 AM, Clark Rivard wrote:

I currently have GPG 1.4.8 installed on a Windows server.  Can the
c:\Programs Files (x86)\GNU\ directory simply be copied to another
server and used or do I need to go through the “download and
installation” process on the new server? Thanks.


1.4.8 is dangerously old. You should download the new version and install in 
both locations.

ftp://ftp.gnupg.org/gcrypt/binary/

hope this helps,

Doug






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

RE: what is the proper way to load gpg-agent with systemd

[Paulo Lopes]

Yes!

-Original Message-
From: Doug Barton
Sent:  17/03/2015, 20:20 
To: Paulo Lopes
Cc: "gnupg-users@gnupg.org"
Subject: Re: what is the proper way to load gpg-agent with systemd


Are you using gpg-agent to handle ssh agent responsibilities, yes or no?



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

RE: Copy Current GPG Installation to Another Server

[Clark Rivard]

I ran the recv-key command again and got a message about "requesting key...from 
hkp server pool..." but then got "HTTP fetch error 7 couldn't connect: No 
error" 

Any ideas?  


-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email] 
Sent: Tuesday, March 17, 2015 3:28 PM
To: Clark Rivard
Cc: GnuPG Users
Subject: Re: Copy Current GPG Installation to Another Server

Please keep things on the list so that the most users can be helped.

You need to run the --recv-key command first, or the --verify command will 
continue to fail.

Try this:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-key 4F25E3B6

Doug


On 3/17/15 1:23 PM, Clark Rivard wrote:
> Doug
>
> I ran the verify command and then tried the recv-key command but it 
> came back with these messages
>
>   "no keyserver known "
>   "keyserver receive failed: bad URI"
>
> I looked up the keyserver option but don’t know what keyserver name to use?
>
> Thanks.
>
>
> -Original Message-
> From: Doug Barton [mailto:dougb@dougbarton.email]
> Sent: Tuesday, March 17, 2015 3:07 PM
> To: Clark Rivard
> Subject: Re: Copy Current GPG Installation to Another Server
>
> You need to download the key referenced in the first message:
>
> gpg --recv-key 4F25E3B6
>
> then do your verify command again:
>
> gpg --verify gnupg-w32cli-1.4.19.exe.sig gnupg-w32cli-1.4.19.exe
>
> and you should get a result like this:
>
> gpg: Signature made Fri Feb 27 00:55:58 2015 PST using RSA key ID 
> 4F25E3B6
> gpg: Good signature from "Werner Koch (dist sig)" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
>
> You can safely ignore the warning, it simply means that you have not 
> validated the key yourself, which when it comes to signed packages is not 
> really a necessity.
>
> hope this helps,
>
> Doug
>
>
> On 3/17/15 12:17 PM, Clark Rivard wrote:
>> Thanks for your fast response, Doug.
>>
>> I am new to this so am struggling through for the first time.
>>
>> I downloaded Version 1.4.19 and am "Checking the Integrity".  I have a 
>> version of gpg installed (by someone else a long time ago).
>> I ran the "gpg" command to check whether the signature file matches 
>> the source file.  I get two messages back
>>
>>  "Signature made 02/27/15 03:55:58 using RSA key ID...   
>>  "Can't check signature: public key not found"
>>
>> The ID shown with the first message is a valid ID for Werner Koch per the 
>> documentation I have.
>> The second line confuses me - makes me wonder if the integrity has been 
>> checked.
>>
>> Has the integrity been properly checked or do I need to do more?   Any help 
>> you can provide is much appreciated.
>>
>> Clark
>>
>>
>> -Original Message-
>> From: Doug Barton [mailto:dougb@dougbarton.email]
>> Sent: Tuesday, March 17, 2015 1:16 PM
>> To: Clark Rivard; gnupg-users@gnupg.org
>> Subject: Re: Copy Current GPG Installation to Another Server
>>
>> On 3/17/15 7:23 AM, Clark Rivard wrote:
>>> I currently have GPG 1.4.8 installed on a Windows server.  Can the 
>>> c:\Programs Files (x86)\GNU\ directory simply be copied to another 
>>> server and used or do I need to go through the “download and 
>>> installation” process on the new server? Thanks.
>>
>> 1.4.8 is dangerously old. You should download the new version and install in 
>> both locations.
>>
>> ftp://ftp.gnupg.org/gcrypt/binary/
>>
>> hope this helps,
>>
>> Doug
>>
>

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 1:42 PM, Clark Rivard wrote:

I ran the recv-key command again and got a message about "requesting key...from hkp server 
pool..." but then got "HTTP fetch error 7 couldn't connect: No error"

Any ideas?


Try it a few more times, you may have gotten a bad server from the pool. 
If it still doesn't work, try the following:


hkp://keys.gnupg.net
hkp://subkeys.pgp.net
hkp://pgp.mit.edu

... and of course all of this assumes that the systems in question have 
network connectivity ...


Doug


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

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

>> -Original Message-
>> From: Doug Barton [mailto:dougb@dougbarton.email]
>> Sent: Tuesday, March 17, 2015 3:07 PM
>> To: Clark Rivard
>> Subject: Re: Copy Current GPG Installation to Another Server
>> gpg: Signature made Fri Feb 27 00:55:58 2015 PST using RSA key ID
>> 4F25E3B6
>> gpg: Good signature from "Werner Koch (dist sig)" [unknown]
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg:  There is no indication that the signature belongs to the
>> owner.
>>
>> You can safely ignore the warning, it simply means that you have not
>> validated the key yourself, which when it comes to signed packages is
>> not really a necessity.

Why is that? I understand getting a validated key can be tricky in
practice, but on the other hand, using *just* a short key ID to do your
verification feels like the other end of the spectrum... I think you
should at least verify the fingerprint on a web site or something.

Peter.

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

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

RE: Defaults

[Bob (Robert) Cavanaugh]

My vote is for the defaults Robert is proposing. Definitely in keeping with 
what else I have been reading.

Thanks,
 
Bob Cavanaugh


> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-
> bounces+robertc=broadcom@gnupg.org] On Behalf Of Robert J.
> Hansen
> Sent: Tuesday, March 17, 2015 12:45 PM
> To: gnupg
> Subject: Defaults
> 
> Given that 2.1 introduces a lot of new capabilities (mostly with respect to
> ECC), I think now, early on in the 2.1 series, would be a good time to discuss
> changing the defaults for newly-generated certificates.
> 
> In a nutshell:
> 
>   * Offer Brainpool-512 and RSA-3072 as options for
> newly-generated certificates
>   * Use AES256 for a symmetric cipher
>   * Raise a warning if the user attempts to encrypt more
> than 4 GiB with an old (64-bit block) cipher
>   * Only use CAST5 if the user explicitly requests it via
> default-cipher-preferences: prefer 3DES over CAST5
>   * Only use IDEA if the user explicitly requests it via
> default-cipher-preferences: prefer 3DES over IDEA
>   * Use SHA256 for RSA-3072/-4096 signatures and SHA512
> for Brainpool-512
> 
> Rationale:
> 
>   * Although there's nothing per se *wrong* with the current
> default of RSA-2048, realistically, 112 shannons of
> uncertainty is not enough to inspire long-term confidence
>   * Originally, a lot of smart cards couldn't support more
> than RSA-2048.  While this is still true on some platforms
> (it's hard to find RSA-3072 JavaCards), this does not
> appear to be generally true any more.
>   * AES256 is a world standard for symmetric encryption and
> appears to be resisting cryptanalysis better than AES128[*]
>   * A good rule of thumb is, "have twice as many bits of hash
> as there are shannons of uncertainty in the key."  RSA-3072
> provides ~128 shannons of uncertainty, hence SHA256.
> Brainpool-512 provides ~256 shannons of uncertainty, hence
> the recommendation for SHA512.
>   * CAST5 is not in good health: as was recently mentioned in
> the IETF WG mailing list, the Canadians themselves still
> allow it to be used for applications requiring 128 shannons
> of uncertainty... but not for secrets that need to be kept
> for more than a week.  That doesn't inspire much confidence
> in the long-term prospects of CAST5.
>   * Attacks on IDEA haven't been getting much better, but IDEA's
> been giving me the heebie-jeebies for about fifteen years
> now.  I'd *really* prefer it if we got rid of it altogether.
> Barring that, "only allow it to be used by explicit command"
> will work for me.
>   * 3DES is still the Rock of Gibraltar.  Big, slow, ungainly,
> and strong.  It's nobody's idea of a good modern cipher, but
> I still think it's a better bet than IDEA or CAST5 today.
>   * CFB modes will potentially recycle internal states after
> 2**(blocksize/2) blocks [**].  For a 64-bit block cipher,
> that's 32GiB of data.  Given that we now have thumb drives
> larger than that, we need to consider the possibility users
> will be using GnuPG as a bulk encryption tool and warn them
> about potentially unsafe uses.  If 2**32 blocks (32 GiB)
> tends to be about the point at which we recycle state,
> let's declare 4 GiB to be the point at which we warn users
> against using a 64-bit block cipher.
>   * We've needed to make all these changes for years now.  I've
> always said we should defer on making big changes to the
> defaults until we had ECC in place for users to migrate to.
> Well, we've got ECC: let's start encouraging users to use it.
> And while we're at it, let's see about making these other
> overdue changes.
> 
> 
> [*] As I read the tea leaves, I'm more convinced of AES256's long-term
> strength than I am of AES128's.  However, the idea that either one of them is
> somehow 'weak' is just ludicrous.  If you use AES128, don't panic.  :)
> 
> [**] Don't believe me, though.  I haven't done any serious crypto work in
> years and my memory could be off.  I vividly recall this warning in both
> _Applied Cryptography_ and the _Handbook of Applied Cryptography_, and I
> think it was also given in _Practical Cryptography_ and maybe _Security
> Engineering_.  Check this before you believe it!
> 
> 
> 
> Thoughts?

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

RE: Copy Current GPG Installation to Another Server

[Clark Rivard]

I tried all of the options below but still got the "HTTP fetch error 7".   

I used the "sha1sum" option and got the expected result - does this verify the 
integrity adequately?  

-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email] 
Sent: Tuesday, March 17, 2015 3:46 PM
To: Clark Rivard
Cc: GnuPG Users
Subject: Re: Copy Current GPG Installation to Another Server

On 3/17/15 1:42 PM, Clark Rivard wrote:
> I ran the recv-key command again and got a message about "requesting 
> key...from hkp server pool..." but then got "HTTP fetch error 7 couldn't 
> connect: No error"
>
> Any ideas?

Try it a few more times, you may have gotten a bad server from the pool. 
If it still doesn't work, try the following:

hkp://keys.gnupg.net
hkp://subkeys.pgp.net
hkp://pgp.mit.edu

... and of course all of this assumes that the systems in question have network 
connectivity ...

Doug

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:09 PM, Clark Rivard wrote:

I tried all of the options below but still got the "HTTP fetch error 7".


That would indicate that the system(s) do not have access to the 
Internet. Is that an expected result?



I used the "sha1sum" option and got the expected result - does this verify the 
integrity adequately?


I can't tell you what is adequate for your situation. You have to make 
that judgement yourself.


Doug



-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email]
Sent: Tuesday, March 17, 2015 3:46 PM
To: Clark Rivard
Cc: GnuPG Users
Subject: Re: Copy Current GPG Installation to Another Server

On 3/17/15 1:42 PM, Clark Rivard wrote:

I ran the recv-key command again and got a message about "requesting key...from hkp server 
pool..." but then got "HTTP fetch error 7 couldn't connect: No error"

Any ideas?


Try it a few more times, you may have gotten a bad server from the pool.
If it still doesn't work, try the following:

hkp://keys.gnupg.net
hkp://subkeys.pgp.net
hkp://pgp.mit.edu

... and of course all of this assumes that the systems in question have network 
connectivity ...

Doug




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

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

On 17/03/15 22:09, Clark Rivard wrote:
> I used the "sha1sum" option and got the expected result - does this verify 
> the integrity adequately?  

It's just as good as verifying the signature of a key with short ID 4F25E3B6. As
you can soon see elsewhere in this thread, I don't think it practically adds
anything. Proper verification of the key requires not relying on the short key
ID, or even the long one for that matter. It means you check the fingerprint of
the key, which is much longer.

HTH,

Peter.

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

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

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

On 17/03/15 22:04, Doug Barton wrote:
> Assuming you get the package, the signature, and the fingerprint from the same
> *.gnupg.org resources, what does that buy you?

Assuming they're all protected by https, nothing.

What does verification of that signature buy you though? That your download
wasn't corrupted?

> If you've somehow downloaded the wrong key by short Id, the signature won't
> validate. If you have the right key, it will. That's enough to tell the user
> that the contents of the package are unaltered.

If I were to place something nefarious inside a GnuPG download, I'd sign the
result with a key I created with the short key ID 4F25E3B6. That way, your
--recv-key command will retrieve both my key and Werners, and the signature will
happily validate. Creating a short key ID collision is peanuts and can be done
with off-the-shelf software on a laptop.

This rakes in not just the people who don't check the signature, but also all
those who just verify the short key ID. Since it's hardly any effort, I'd do it,
even though it probably only gains me a few percent coverage.

> More extensive checking would be great, but would require a lot of 
> documentation
> to teach the users how to do it ... are you volunteering to write it? :)

No, but I'm also not telling people they can verify using the short key ID. No
guidance is better than wrong guidance, IMHO. No offence meant, I appreciate you
helping him out. I'm just trying to give some constructive criticism.

HTH,

Peter.

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

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

Re: Defaults

[René Puls]

On Tue, 17 Mar 2015 15:44:47 -0400 Robert J. Hansen wrote:
> [*] As I read the tea leaves, I'm more convinced of AES256's long-term
> strength than I am of AES128's.  However, the idea that either one of
> them is somehow 'weak' is just ludicrous.  If you use AES128, don't
> panic.  :)

I remember reading about an attack that works better against AES-256
than AES-128:

https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

Bruce Schneier wrote:

> And for new applications I suggest that people don't use AES-256.
> AES-128 provides more than enough security margin for the forseeable
> future. But if you're already using AES-256, there's no reason to
> change.

I am not qualified to argue for or against either cipher, but I wonder
if this advice from 2009 is still valid today.

René

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

RE: Copy Current GPG Installation to Another Server

[Clark Rivard]

How do you check the fingerprint? 

-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Peter 
Lebbing
Sent: Tuesday, March 17, 2015 4:19 PM
To: Doug Barton
Cc: GnuPG Users
Subject: Re: Copy Current GPG Installation to Another Server

On 17/03/15 22:04, Doug Barton wrote:
> Assuming you get the package, the signature, and the fingerprint from 
> the same *.gnupg.org resources, what does that buy you?

Assuming they're all protected by https, nothing.

What does verification of that signature buy you though? That your download 
wasn't corrupted?

> If you've somehow downloaded the wrong key by short Id, the signature 
> won't validate. If you have the right key, it will. That's enough to 
> tell the user that the contents of the package are unaltered.

If I were to place something nefarious inside a GnuPG download, I'd sign the 
result with a key I created with the short key ID 4F25E3B6. That way, your 
--recv-key command will retrieve both my key and Werners, and the signature 
will happily validate. Creating a short key ID collision is peanuts and can be 
done with off-the-shelf software on a laptop.

This rakes in not just the people who don't check the signature, but also all 
those who just verify the short key ID. Since it's hardly any effort, I'd do 
it, even though it probably only gains me a few percent coverage.

> More extensive checking would be great, but would require a lot of 
> documentation to teach the users how to do it ... are you volunteering 
> to write it? :)

No, but I'm also not telling people they can verify using the short key ID. No 
guidance is better than wrong guidance, IMHO. No offence meant, I appreciate 
you helping him out. I'm just trying to give some constructive criticism.

HTH,

Peter.

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

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

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:27 PM, Clark Rivard wrote:

How do you check the fingerprint?


Step 1 is that you have to get a validated version of the fingerprint of 
the key that you would have been using to verify the package if you 
could have downloaded that key in the first place.


The concept of validating keys is a much more advanced topic, and while 
I admire Peter's enthusiasm, isn't really a useful exercise for you to 
engage in at this point, especially since you can't seem to download the 
key that you would be validating with the fingerprint in the first place.


Doug



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

Re: Defaults

[Robert J. Hansen]

> I remember reading about an attack that works better against AES-256 
> than AES-128:

That one's a related-key attack, which requires the attacker to have a
significant number of keys that have some mathematical relationship to
each other.

OpenPGP uses random nonces for symmetric keys (or iterated hashing,
which does a pretty good job of destroying mathematical relationships),
so this attack is a complete nonissue for OpenPGP.  :)

> I am not qualified to argue for or against either cipher, but I
> wonder if this advice from 2009 is still valid today.

The biggest reason, IMO, to move to 256-bit ciphers is because it will
hopefully quell the voices who are screaming that 128-bit crypto is
somehow insufficient.  It's not, and no one has ever presented any
serious evidence that it is, but these arguments crop up with great
regularity nevertheless.



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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:19 PM, Peter Lebbing wrote:

On 17/03/15 22:04, Doug Barton wrote:

Assuming you get the package, the signature, and the fingerprint from the same
*.gnupg.org resources, what does that buy you?


Assuming they're all protected by https, nothing.


I think you missed my point. If all three resources related to 
verification are provided by the same source, then verifying the 
fingerprint gets you zero added security. It's more or less equivalent 
to using a hash by itself.



What does verification of that signature buy you though? That your download
wasn't corrupted?


I covered that later in the message, but basically, yes.


If you've somehow downloaded the wrong key by short Id, the signature won't
validate. If you have the right key, it will. That's enough to tell the user
that the contents of the package are unaltered.


If I were to place something nefarious inside a GnuPG download,


So to start with, that's a pretty big hurdle to jump, and if you have 
access to do that, then you almost certainly have access to do other 
things like changing the fingerprint to verify.


So in my threat model once Eve has access to the site where the 
downloads are posted, it's already game over. You can posit a threat 
model where Eve has access to one thing, but not the other, and that's 
fine; but there are way too many technical and social engineering tricks 
that can be performed if you have access to just the downloads. Your 
idea of "verify the fingerprint from a web page" provides little to no 
improved security in a world where the nefarious actor has no access to 
the downloads in the first place, and zero when they do.



I'd sign the
result with a key I created with the short key ID 4F25E3B6.


Why would you bother? Why not just sign it with a completely new key, 
and include in the comments something like "2015 Q1 Signing key for 
official purposes?" That's enough social engineering to "catch" the 
overwhelming majority of users, even the ones sophisticated enough to 
actually review the key that they just downloaded.



That way, your
--recv-key command will retrieve both my key and Werners, and the signature will
happily validate. Creating a short key ID collision is peanuts and can be done
with off-the-shelf software on a laptop.


... even assuming that this is relevant ...


This rakes in not just the people who don't check the signature,


when the malicious actor has access to the downloads, those people are 
already hosed, regardless of what extra security you're suggesting.



but also all
those who just verify the short key ID. Since it's hardly any effort, I'd do it,
even though it probably only gains me a few percent coverage.


... and as above, it's totally unnecessary.


More extensive checking would be great, but would require a lot of documentation
to teach the users how to do it ... are you volunteering to write it? :)


No, but I'm also not telling people they can verify using the short key ID. No
guidance is better than wrong guidance, IMHO.


In the first place, I disagree with your premise that no guidance is 
better. If for no other reason than providing the "wrong" guidance is 
likely to spur the people with the "right" answer into responding when 
they otherwise would not.


I also disagree with you that I'm providing the wrong guidance. :)

Doug


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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 1:54 PM, Peter Lebbing wrote:

-Original Message-
From: Doug Barton [mailto:dougb@dougbarton.email]
Sent: Tuesday, March 17, 2015 3:07 PM
To: Clark Rivard
Subject: Re: Copy Current GPG Installation to Another Server
gpg: Signature made Fri Feb 27 00:55:58 2015 PST using RSA key ID
4F25E3B6
gpg: Good signature from "Werner Koch (dist sig)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.

You can safely ignore the warning, it simply means that you have not
validated the key yourself, which when it comes to signed packages is
not really a necessity.


Why is that?


Because in this situation you're often dealing with beginners who don't 
understand the subtleties involved in validating keys.



I understand getting a validated key can be tricky in
practice, but on the other hand, using *just* a short key ID to do your
verification feels like the other end of the spectrum... I think you
should at least verify the fingerprint on a web site or something.


Assuming you get the package, the signature, and the fingerprint from 
the same *.gnupg.org resources, what does that buy you?


If you've somehow downloaded the wrong key by short Id, the signature 
won't validate. If you have the right key, it will. That's enough to 
tell the user that the contents of the package are unaltered.


More extensive checking would be great, but would require a lot of 
documentation to teach the users how to do it ... are you volunteering 
to write it? :)


Doug



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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 8:44 PM, Robert J. Hansen wrote:
> Given that 2.1 introduces a lot of new capabilities (mostly with respect
> to ECC), I think now, early on in the 2.1 series, would be a good time
> to discuss changing the defaults for newly-generated certificates.
> 
> In a nutshell:
> 
>   * Offer Brainpool-512 and RSA-3072 as options for
> newly-generated certificates

I mostly agree. However, I have a few minor points:

- Above RSA-2048, keys and signatures become quite large. DSA signatures
increase slightly, but are considerably smaller than RSA signatures.

As long as we're considering "legacy" algorithms like RSA and DSA, is
there any particular reason for preferring RSA over DSA at such key
lengths? I know that DSA is only defined up to DSA-3072, so those who
wish to use larger keys would need to use RSA or ECC, but why not use
DSA as the default?

Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x also
have that feature?

- The Brainpool curves are similar in structure to the NIST curves,
though their curve parameters are chosen in a clear, open manner. While
that leads to increased trust that the parameters aren't chosen for
nefarious purposes, if one is already making a major change to ECC, why
not use some other, more modern curve that's designed at a high-security
level?

Curve M-511 comes to mind, as it's similar to Curve25519 (which GnuPG
already implements).

See http://safecurves.cr.yp.to/ -- djb and Lange clearly lay out their
criteria for different curves and why they're categorized they way they
are. I'm nothing more than an interested amateur in this subject, but
why not benefit from their efforts?

>   * Use AES256 for a symmetric cipher
>   * Raise a warning if the user attempts to encrypt more
> than 4 GiB with an old (64-bit block) cipher

Agreed.

>   * Only use CAST5 if the user explicitly requests it via
> default-cipher-preferences: prefer 3DES over CAST5

(Rationale)
>   * CAST5 is not in good health: as was recently mentioned in
> the IETF WG mailing list, the Canadians themselves still
> allow it to be used for applications requiring 128 shannons
> of uncertainty... but not for secrets that need to be kept
> for more than a week.  That doesn't inspire much confidence
> in the long-term prospects of CAST5.

Do you have a link to this discussion on the IETF list? I suspect the
community here would be very interested.

>   * Only use IDEA if the user explicitly requests it via
> default-cipher-preferences: prefer 3DES over IDEA

(Rationale)
>   * Attacks on IDEA haven't been getting much better, but IDEA's
> been giving me the heebie-jeebies for about fifteen years
> now.  I'd *really* prefer it if we got rid of it altogether.
> Barring that, "only allow it to be used by explicit command"
> will work for me.

Is there something particular about IDEA that concerns you?

>   * Use SHA256 for RSA-3072/-4096 signatures and SHA512
> for Brainpool-512

Agreed.

>   * We've needed to make all these changes for years now.  I've
> always said we should defer on making big changes to the
> defaults until we had ECC in place for users to migrate to.
> Well, we've got ECC: let's start encouraging users to use it.
> And while we're at it, let's see about making these other
> overdue changes.

Alas, a lot of Linux distributions are quite slow-moving: it's unlikely
that distributions like Debian and Ubuntu will have GnuPG 2.1.x
available (let alone installed by default) for several years.

Yes, the changes should be made, but ECC support won't be widely
available to most users for some time.

Cheers!
-Pete

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

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

On 17/03/15 22:56, Peter Lebbing wrote:
> and checking it says
> 
> pub   2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
>   Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
> uid   [  full  ] Werner Koch (dist sig)
> sub   2048R/AC87C71A 2011-01-12 [expires: 2019-12-31]

Hah! Obviously it wouldn't say "full", firstly because you need list-options
show-uid-validity in your gpg.conf, and secondly because the whole issue here is
you didn't have a trust path to that key. I met Werner at the 31C3 this
December, so I can in fact now finally check the validity of this key! :)

Should properly read stuff I copy-paste before I send the message...

Peter.

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

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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 2:56 PM, Peter Lebbing wrote:

On 17/03/15 22:34, Doug Barton wrote:

Assuming they're all protected by https, nothing.


I think you missed my point. If all three resources related to verification are
provided by the same source, then verifying the fingerprint gets you zero added
security. It's more or less equivalent to using a hash by itself.


No, I think that's what I mean as well. If they all come from the same source,
it gets you nothing to check the signature. So I don't see why you would verify
the signature at all.


Because it tells you that the package was not tampered with. I've 
covered this several times now.



So to start with, that's a pretty big hurdle to jump, and if you have access to
do that, then you almost certainly have access to do other things like changing
the fingerprint to verify.


By creating a short key ID collision, I'm also getting those people that read
your e-mail or a similar thing somewhere on the web, and just download the short
key ID. I'm also getting those people that get a "BAD signature" and then do a
new --recv-key with the short key ID in an unfortunate attempt to get it to
verify ("hmmm, maybe it has expired?").


Again, I think you're missing the bigger picture here. If you have write 
access to the FTP site, why would you even bother creating the signature 
for your malicious package with a key that has the same short key Id?


You're trying to defend against an incredibly unlikely threat model. If 
I download 'malicious package' + 'signature for malicious package 
created by key controlled by malicious actor,' one of two things is 
overwhelmingly likely to happen:


1. I blindly import the key, verify the signature, and move on; or
2. I import the key, perform a cursory review, verify the signature, and 
move on.


Either way, your short key Id collision is out of spec. The user in this 
situation has no way to know that there should be a short key Id other 
than the one that is related to the signature that they have in hand. 
Since both the package and the signature are under Eve's control, the 
threat model you are suggesting is a complete red herring.



But back to my primary objection:

I consider it bad advice to tell someone to rely on the short key ID. Sounds
like a bad habit potentially getting bootstrapped to me.

That's really all this is about.


Thank you for confirming your real motives. :) I understand in theory 
that relying solely on the short key Id is not a good practice in a 
situation where you want things to be "very secure." But we do indeed 
have a bootstrapping issue here, which is, "Where do you start when it 
comes to rank beginners?" I think you are asking way too much, and 
giving near-zero value in return.



You could also say they should check the sha1sum, like Clark ended up doing. Or
typing

gpg --fingerprint -k 4F25E3B6

and checking it says

pub   2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
   Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
uid   [  full  ] Werner Koch (dist sig)
sub   2048R/AC87C71A 2011-01-12 [expires: 2019-12-31]

with a little caveat that you should actually get the fingerprint from somewhere
trusted, not from a stranger.


Sure, but now you've entered a very sticky briar patch, with a lot of 
bootstrapping knowledge that is not easy for a rank beginner to grasp. 
You and I "get" what you're talking about, but that knowledge came from 
experience. (and again, the extra security that you get is of very 
limited value at this stage of the game)


Doug


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

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

On 17/03/15 22:34, Doug Barton wrote:
>> Assuming they're all protected by https, nothing.
> 
> I think you missed my point. If all three resources related to verification 
> are
> provided by the same source, then verifying the fingerprint gets you zero 
> added
> security. It's more or less equivalent to using a hash by itself.

No, I think that's what I mean as well. If they all come from the same source,
it gets you nothing to check the signature. So I don't see why you would verify
the signature at all.

> So to start with, that's a pretty big hurdle to jump, and if you have access 
> to
> do that, then you almost certainly have access to do other things like 
> changing
> the fingerprint to verify.

By creating a short key ID collision, I'm also getting those people that read
your e-mail or a similar thing somewhere on the web, and just download the short
key ID. I'm also getting those people that get a "BAD signature" and then do a
new --recv-key with the short key ID in an unfortunate attempt to get it to
verify ("hmmm, maybe it has expired?").

Like you said, I passed a big hurdle. I'm either MITM, or I write-accessed the
ftp server of gnupg.org. Why stop there when it's so little effort to create a
short key ID collision? It sounds fun in a perverse way.

But back to my primary objection:

I consider it bad advice to tell someone to rely on the short key ID. Sounds
like a bad habit potentially getting bootstrapped to me.

That's really all this is about.

You could also say they should check the sha1sum, like Clark ended up doing. Or
typing

gpg --fingerprint -k 4F25E3B6

and checking it says

pub   2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
uid   [  full  ] Werner Koch (dist sig)
sub   2048R/AC87C71A 2011-01-12 [expires: 2019-12-31]

with a little caveat that you should actually get the fingerprint from somewhere
trusted, not from a stranger. That would already go a long way. When I include
non-trivial code to be entered on someone's PC, I always include the disclaimer
"Please understand what you are doing here, never enter on your PC what a
stranger on the internet tells you to". At least, I think and hope I do, might
have forgotten in my enthousiasm sometimes.

Or don't check at all and simply see if it crashes during installation. I
wouldn't be surprised if it included a checksum in the .exe as part of the
installer.

But we obviously disagree in an informed way. I know I can be rather principal.
Thanks for appreciating my enthousiasm though :).

HTH,

Peter.

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

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

Re: Defaults

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/17/2015 10:58 PM, Pete Stephenson wrote:
> On 3/17/2015 8:44 PM, Robert J. Hansen wrote:

...

> Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x
> also have that feature?
> 

RFC6979 is used for gnupg 2.0 compiled with libgcrypt >= 1.6.0


- -- 
- 
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
- 
Aurum est Potestas
Gold is power
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVCKnNAAoJEP7VAChXwav6B+AH/jAPCf2xeXW8/PGplQzUVMOT
fsdFjS29lSxGhiRCbUqZyC1nU/7KL2d3R//d05A7tKSvhz01MzG1yLTPjZG7J22U
viMsa2lp8zwWWAqqgefB7qoip389nluzi/3Qcq/WCoRj0T19X5I1iFfV5pYft3zO
IsGOR9qKbOBlF+PRWQOLwyRkJ93qnT3tY6kZG6GbcZWLdHfVw6uRlewJEzPftpkZ
nFwjcy2iVHZF/KHqyQ2CurPu4lqljOxijmae2OKk2EHCUBcCOqLrSq46eOzaLqX6
MLNZfi20ra3YRFMQ3F1Vzw4VAB2pxweNflMSEkdURSFhkwBJNkm5/NqmV0BkhVM=
=s11V
-END PGP SIGNATURE-

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

Re: Defaults

[Robert J. Hansen]

> As long as we're considering "legacy" algorithms like RSA and DSA,
> is there any particular reason for preferring RSA over DSA at such
> key lengths?

I have reasons to prefer RSA, yes, but whether they'll convince you is a
different matter.  :)

Where signature size matters most is in email.  An RSA-3072 signature's
size is significant (says the sophist, surreptitiously suggesting
alliteration on several syllables) on a 512-byte message; there, the
overhead is huge.  On a 5MiB file, the signature's insignificant.

In email, the way of the future is PGP/MIME.  For years I've advocated
inline PGP and said PGP/MIME wasn't ready for prime time, but I'm now at
the point where I believe PGP/MIME is ready to be the default.  And in
PGP/MIME messages, the end-user never sees the signature block, so
there's very little for users to get upset over.  The size difference
between a DSA-3072 signature and an RSA-3072 signature is unlikely to
make a dent in anyone's mobile data plan, either.

So the main advantage DSA has over RSA -- smaller signature size -- is
irrelevant.

And although it genuinely pains me to say this, I can understand why
some OpenPGP users mistrust DSA.  I don't mistrust it and I think people
who do mistrust it are doing so erroneously, but I understand.  NIST's
reputation has taken a pounding in the last few years.

Frankly, people trust RSA more.  I personally think that's foolish:
they're both rock-solid algorithms.  But I understand it, at the same
time, and a decent respect for the concerns of others causes me to
recommend RSA.  I frankly have no preference between RSA and DSA; some
other people in the community trust RSA more; so, okay, let's go for RSA.

> - The Brainpool curves are similar in structure to the NIST curves, 
> though their curve parameters are chosen in a clear, open manner.
> While that leads to increased trust that the parameters aren't chosen
> for nefarious purposes, if one is already making a major change to
> ECC, why not use some other, more modern curve that's designed at a
> high-security level?

Because at present GnuPG supports the following curves:

* NIST
o P-256
o P-384
o P-521
* Brainpool
o P-256
o P-384
o P-512

I cannot in good conscience recommend changing the defaults to an
algorithm not yet supported by GnuPG.  :)

> Do you have a link to this discussion on the IETF list? I suspect
> the community here would be very interested.

https://www.cse-cst.gc.ca/en/node/227/html/15164

Looking over it again, it turns out the Canadians are distrustful of
128-bit crypto *in general*.  None of them are approved for periods
longer than seven days.

> Is there something particular about IDEA that concerns you?

About fifteen years ago I learned about a miss-in-the-middle attack on
IDEA that broke 4.5 of 8.5 rounds (by ... Biham, I think).  That made my
eyebrows go up.  It wasn't a full break, but it sure as hell was
interesting, and attacks only ever get better over time.  That was when
IDEA started giving me the heebie-jeebies.

Khovratovich presented a break against full (8.5-round) IDEA in 2012.
This attack isn't huge -- it reduces 128 shannons of uncertainty to 126,
more or less -- but, at the same time, it's freaking enormous.  From
here on out, every improvement is going to reduce the effective strength
of IDEA.  We're no longer playing games of trying to extend things to
the full cipher: for the last three years we've been watching the full
IDEA be subjected to real attacks.

So far those attacks haven't been successful.  Like I said, a
two-shannon reduction isn't much.

But imagine what it's going to be like in another five years.



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

Re: Defaults

[Daniel Kahn Gillmor]

On Tue 2015-03-17 17:58:47 -0400, Pete Stephenson wrote:
> Alas, a lot of Linux distributions are quite slow-moving: it's unlikely
> that distributions like Debian and Ubuntu will have GnuPG 2.1.x
> available (let alone installed by default) for several years.

For debian stable, this is likely to be the case because of where we
were in the release cycle when 2.1 was finally released.

I hope to have 2.1.x in debian testing and unstable shortly after we
manage to release jessie, and hope to move to it as the default either
for "stretch" (the release after jessie) or (if things turn out to be
much more complicated than i'd like) stretch+1.

> Yes, the changes should be made, but ECC support won't be widely
> available to most users for some time.

I agree that defaulting to brainpool-512 right now would be a mistake.

Defaulting to RSA 3072 seems reasonable to me, though.

--dkg

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

RE: Copy Current GPG Installation to Another Server

[Smith, Cathy]

I would think you can copy your keyring over, though.  I did that when 
converting from an old, unsupported version of PGP to GPG.  But that was 
Solaris to Linux.  You mileage may vary.


Regards,


Cathy

---
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the
U.S. Department of Energy

Phone:  509.375.2687
Fax:    509.375.2330
Email:  cathy.sm...@pnnl.gov


-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Doug 
Barton
Sent: Tuesday, March 17, 2015 11:16 AM
To: Clark Rivard; gnupg-users@gnupg.org
Subject: Re: Copy Current GPG Installation to Another Server

On 3/17/15 7:23 AM, Clark Rivard wrote:
> I currently have GPG 1.4.8 installed on a Windows server.  Can the 
> c:\Programs Files (x86)\GNU\ directory simply be copied to another 
> server and used or do I need to go through the “download and 
> installation” process on the new server? Thanks.

1.4.8 is dangerously old. You should download the new version and install in 
both locations.

ftp://ftp.gnupg.org/gcrypt/binary/

hope this helps,

Doug


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

Re: Defaults

[Robert J. Hansen]

> I have reasons to prefer RSA, yes, but whether they'll convince you 
> is a different matter.  :)

D'oh!  Forgot to mention an important one --

RSA-3072 keys can be moved to smart cards, and/or generated on the same.
Very few smart cards support DSA.  :)




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

Re: Defaults

[Robert J. Hansen]

> I agree that defaulting to brainpool-512 right now would be a
> mistake.
> 
> Defaulting to RSA 3072 seems reasonable to me, though.

I think it's best to minimize the number of times we change the
defaults.  If we change them too often it causes users to wonder if
there's some weakness in OpenPGP -- after all, why else would we need to
constantly play catch-up?  (Note that I don't agree with this; I just
understand it.)

So if we're looking at a situation where we think that within the next
five years we'll want to make ECC the default, I think it would be best
to get that option out in front of users now.  Default to RSA-3072,
sure, but let's get users accustomed to seeing ECC as an option so that
when we migrate fully to ECC-by-default nobody gets surprised.

I freely admit this is a human-factors argument and not a technical
argument, though.  :)




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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 11:25 PM, Robert J. Hansen wrote:
>> As long as we're considering "legacy" algorithms like RSA and DSA,
>> is there any particular reason for preferring RSA over DSA at such
>> key lengths?
> 
> I have reasons to prefer RSA, yes, but whether they'll convince you is a
> different matter.  :)
> 
> Where signature size matters most is in email.

[snip]

Agreed. It's always a bit tedious to see large in-line signatures with
short messages. PGP/MIME, as you say, alleviates this issue somewhat by
hiding the signature, but it also tends to be somewhat fragile when
mailing lists are involved...but that's a different story altogether.

> And although it genuinely pains me to say this, I can understand why
> some OpenPGP users mistrust DSA.  I don't mistrust it and I think people
> who do mistrust it are doing so erroneously, but I understand.  NIST's
> reputation has taken a pounding in the last few years.

Yeah. I'm skeptical of non-RFC6979 DSA simply because it can fail
catastrophically if insufficient entropy is not available when making a
signature. RSA only requires entropy when generating a new key, while
DSA needs it for key and signature generation.

If DSA uses RFC6979 I have no issues with it.

>> - The Brainpool curves are similar in structure to the NIST curves, 
>> though their curve parameters are chosen in a clear, open manner.
>> While that leads to increased trust that the parameters aren't chosen
>> for nefarious purposes, if one is already making a major change to
>> ECC, why not use some other, more modern curve that's designed at a
>> high-security level?
> 
> Because at present GnuPG supports the following curves:
> 
>   * NIST
>   o P-256
>   o P-384
>   o P-521
>   * Brainpool
>   o P-256
>   o P-384
>   o P-512
> 
> I cannot in good conscience recommend changing the defaults to an
> algorithm not yet supported by GnuPG.  :)

*laughs* Indeed!

I hope that everyone understood my point to be "Since GnuPG is already
making a major change by implementing ECC, it'd probably be a good idea
to Do Things Right The First Time(tm), implement strong curves, and make
them the default."

Of course, it'd be a good thing to work with developers of other
OpenPGP-compatible software to ensure that such algorithms would be
widely supported even though the standards don't yet include such
algorithms.

>> Do you have a link to this discussion on the IETF list? I suspect
>> the community here would be very interested.
> 
> https://www.cse-cst.gc.ca/en/node/227/html/15164
> 
> Looking over it again, it turns out the Canadians are distrustful of
> 128-bit crypto *in general*.  None of them are approved for periods
> longer than seven days.

True, but that's not uncommon: OpenVPN in TLS mode renegotiates a new
session key ever hour by default. GnuPG generates new session keys with
each message. Are there any common cryptographic implementations that
would use the same symmetric key for long periods of time?

>> Is there something particular about IDEA that concerns you?
> 
> About fifteen years ago I learned about a miss-in-the-middle attack on
> IDEA that broke 4.5 of 8.5 rounds (by ... Biham, I think).  That made my
> eyebrows go up.  It wasn't a full break, but it sure as hell was
> interesting, and attacks only ever get better over time.  That was when
> IDEA started giving me the heebie-jeebies.
> 
> Khovratovich presented a break against full (8.5-round) IDEA in 2012.
> This attack isn't huge -- it reduces 128 shannons of uncertainty to 126,
> more or less -- but, at the same time, it's freaking enormous.  From
> here on out, every improvement is going to reduce the effective strength
> of IDEA.  We're no longer playing games of trying to extend things to
> the full cipher: for the last three years we've been watching the full
> IDEA be subjected to real attacks.
> 
> So far those attacks haven't been successful.  Like I said, a
> two-shannon reduction isn't much.
> 
> But imagine what it's going to be like in another five years.

Interesting, thanks.

Cheers!
-Pete


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

Re: Defaults

[Daniel Kahn Gillmor]

On Tue 2015-03-17 18:37:40 -0400, Robert J. Hansen wrote:
>> I agree that defaulting to brainpool-512 right now would be a
>> mistake.
>> 
>> Defaulting to RSA 3072 seems reasonable to me, though.
>
> I think it's best to minimize the number of times we change the
> defaults.  If we change them too often it causes users to wonder if
> there's some weakness in OpenPGP -- after all, why else would we need to
> constantly play catch-up?  (Note that I don't agree with this; I just
> understand it.)

by this argument, you should have pushed for RSA 3072 during the last
defaults change, since it would have lasted longer than 2048 ;)

> So if we're looking at a situation where we think that within the next
> five years we'll want to make ECC the default, I think it would be best
> to get that option out in front of users now.  Default to RSA-3072,
> sure, but let's get users accustomed to seeing ECC as an option so that
> when we migrate fully to ECC-by-default nobody gets surprised.

Except that by the time we're ready to adopt ECC by default we may very
well want to use Goldilocks (Hamburg's 448-bit curve), since that seems
to be the high-strength curve that the CFRG is heading toward (yes,
goldilocks is not yet specified for OpenPGP; we'd need to do that
first).

Brainpool-512 is incompatible with some of the other work going on in
the OpenPGP ecosystem (e.g. yahoo and google's work on the e2e webmail
app, which supports P-256 and P-512).

At any rate, changes are afoot, and i don't think we should be afraid to
update the defaults if we think a new set is reasonable.

   --dkg

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

Re: what is the proper way to load gpg-agent with systemd

[Marco Morales]

I recommend starting it from a script in /etc/profile.d/

If you're running >2.1 then you don't need to do the env-file thing. Here's
an example:

https://wiki.archlinux.org/index.php/GnuPG#gpg-agent

On Tue, Mar 17, 2015 at 2:36 PM, Doug Barton  wrote:

> Ok, then you need to start the agent prior to or during the X startup, so
> that the variables are available to your environment (as you were doing
> previously).
>
> So, why are you trying to start the agent with systemd? What method were
> you using previously, and did you try it in the new OS version?
>
> Doug
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Defaults

[Robert J. Hansen]

> by this argument, you should have pushed for RSA 3072 during the
> last defaults change, since it would have lasted longer than 2048 ;)

You're absolutely right, I should have.  :)  I took my eye off the ball
and didn't notice we were changing defaults, otherwise I would've argued
then for RSA-3072.

> At any rate, changes are afoot, and i don't think we should be afraid
> to update the defaults if we think a new set is reasonable.

Point, point.  The ECC ecosystem isn't mature enough to encourage users
to migrate to it.

Okay, so drop the ECC recommendations from my suggestions.
RSA-3072/SHA-256 + one of the modern 128-bit block ciphers, plus strong
recommendations against CAST5, IDEA, or using 64-bit block ciphers to do
bulk encryption.  So far that all seems pretty uncontroversial.  :)





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

Re: Defaults

[Robert J. Hansen]

>> Looking over it again, it turns out the Canadians are distrustful
>> of 128-bit crypto *in general*.  None of them are approved for
>> periods longer than seven days.
> 
> True, but that's not uncommon: OpenVPN in TLS mode renegotiates a
> new session key ever hour by default. GnuPG generates new session
> keys with each message. Are there any common cryptographic
> implementations that would use the same symmetric key for long
> periods of time?

Point: this is probably not indicative of Canadian distrust in AES-128,
CAST5, or 3DES, so much as it is the Canadians codifying an existing
best practice.

However, using the same symmetric key for long periods isn't at all
uncommon.  I last changed the passphrase on my key a little over a year
ago, for instance, so I'm empirical evidence of at least one person
who's been using a symmetric key for over a year.  :)




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

Re: Defaults

[Samir Nassar]

On Tuesday, March 17, 2015 06:53:48 PM Daniel Kahn Gillmor wrote:
> Brainpool-512 is incompatible with some of the other work going on in
> the OpenPGP ecosystem (e.g. yahoo and google's work on the e2e webmail
> app, which supports P-256 and P-512).

Well, the Yahoo! folks are not 100% committed to OpenPGP compatibility, 
according to statements on Twitter. Of course this may or may not change (or 
it could all be a misunderstanding), in case it isn't though, I don't see what 
E2E-compatability adds. If the projects make a solid commitment to OpenPGP 
compatibility and back it up then that changes things.

> At any rate, changes are afoot, and i don't think we should be afraid to
> update the defaults if we think a new set is reasonable.

Hear hear. There are many times where GnuPG setting the pace would have helped 
those of us helping others understand how to use PGP.

Samir

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Copy Current GPG Installation to Another Server

[Peter Lebbing]

On 2015-03-17 23:18, Doug Barton wrote:

I think you are asking way too much, and
giving near-zero value in return.


I'm not asking for anything. I suggested they check the plain SHA1 
checksum or even not check at all! I'm merely opposed to making people 
think the short key ID is any good for verification purposes, or that 
"when it comes to signed packages [it] is not really a necessity" to 
check the validity of the signing key.


Peter.

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




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

Re: Copy Current GPG Installation to Another Server

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/17/2015 11:02 PM, Peter Lebbing wrote:
> On 17/03/15 22:56, Peter Lebbing wrote:
>> and checking it says
>> 
>> pub   2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key
>> fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6 
>> uid   [  full  ] Werner Koch (dist sig) sub   2048R/AC87C71A
>> 2011-01-12 [expires: 2019-12-31]
> 
> Hah! Obviously it wouldn't say "full", firstly because you need
> list-options show-uid-validity in your gpg.conf,

list-options show-uid-validity is the default since GnuPG 2.0.24

- -- 
- 
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
- 
"If you choose to sail upon the seas of banking, build your bank as
you would your boat, with the strength to sail safely through any storm."
(Jacob Safra (1891–1963))
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVCLfhAAoJEP7VAChXwav6g3kIAJB9J93I7Exa+b0GZMzpYEYZ
0i3XcjNS3kkxtbi8SoXLIaKRtzrwHBInHurVXeMNJjPMLuWuaErmeu/CGiObMnXx
nojuzHQ8YEArjz9GU5/rmbTaPU6d3FZ5O4opvNSDIHwKfBgP0EGvOnE/Yh2lbFHu
yfOFb9deUaJv5SvnvAGIPipL8/0msROq7jhfwSMm8m4VHFpFMslnDkiorH6TFd98
E3in8yTeuJYvKMZP1T9h12r800Uax3O0VO7a8Byy4DYRz0Xxotwt2Zmrc7BOpvR4
8PGSdl6cRhyztzgumpoXa2IhFzbcOF0onY1XZjZgjKPzPF4V3hkzhSBlATwr+kg=
=MQYo
-END PGP SIGNATURE-

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

Re: Defaults

[Damien Goutte-Gattat]

On 03/17/2015 08:44 PM, Robert J. Hansen wrote:

Given that 2.1 introduces a lot of new capabilities (mostly with respect
to ECC), I think now, early on in the 2.1 series, would be a good time
to discuss changing the defaults for newly-generated certificates.


Some of the defaults you propose are already there. If I look at a 
freshly generated key pair with GnuPG 2.1, the default preferred 
algorithms are:


Cipher: AES256, AES192, AES, 3DES
Digest: SHA256, SHA384, SHA512, SHA224, SHA1

So, AES256 is already the default symmetric cipher (CAST5 and IDEA are 
not even in the list and must both be explicitly requested by the user), 
and SHA256 is already the default hash algorithm.




* Use SHA256 for RSA-3072/-4096 signatures and SHA512
  for Brainpool-512


Do you mean signatures in general, or key signatures (certifications)? 
For key signatures, SHA-1 is still the default for RSA keys, but 
signatures on (EC)DSA keys will use up to SHA-512 depending on the key 
size (SHA-256 for a Brainpool-256 key, SHA-512 for a BrainpoolP512 key).




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

Re: Defaults

[Pete Stephenson]

On 3/17/2015 11:25 PM, Kristian Fiskerstrand wrote:
> On 03/17/2015 10:58 PM, Pete Stephenson wrote:
>> On 3/17/2015 8:44 PM, Robert J. Hansen wrote:
> 
> ...
> 
>> Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x
>> also have that feature?
> 
> 
> RFC6979 is used for gnupg 2.0 compiled with libgcrypt >= 1.6.0

Excellent. That's exactly what I hoped to hear.

Cheers!
-Pete


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

Re: Defaults

[Daniel Kahn Gillmor]

On Tue 2015-03-17 18:53:42 -0400, Damien Goutte-Gattat wrote:
> Do you mean signatures in general, or key signatures (certifications)? 
> For key signatures, SHA-1 is still the default for RSA keys

Is this correct?  I think we should be defaulting to SHA-256 for RSA
certifications these days.

If we want to cater to users who really want their certifications to
have compatibility with buggy 10-year-old clients that don't have
SHA-256, we should make it easy for them to make a SHA-1 certification
with a 1-second-earlier timestamp.

> but signatures on (EC)DSA keys will use up to SHA-512 depending on the
> key size (SHA-256 for a Brainpool-256 key, SHA-512 for a BrainpoolP512
> key).

I think you mean signatures *by* (EC)DSA keys, not *on* (EC)DSA keys,
right?

  --dkg

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

Re: Copy Current GPG Installation to Another Server

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/17/2015 10:04 PM, Doug Barton wrote:
> On 3/17/15 1:54 PM, Peter Lebbing wrote:
 -Original Message-



> 
> Assuming you get the package, the signature, and the fingerprint
> from the same *.gnupg.org resources, what does that buy you?

Strictly speaking there could be multiple servers hosting the various
resources and only one of which is compromised. It is also quite
common to download the source from mirror rather than *.gnupg.org directly

> 
> More extensive checking would be great, but would require a lot of 
> documentation to teach the users how to do it ... are you
> volunteering to write it? :)
> 

Its included in every announcement[0]. Just a verification by
cross-checking this information in various archives [1] mirroring the
announcement reduce the likelihood of an active compromise, and is a
far better to try to bootstrap a key validity in the absence of a
direct key path.

References:
[0] http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000362.html
[1] http://permalink.gmane.org/gmane.org.fsf.announce/2278

- -- 
- 
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
- 
"If you choose to sail upon the seas of banking, build your bank as
you would your boat, with the strength to sail safely through any storm."
(Jacob Safra (1891–1963))
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJVCLoKAAoJEP7VAChXwav6cpgIALaRMFFd4kLC7edFmkEcYTyl
2GmgxHG7wVYMI/F06DpO4ifMJPQJ/wqadTJPN4o64sjd6PEL5rvWeD+hlA8a+kyj
8PSW3ENzgKCwV72XAzqDzYnvD3i/N0ZV02Wbi0k4gc4SfS98ZPbOroqTqMHcUjVi
OHh+QpnyPGBgWDAq3+MbRxscWSPQFaW9P9HzMKF5Nnu3oWz/dp327YmB1i9176Nw
UoKfhFR6YoPTXBt8WN0QQWAY4ZKRYfRRn63FJYwQSXjhYbz4sn4dPZUjKvej3OH/
ziTFUig62O0owaCK7AaiSbl3qJnL+li1ve0lcnz5bnegck+aYq4ukCp9ZeEvA88=
=MQjq
-END PGP SIGNATURE-

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

Re: Defaults

[Damien Goutte-Gattat]

On 03/18/2015 12:28 AM, Daniel Kahn Gillmor wrote:

On Tue 2015-03-17 18:53:42 -0400, Damien Goutte-Gattat wrote:

Do you mean signatures in general, or key signatures (certifications)?
For key signatures, SHA-1 is still the default for RSA keys


Is this correct?  I think we should be defaulting to SHA-256 for RSA
certifications these days.


Actually no, it is not. My mistake.

SHA-256 is the default cert-digest-algo since GnuPG 2.1.0.



but signatures on (EC)DSA keys will use up to SHA-512 depending on the
key size (SHA-256 for a Brainpool-256 key, SHA-512 for a BrainpoolP512
key).


I meant *on*, but now I realize I was only thinking about *self* 
signatures, where the signing key and the signed key happen to be the same.


In the more general case you are right of course: the default hash 
algorithm is determined by the type and size of the *signing* key, not 
of the key that is about to be signed.




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

Re: Defaults

[Robert J. Hansen]

> Some of the defaults you propose are already there.

Yes.  My list was comprehensive ("what the new set should be"), not
differential ("what needs changing").  :)

> So, AES256 is already the default symmetric cipher (CAST5 and IDEA
> are not even in the list and must both be explicitly requested by the
> user), and SHA256 is already the default hash algorithm.

Your key pref isn't what matters: it's your default-cipher-prefs.  :)

CAST5 may not be the default choice anymore, but it can still be
selected (I believe) if the recipient's key prefs list it.  I think this
shouldn't be supported; CAST5 should only be used if (a) it's in the
recipient's key prefs and (b) it's explicitly listed in
default-cipher-prefs.

> Do you mean signatures in general, or key signatures
> (certifications)?

The former, although I think setting cert-digest-algo SHA256 by default
may be worth discussing.



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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 4:17 PM, Peter Lebbing wrote:

On 2015-03-17 23:18, Doug Barton wrote:

I think you are asking way too much, and
giving near-zero value in return.


I'm not asking for anything.


Originally you suggested that they verify the fingerprint, and use that 
to retrieve the key. Glad to see now that you realize that was not the 
right course of action. :)



I suggested they check the plain SHA1
checksum or even not check at all!


I would argue that verifying the signature when available is slightly 
better, but I won't quibble on this point. For most users it is true 
that the checksum is likely to be "just as good" as a signature 
verification.



I'm merely opposed to making people
think the short key ID is any good for verification purposes, or that
"when it comes to signed packages [it] is not really a necessity" to
check the validity of the signing key.


We will have to agree to disagree on this point.

Doug


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

Re: Copy Current GPG Installation to Another Server

[Doug Barton]

On 3/17/15 4:34 PM, Kristian Fiskerstrand wrote:

On 03/17/2015 10:04 PM, Doug Barton wrote:

On 3/17/15 1:54 PM, Peter Lebbing wrote:

-Original Message-






Assuming you get the package, the signature, and the fingerprint
from the same *.gnupg.org resources, what does that buy you?


Strictly speaking there could be multiple servers hosting the various
resources and only one of which is compromised.


I conceded from the start that there are scenarios where Peter's threat 
model is valid. However they are overwhelmingly unlikely.


You also seem to be ignoring the bootstrapping problem of educating the 
new users on doing proper validity checking for fingerprints, keys, etc.



It is also quite
common to download the source from mirror rather than *.gnupg.org directly


Yes, and mirrors, by definition, are copies of the original. So either 
they are all compromised (because the master is), or the subset of 
systems that get compromised will auto-correct at whatever interval they 
are set up to mirror the master.


So the scenario where "download the package and signature from one site 
and verify the fingerprint from another site provided by the same 
operator" is useful still falls into the "incredibly unlikely" category.



More extensive checking would be great, but would require a lot of
documentation to teach the users how to do it ... are you
volunteering to write it? :)



Its included in every announcement[0]. Just a verification by
cross-checking this information in various archives [1] mirroring the
announcement reduce the likelihood of an active compromise, and is a
far better to try to bootstrap a key validity in the absence of a
direct key path.

References:
[0] http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000362.html
[1] http://permalink.gmane.org/gmane.org.fsf.announce/2278


The announcements are of no use to the user going to the FTP site to 
download a new package unless they happen to be on the mailing list. And 
in any case, the archives and gmane.org mirror fall into the "same 
operator" trap described above.


The thing I'm trying to avoid here is adding complexity that does 
nothing but satisfy the OCD of experienced users who know the 
good/right/best way of doing things and add no real value to new users 
who are just trying to get started with the software.


If there were a comprehensive new-user guide that could explain all of 
this stuff that would be a valuable addition. But there isn't, and I'm 
not going to write one. So personally I'll settle for offering practical 
advice to folks at the level I think they're ready to deal with it. If 
you want to do more, then $DEITY bless you, I look forward to seeing 
your efforts.


Doug

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

Re: what is the proper way to load gpg-agent with systemd

[Daniel Kahn Gillmor]

On Tue 2015-03-17 14:43:02 -0400, Paulo Lopes wrote:
> So what I did was to create a user unit file like this on ~/.local/:
>
> [Unit]
> Description=gpg-agent
> ConditionFileIsExecutable=/usr/bin/gpg-agent
>
> [Service]
> ExecStart=/usr/bin/gpg-agent --daemon --enable-ssh-support
> --scdaemon-program /usr/libexec/scdaemon --use-standard-socket --log-file
> ~/.gnupg/gpg-agent.log --write-env-file %h/$
> ExecStop=/usr/bin/pkill gpg-agent
> Type=forking
> Restart=always
>
> [Install]
> WantedBy=default.target
>
>
> Now what happens is that i start a java application "IntelliJ" and when i
> try to get git to fetch some code it complains that the it cannot sign the
> key. However if i use "pass" then the pinentry popup shows i enter my pin
> and from there the git stuff works from intellij.

I don't know what "pass" is, but i guess it's how you trigger pinentry
to talk to your agent?

it sounds to me like you're saying that the agent started by systemd
doesn't know how to find your X11 session properly, so it doesn't know
how to launch pinentry on its own.

Does that sounds like an accurate characterization?

have you tried adding the following line to the [Service] stanza in your
.service file?

Environment=DISPLAY=:0

Try that, and then a full machine shutdown, restart, and login.  It's a
workaround at best (your $DISPLAY won't always be :0) but if it works
for you, you'll know that this is at least the right diagnosis.

hth,

--dkg

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

Re: Making the case for smart cards for the average user

[Brian Minton]

I thought keyservers strip all punctuation. So  becomes
foo example com.

On Tue, Mar 17, 2015, 3:33 PM MFPA <2014-667rhzu3dc-lists-gro...@riseup.net>
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On Tuesday 17 March 2015 at 5:38:03 PM, in
> , Daniel Kahn Gillmor
> wrote:
>
>
>
>
> > This might be a bug (or at least a well-warranted
> > feature enhancement) in GnuPG.
>
> > I've just opened
> > https://bugs.g10code.com/gnupg/issue1927 to track it.
>
> Thanks.
>
> - --
> Best regards
>
> MFPA  
>
> Take my advice - I don't use it anyway.
> -BEGIN PGP SIGNATURE-
>
> iQF8BAEBCgBmBQJVCIEoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
> QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwAVYIAKYbEhLI9Iuiy87J7iuyPXWz
> 67f+oq8iiBq2V6/CcuS+5u5LJKhKhdeBbnSZLwXrEv6C7uRNAbvS3uLa0um2kQ3s
> 6L9rTmmsbuVURYcAsYsRdYSnPjB2G2t6ocCc9FwZMnsv6H5TCskrnsO82PcvjWjo
> wlTzU/ESlujVirFYZKe0Cx+bhSb1FVG4kRcc657RoV6/HE6+kKEudIXn4JExyHmJ
> 8uNbsY6b2HEj8wxjEoTa54b0lSpb1XWQawolyxk7fVwqgKcpxBizvgqHEVWzuhH+
> 7skCdSZpX+bjBSb5ZyFA3dWanjc184zh+SH/oEWOsJ7VmcGuwPg3hJy8Kg5hhguI
> vgQBFgoAZgUCVQiBRV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
> cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
> MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45AG5AQBAJJysXSkrs+kxTsXOf5dFzG7y
> +Tvzagn5cESWj7KSggEAs+rcnGKH9b6AY3eduOVKJ4vwUGgmn6vujD6yOUZs7Qw=
> =b48P
> -END PGP SIGNATURE-
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Making the case for smart cards for the average user

[Daniel Kahn Gillmor]

On Tue 2015-03-17 21:35:46 -0400, Brian Minton wrote:
> I thought keyservers strip all punctuation. So  becomes
> foo example com.

This discussion has been about gnupg and its own keyring, not
necessarily about keyservers.  The bug report i filed referred to local
gpg activity, not keyserver activity.

--dkg

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