Re: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists

On 08/17/2016 11:00 PM, Spoofy32 . wrote: > --status-file outputs: > > [GNUPG:] ENC_TO 1 0 > [GNUPG:] GOOD_PASSPHRASE > [GNUPG:] ERROR pkdecrypt_failed 18 > [GNUPG:] BEGIN_DECRYPTION > [GNUPG:] DECRYPTION_FAILED > [GNUPG:] END_DECRYPTION > > Is there a place where error code 18

Re: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists

--status-file outputs: [GNUPG:] ENC_TO 1 0 [GNUPG:] GOOD_PASSPHRASE [GNUPG:] ERROR pkdecrypt_failed 18 [GNUPG:] BEGIN_DECRYPTION [GNUPG:] DECRYPTION_FAILED [GNUPG:] END_DECRYPTION Is there a place where error code 18 is defined? On Wed, Aug 17, 2016 at 8:33 AM, Daniel Ranft

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

On Wed, Aug 17, 2016 at 05:32:03PM +0200, Kristian Fiskerstrand wrote: > On 08/17/2016 05:04 PM, Bernhard Reiter wrote: > > Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: > >> FWIW, I really wonder why people seem to use the keyid to check keys. > > > > It is not done to check keys,

Re: 2 Q's

On 17/08/16 19:35, Andrew Gallagher wrote: > > Public keys are low-latency things D'oh. s/low/high/ A signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org

Re: 2 Q's

On 17/08/16 19:15, Robert J. Hansen wrote: > > Parcimonie is a key refreshing daemon. (So far, cool! It's a real > problem. Solving this problem is cool.) In order to defend against > completely hypothetical movie plot attacks, it insists on refreshing the > keys spread out over a long period

Re: 2 Q's

> Okay, I give up. What is "Parcimonie"? A poorly-thought-out answer to a problem that doesn't exist. Parcimonie is a key refreshing daemon. (So far, cool! It's a real problem. Solving this problem is cool.) In order to defend against completely hypothetical movie plot attacks, it insists

Re: 2 Q's

On Wed, Aug 17, 2016 at 04:07:34PM +0100, Andrew Gallagher wrote: On 17/08/16 15:54, Jerry wrote: On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: Parcimonie already exists. But it's an optional extra that most people don't install (or even know of). People shouldn't be expected

Re: 2 Q's

On 17/08/16 17:03, Gabriel Philippe wrote: > On Wed, Aug 17, 2016 at 5:43 PM, Andrew Gallagher wrote: >> On 17/08/16 16:36, Gabriel Philippe wrote: >>> >>> Set an expiration date to your key one year from now. Every 6 months, >>> postpone this expiration date to 6 more

[Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]

Hello! The GnuPG Project is pleased to announce the availability of new Libgcrypt and GnuPG versions to *fix a critical security problem*. Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An

Re: 2 Q's

On 2016-08-17 at 16:36, Andrew Gallagher wrote: > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. > Last time I checked, Parcimonie

Re: 2 Q's

On 16-08-17 10:54, Jerry wrote: > On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: > > >Parcimonie already exists. But it's an optional extra that most people > >don't install (or even know of). People shouldn't be expected to > >install or configure extras before they have a (safely)

Re: 2 Q's

On Wed, Aug 17, 2016 at 5:43 PM, Andrew Gallagher wrote: > On 17/08/16 16:36, Gabriel Philippe wrote: >> >> Set an expiration date to your key one year from now. Every 6 months, >> postpone this expiration date to 6 more months. It's too late for >> these people, but in the

Re: 2 Q's

On 17/08/16 16:43, Gabriel Philippe wrote: > On Wed, Aug 17, 2016 at 4:36 PM, Andrew Gallagher wrote: >> Parcimonie already exists. But it's an optional extra that most people >> don't install (or even know of). People shouldn't be expected to >> install or configure extras

Re: 2 Q's

Le 18 août 2016 00:09, "Andrew Gallagher" a écrit : > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. I

Re: 2 Q's

On Wed, Aug 17, 2016 at 4:36 PM, Andrew Gallagher wrote: > Parcimonie already exists. But it's an optional extra that most people > don't install (or even know of). People shouldn't be expected to > install or configure extras before they have a (safely) usable system. I

Re: 2 Q's

On Wed, Aug 17, 2016 at 3:21 PM, Robert J. Hansen wrote: > You're assuming people refresh their keyrings. Although that's a > recommended practice, it appears to be the opinion of the minority. I am used to being a minority. :) > My > certificate 0x23806BE5D6B98E10 has

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

On 08/17/2016 05:04 PM, Bernhard Reiter wrote: > Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: >> FWIW, I really wonder why people seem to use the keyid to check keys. > > It is not done to check keys, it done to distinquish keys to select > in user interfaces. At which point even

Re: 2 Q's

On 17/08/16 15:54, Jerry wrote: > On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: > >> Parcimonie already exists. But it's an optional extra that most people >> don't install (or even know of). People shouldn't be expected to >> install or configure extras before they have a (safely)

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

Am Mittwoch, 17. August 2016 16:53:57 schrieb Werner Koch: > FWIW, I really wonder why people seem to use the keyid to check keys. It is not done to check keys, it done to distinquish keys to select in user interfaces. You could call this some sort of "checking" of course, but it is a usability

Re: 2 Q's

On Wed, 17 Aug 2016 15:36:05 +0100, Andrew Gallagher stated: >Parcimonie already exists. But it's an optional extra that most people >don't install (or even know of). People shouldn't be expected to >install or configure extras before they have a (safely) usable system. Okay, I give up. What is

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

On Wed, 17 Aug 2016 16:29, kristian.fiskerstr...@sumptuouscapital.com said: > I'm not sure I like this, it avoids the actual issue of people using > non-verified keys (and verification would be using fingerprint to begin > with, although I might read it without the proper context in this email)

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

Am Dienstag, 16. August 2016 16:57:07 schrieb Robert J. Hansen: > > Ah thanks, this was introduced with 2.1.13 and I tested the > > behaviour on an earlier 2.1 version where it make a difference. > > So it is a recommendation for GnuPG v <=2.0. > > Concur. I'll make the change shortly. Thanks.

Re: 2 Q's

On 17/08/16 14:52, Robert J. Hansen wrote: >> That sounds like an argument for marking downloaded local copies of >> public keys stale after a certain period, similarly to DNS TTL... > > That suggestion fills me with horror. Key management is *already* a > nightmare without adding this to it.

Re: gpg.conf recommendations (FAQ improvement) was: GnuPG 1.4.19 - Encryption Questions

On 08/17/2016 04:24 PM, Bernhard Reiter wrote: > Am Dienstag, 16. August 2016 16:57:07 schrieb Robert J. Hansen: >>> Ah thanks, this was introduced with 2.1.13 and I tested the >>> behaviour on an earlier 2.1 version where it make a difference. >>> So it is a recommendation for GnuPG v <=2.0. >>

Re: [Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists

Am Dienstag, 16. August 2016 22:39:11 schrieb Spoofy32 .: > The key IDs in the --list-keys outputs match between the private and public > keys. Given the round of fake keys that were available yesterday from a number of keyservers, I additionally recommend checking and comparing the long keyid.

Re: 2 Q's

On 2016-08-17 at 15:52, Robert J. Hansen wrote: > Better by far to provide a cronjob that can do the refreshing > automatically -- or, on Windows, to write a service to do it. > Or an scheduled task. -- Juan Miguel Navarro Martínez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F

Re: 2 Q's

> That sounds like an argument for marking downloaded local copies of > public keys stale after a certain period, similarly to DNS TTL... That suggestion fills me with horror. Key management is *already* a nightmare without adding this to it. Better by far to provide a cronjob that can do the

Re: 2 Q's

On 17/08/16 14:21, Robert J. Hansen wrote: >> Concerning key servers, unless in very specific cases, I think keys >> should be on big and commonly used keyservers which synchronize among >> themselves. Otherwise new signatures, IDs, and revocations will not >> get propagated when people refresh

Re: 2 Q's

> Concerning key servers, unless in very specific cases, I think keys > should be on big and commonly used keyservers which synchronize among > themselves. Otherwise new signatures, IDs, and revocations will not > get propagated when people refresh their keyring. You're assuming people refresh

Re: 2 Q's

On Tue, Aug 16, 2016 at 3:00 PM, Robert J. Hansen wrote: >> 2) What is the best way to automatically send my Public Key to message >> recipients? > > Don't. Public keys are big and a little obnoxious. Send your public > certificate to a keyserver. In your email signature,

[Resend] Assistance with decryption failure, gpg unable to find secret key that actually exists

Apologies, I sent the previous email to the list before I finished typing it (and I didn't have the undo send option enabled)! Please disregard that email and my apologies for any inconvenience. Actually intended text: Greetings! I am currently having an issue with decrypting a simple text file