Re: Implications of a common private keys directory in 2.1

On 19/12/16 20:05, Stephan Beck wrote: > So, yes, and sorry for my hesitation, the only way (I see) is to > invalidate the passphrase cache removing all its entries and manually > presetting the one keygrip/key to use on the command line. Why don't you just disable passphrase caching if that is th

Re: Implications of a common private keys directory in 2.1

Hi, Carola Grunwald: > 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 protocol? And what would >

Re: Implications of a common private keys directory in 2.1

On 11/12/16 02:48, Carola Grunwald wrote: > Nevertheless the user has to get knowledge of such an attack, which is > why a header entry reporting the decoding status is added to the message > forwarded to the client: > > | O-Nym-Crypto: slot=19; sym=3; asym=1; esub=i; > account=myacco...@nym.mixm

Re: Implications of a common private keys directory in 2.1

I think I've made my point, but more importantly, I feel that you understood what I tried to get across. You reach a different conclusion than I, but I think any further discussion on these points would lead to rehashing of previously made arguments. On 12/12/16 04:06, Carola Grunwald wrote: > You

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 protocol? And what would >> be the way to get a list of all

Re: Implications of a common private keys directory in 2.1

Hi Caro, 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 protocol? And what would > be the way to get a list of all valid cache_ids?

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 recipient. This is easy >>> to investigate if you create a few te

Re: Implications of a common private keys directory in 2.1

Carola Grunwald: > 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 configuration i

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 configuration is a >> design decision, thou

Re: Implications of a common private keys directory in 2.1

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 configuration is a > design decision, though one I don't quite unders

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

I'm going to respond to a few points that I already know my answer to. I might not actually have all that much interesting to say about the more complicated points, though... > 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

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 should still have a lot of life

Re: Implications of a common private keys directory in 2.1

Peter Lebbing: > On 06/12/16 15:53, Stephan Beck wrote: >> [...], and use it as in >> gpg2 --no-default-keyring --secret-keyring file --try-secret-key >> [NAME=aspecificlongKeyID | fingerprint] --decrypt >> any_signedANDencrypted_message.txt.gpg ? >> Would that work? > >>From the GnuPG 2.1 man p

Re: Implications of a common private keys directory in 2.1

On 06/12/16 15:53, Stephan Beck wrote: > [...], and use it as in > gpg2 --no-default-keyring --secret-keyring file --try-secret-key > [NAME=aspecificlongKeyID | fingerprint] --decrypt > any_signedANDencrypted_message.txt.gpg ? > Would that work? From the GnuPG 2.1 man page: --secret-keyrin

Re: Implications of a common private keys directory in 2.1

Carola Grunwald: > Peter Lebbing wrote: >> On 25/11/16 00:03, Carola Grunwald wrote: [...] >> An option --only-try-secret would solve both (your software >> would know which to try for a given nym account), but such an option is >> not available. You could try to make the case that such an opti

Re: Implications of a common private keys directory in 2.1

On 04/12/16 20:59, Carola Grunwald wrote: > It's a small > tool running as a background task residing in the system tray. Hold on a sec. Are you running a pseudonymity service on your personal desktop? Andrew. signature.asc Description: OpenPGP digital signature

Re: Implications of a common private keys directory in 2.1

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 should still have a lot of life left in it. > Just at the mo

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 >IMAP server at

Re: Implications of a common private keys directory in 2.1

On 03/12/16 18:21, MFPA wrote: > If the recipients are hidden, doesn't GnuPG first try the key set > with --default-key, followed by any keys set with --try-secret-key? Hey, I didn't know that! Thanks! > That is sufficient for your smartcard and known-hidden-key examples, > but not for Caro's sit

Re: Implications of a common private keys directory in 2.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Saturday 3 December 2016 at 2:35:09 PM, in , Peter Lebbing wrote:- > An option --only-try-secret would solve both > (your software > would know which to try for a given nym account), but > such an option is > not available. You could try to m

Re: Implications of a common private keys directory in 2.1

On 25/11/16 00: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 Right, you're also hiding the proxy server. So if the proxy used the same public key for multiple nym acco

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 messages, crypto and anonymization >> ca

Re: Implications of a common private keys directory in 2.1

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 messages, crypto and anonymization > capabilities are provided by the p

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 encapsulated mail through both of them to a single >>

Re: Implications of a common private keys directory in 2.1

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 encapsulated mail through both of them to a single > recipient making him believe he t

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 based on their >> common si

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

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 based on their > common signature key-ID. I don't und

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 per-user keys. > >OpenPGP, or at least

Re: Implications of a common private keys directory in 2.1

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 per-user keys. OpenPGP, or at least as produced by GnuPG, is Sign-

Re: Implications of a common private keys directory in 2.1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wednesday 23 November 2016 at 3:48:19 AM, in , Carola Grunwald wrote:- > This concept of an enhanced transport security layer > offers external > adversaries least possible information while it > doesn't preclude the > sender from adding anoth

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 signature time and >the time noted i

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 to go the whole hog and transport over Tor. A

Re: Implications of a common private keys directory in 2.1

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 signature time and the time noted in the Received:-header are vi

Re: Implications of a common private keys directory in 2.1

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 to go the whole hog and transport over Tor. And even >> that is no panacea.

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 control of a key. Just so long as we >

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: Implications of a common private keys directory in 2.1

Peter Lebbing: > 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 h

Re: Implications of a common private keys directory in 2.1

On 23/11/16 10:19, Peter Lebbing wrote: > I could concur with this statement if we amend it a little: when two > MTA's are explicitly configured as TLS peers. Absolutely. But if you're using a non-standard protocol, then you also need to explicitly configure both sides. So in practical terms ther

Re: Implications of a common private keys directory in 2.1

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 have to abort the mail excha

Re: Implications of a common private keys directory in 2.1

> 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 control of a key. Just so long as we understand that the key is now the

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: Implications of a common private keys directory in 2.1

> 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 necessary. I concur. This post is agr

Re: Implications of a common private keys directory in 2.1

On 22/11/16 18:17, Carola Grunwald wrote: > You seriously recommend to run a dedicated gpg-agent instance for each > of dozens if not hundreds of mail service users? 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 m

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 any chance s/he guesses the >> correct

Re: Implications of a common private keys directory in 2.1

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 any chance s/he guesses the > correct passphrase. That's what fi

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: Implications of a common private keys directory in 2.1

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 believe that what I described is intended behavior, > not a 2.1 design fla

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-