Re: How to prevent passphrase caching in 2.1

On Thu, 29 Dec 2016 12:37:03 +, MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote: >On Sunday 27 November 2016 at 5:15:55 PM, in >, Carola >Grunwald wrote:- > > >> But no, unfortunately it's a Windows server >> application with GnuPG, Tor, >> Mix

Re: Implications of a common private keys directory in 2.1

Stephan Beck wrote: >Carola Grunwald: >> Stephan Beck wrote: >>> Carola Grunwald: >>>> Peter Lebbing wrote: >> >> >> Removing all cached passphrases sounds great. But does that mean I have >> to invoke the agent directly using the Assuan proto

Re: Implications of a common private keys directory in 2.1

Stephan Beck wrote: >Carola Grunwald: >> Peter Lebbing wrote: >>>> You mean --try-secret-key doesn't overrule the key parameter that comes >>>> along with the encoded material? >>> >>> No, it specifies which keys to try for a hidden recipi

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 11/12/16 20:58, Carola Grunwald wrote: >> With 'problems' i referred to the GenKey bug/feature I reported a few >> hours ago and the IPC instabilities I experienced. Sure, the >> single-sec-keys-depository : multiple-pub-keyrings config

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >> But what do you mean by 'deprecated for server use'? > >I meant that GnuPG 1.4 is not deprecated for server use. By which I mean >it is pretty much advised against for desktop use. > >I didn't mean that GnuPG 2.x was deprecated for anything at all :-). I see. Thanks for t

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 04/12/16 21:59, Carola Grunwald wrote: >> Three months ago I thought it was time to adapt it to GnuPG 2.1, and >> the problems began. > >I would seriously consider the option of just sticking to 1.4. It's not >deprecated for server use. It sh

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 25/11/16 00:03, Carola Grunwald wrote: >I think it would be better to implement the proxy on the client machine, >instead of on a server machine. That way, all secrets stay on the client >machine, and you could still use regular e-mail clients, just with an

Re: Implications of a common private keys directory in 2.1

Andrew Gallagher wrote: >On 26/11/16 01:17, Carola Grunwald wrote: >> >> WME encoding, remailing and nym handling are done completely at the >> proxy. You can use any, even the most primitive PGP-unaware MUA to send >> and receive standard mail and Usenet message

Re: How to prevent passphrase caching in 2.1

Werner Koch wrote: >On Wed, 23 Nov 2016 03:28, c...@nymph.paranoici.org said: > >> Sure, I like v1.4's small footprint and its reliability. But as the >> --faked-system-time option, important in my application for privacy >> reasons, wasn't backported to v1.4, I had to migrate to v2.1. I'm still

Re: Implications of a common private keys directory in 2.1

Andrew Gallagher wrote: >On 24/11/16 23:03, Carola Grunwald wrote: >> >> Let's just say I hold two nym accounts at different nym servers >> >> https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers >> >> and send WME encaps

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 24/11/16 14:16, Carola Grunwald wrote: >> WME combined with nym server usage for example requires an individual >> WME key for each account, as otherwise at least the recipient, who may >> communicate with different aliases is able to link them bas

Re: Implications of a common private keys directory in 2.1

MFPA <2014-667rhzu3dc-lists-gro...@riseup.net> wrote: >Have you looked at all at Mike Ingle's "Confidant Mail" (CM) >? Maybe your signing/encryption servers >at each end could incorporate a CM-to-SMTP gateway; CM could be >awesome it were possible to compose and read

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 24/11/16 00:09, Carola Grunwald wrote: >> When you deal with pseudonymity you have to avoid similarities of >> your aliases. So the WME keys they use to secure their messages have >> to be different. > >I still don't see why you need

Re: How to prevent passphrase caching in 2.1

Daniel Kahn Gillmor wrote: >On Wed 2016-11-23 03:46:57 -0500, Carola Grunwald wrote: >> With GnuPG 1.4 I had no agent. And, in case it is, I've no idea why with >> 2.x such a passphrase cache with all its risks has to be mandatory. > >in 2.0, the agent is a passphrase

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 23/11/16 18:54, Carola Grunwald wrote: >> Which relevant information does the single Received: header, describing >> the recipient MTA's interaction with the exit remailer, leak? > >If you sign the data just before the interaction, the signatur

Re: Implications of a common private keys directory in 2.1

Andrew Gallagher wrote: >On 23/11/16 17:54, Carola Grunwald wrote: >> Andrew Gallagher wrote: >> >>> If you are worried about an attacker on the wire doing statistical >>> analysis of your message sizes and patterns of use, you will >>> probably have

Re: Implications of a common private keys directory in 2.1

Andrew Gallagher wrote: > >> On 23 Nov 2016, at 03:48, Carola Grunwald wrote: >> >> But why does a person have to be in control of a signature key? Why not >> a server in the name of a company resp. its employees. > >There is no problem having a server in con

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 23/11/16 10:53, Andrew Gallagher wrote: >> If the message is being automatically decrypted at the MTA then it >> provides no more security than TLS. > >I could concur with this statement if we amend it a little: when two >MTA's are explicitly configured as TLS peers. They

Re: How to prevent passphrase caching in 2.1

Daniel Kahn Gillmor wrote: >On Tue 2016-11-22 11:20:26 -0500, Carola Grunwald wrote: >> They don't have direct access to any key. Nevertheless by using someone >> else's cached passphrase with 2.1 and its all-embracing keyring they may >> succeed in decoding data n

Re: Implications of a common private keys directory in 2.1

"Robert J. Hansen" wrote: >> gpg is intended to run on the client, not the server. A mail service >operator >> should not hold the private keys of its users, never mind perform >encryption >> operations on their behalf. I would question the design of your >architecture if >> you feel this is nece

Re: How to prevent passphrase caching in 2.1

Peter Lebbing wrote: >On 22/11/16 17:20, Carola Grunwald wrote: >> They don't have any system account at all. These are users of a >> messaging system, only allowed to access its POP3, SMTP and NNTP >> service. > >Perhaps 1.4 is the best release for you... you

Re: Implications of a common private keys directory in 2.1

Peter Lebbing wrote: >On 22/11/16 02:54, Carola Grunwald wrote: >> - In a multi-user environment the key owning recipient has to be granted >> access to the private key with some sender being restricted to only use >> the public key no matter whether there's a

Re: How to prevent passphrase caching in 2.1

Peter Lebbing wrote: >On 21/11/16 15:20, Carola Grunwald wrote: >> As for each single decryption task only a defined passphrase is >> allowed to be used it's essential to have caching, which implicates >> the risk of unauthorized passphrase usage, strictly deactivated

Re: Implications of a common private keys directory in 2.1

Hello Werner! On Mon, 21 Nov 2016 10:28:47 +0100, you wrote: >On Sun, 20 Nov 2016 21:37, c...@nymph.paranoici.org said: > >>>Is there any chance to get that disentangled, maybe by defining a >>>separate secret key directory for each public .kbx keyring in use? > >No. > >> The silence makes me bel

Re: How to prevent passphrase caching in 2.1

Hello Werner, thanks for your fast reply. On Mon, 21 Nov 2016 10:30:51 +0100, you wrote: >On Sun, 20 Nov 2016 22:18, c...@nymph.paranoici.org said: > >> to gpg-agent.conf the official way to deactivate passphrase caching >> completely and make GnuPG only use the term transferred with the > >Plea

How to prevent passphrase caching in 2.1

Hi, is adding | default-cache-ttl 0 and/or | max-cache-ttl 0 to gpg-agent.conf the official way to deactivate passphrase caching completely and make GnuPG only use the term transferred with the --passphrase option? Thanks Caro ___ Gnupg-users mail

How to prevent passphrase caching in 2.1

Hi, is adding | default-cache-ttl 0 and/or | max-cache-ttl 0 to gpg-agent.conf the official way to deactivate passphrase caching completely and make GnuPG only use the term transferred with the --passphrase option? Thanks Caro ___ Gnupg-users mail

Re: Implications of a common private keys directory in 2.1

On Sun, 16 Oct 2016 01:22:50 + (UTC), I wrote: >Hi, > >my next problem with 2.1.15 on Windows 7. > >I add a pub/sec keypair to two different keyrings > '--import ... --keyring a.kbx', then '--import ... --keyring b.kbx'. >Following this I delete that key from one of the keyrings > '--delete-

Implications of a common private keys directory in 2.1

Hi, my next problem with 2.1.15 on Windows 7. I add a pub/sec keypair to two different keyrings '--import ... --keyring a.kbx', then '--import ... --keyring b.kbx'. Following this I delete that key from one of the keyrings '--delete-secret-and-public-key ... --keyring a.kbx', which unfortunat

Re: Decryption with suppressed key ID (--throw-keyids) different in 2.1

Hi Werner! On Sun, 28 Aug 2016 17:26:22 +0200, Werner Koch wrote: >On Sun, 28 Aug 2016 00:07, c...@nymph.paranoici.org said: > >> Is there a reason why decryption of data with the recipient's key ID >> suppressed now requires the --try-all-secrets option? It took me some > >No, this would be a

Decryption with suppressed key ID (--throw-keyids) different in 2.1

Hi, the next problem with my 1.4 -> 2.1 (2.1.15) migration (Windows 7). Is there a reason why decryption of data with the recipient's key ID suppressed now requires the --try-all-secrets option? It took me some time to realize that difference. Kind regards, Caro __

Decryption with suppressed key ID (--throw-keyids) different in 2.1

Hi, the next problem with my 1.4 -> 2.1 (2.1.15) migration (Windows 7). Is there a reason why decryption of data with the recipient's key ID suppressed now requires the --try-all-secrets option? It took me some time to realize that difference. Kind regards, Caro __

Re: Standard gnupg folder created despite --homedir parameter

On Wed, 10 Aug 2016 10:40:29 +0200, Peter Lebbing wrote: >On 10/08/16 01:23, Carola Grunwald wrote: >> May I ask how that translates into the Windows world? Is it a way to >> get rid of the ...\AppData\Roaming\gnupg folder? > >While the directory names give off a strong Un

Re: Standard gnupg folder created despite --homedir parameter

Hello Werner, many thanks for your involvement in this discussion. GPG 2.1 took big steps towards becoming a truly portable application. On Tue, 09 Aug 2016 12:10:21 +0200, Werner Koch wrote: >On Mon, 8 Aug 2016 18:20, sinclair.ander...@usabilitypartners.se said: > >> set GNUPGHOME=. > >Don'

Re: Standard gnupg folder created despite --homedir parameter

Sinclair Andersen wrote: >> From: Carola Grunwald >> Subject: Standard gnupg folder created despite --homedir parameter >> Migrating a Windows encryption tool from 1.4.20 I need help with GnuPG >> 2.1.14. >> >> Though using the --homedir parameter, with ce

Standard gnupg folder created despite --homedir parameter

Hello! Migrating a Windows encryption tool from 1.4.20 I need help with GnuPG 2.1.14. Though using the --homedir parameter, with certain gpg commands a gnupg folder is created in %APPDATA% (C:\Users\%USERNAME%\AppData\Roaming). Is there a reason for having that folder or is it just a bug? Any ch

Re: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)

On Tue, 10 May 2016 11:35:33 +0200, Werner Koch wrote: >On Tue, 10 May 2016 09:47, c...@nymph.paranoici.org said: > >> Meanwhile I'm sure it's a bug similar to >> https://bugs.gnupg.org/gnupg/issue2324. > >Not really. > >> GnuPG 2.1 isn't ready for embedded usage yet. >> It's still experimental,

Re: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)

Hello Dashamir, on Tue, 10 May 2016 04:17:07 +0200, you wrote: >On Sat, May 7, 2016 at 5:32 PM, Carola Grunwald >wrote: > >> >> You're right, there's no passphrase request with >> >> | d:\gpg>gpg.exe --batch --homedir "d:\gpgdat" --no-auto

Re: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)

Hello Dashamir, on Sat, 7 May 2016 14:18:39 +0200, you wrote: >On Sat, May 7, 2016 at 12:59 PM, Carola Grunwald >wrote: > >> Hello, >> >> on Wed, 4 May 2016 22:55:34 + (UTC), I wrote: >> >> >I need help with GnuPG 2.1.12 migrating an encryption to

Re: 'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)

Hello, on Wed, 4 May 2016 22:55:34 + (UTC), I wrote: >I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. > >I'm trying to run the --delete-secret-and-public-key command with the >passphrase entered through stdin, which doesn't get activated ('delete >key failed: No pinen

'No pinentry' error (--pinentry-mode loopback with --delete-secret-and-public-key)

Hello! I need help with GnuPG 2.1.12 migrating an encryption tool from 1.4.20. I'm trying to run the --delete-secret-and-public-key command with the passphrase entered through stdin, which doesn't get activated ('delete key failed: No pinentry'). With --export-secret-keys I was successful this w