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? 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
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.
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
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 http://digitalbrains.com/2012/openpgp-key-peter ___ 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
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
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
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
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: Making the case for smart cards for the average user
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
RE: Defaults
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
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
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 http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Copy Current GPG Installation to Another Server
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: Defaults
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
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 http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Copy Current GPG Installation to Another Server
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
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
Copy Current GPG Installation to Another Server
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?
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 http://digitalbrains.com/2012/openpgp-key-peter ___ 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
On Tue 2015-03-17 21:35:46 -0400, Brian Minton wrote: I thought keyservers strip all punctuation. So f...@example.com 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
Re: what is the proper way to load gpg-agent with systemd
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
I thought keyservers strip all punctuation. So f...@example.com 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 mid:87lhivpls4@alice.fifthhorseman.net, 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 mailto:2014-667rhzu3dc-lists-gro...@riseup.net 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: Copy Current GPG Installation to Another Server
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: Defaults
-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
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
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
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 dougb@dougbarton.email 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
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
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: Defaults
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
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: Defaults
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
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
-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
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: Copy Current GPG Installation to Another Server
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 http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Copy Current GPG Installation to Another Server
-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: Copy Current GPG Installation to Another Server
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
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: Defaults
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
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
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: 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: Making the case for smart cards for the average user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tuesday 17 March 2015 at 5:38:03 PM, in mid:87lhivpls4@alice.fifthhorseman.net, 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 mailto:2014-667rhzu3dc-lists-gro...@riseup.net 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: Copy Current GPG Installation to Another Server
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 use option --keyserver 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
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: what is the proper way to load gpg-agent with systemd
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
On Tue, Mar 17, 2015 at 7:19 PM, Doug Barton dougb@dougbarton.email 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
RE: what is the proper way to load gpg-agent with systemd
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
RE: what is the proper way to load gpg-agent with systemd
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
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: 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 use option --keyserver 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
what is the proper way to load gpg-agent with systemd
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
