Implications of a common private keys directory in 2.1

[Peter Lebbing]

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 moment I have seven (!) gpg-agent.exe entries sharing the
> same HomeDir listed in the Windows Task-Manager, six of them frozen, 
> one hopefully still alive.

That sounds like a bug. In fact, an agent-freezing bug was fixed a short
while ago, are you runnning the latest and greatest? Otherwise, it might
be a new bug.

>> If you really want to cut down on the number of running agents,
>> I'd first discuss this with the GnuPG developers. Is the agent well
>> suited to serve dozens, hundreds of private keys? If the design
>> never accounted for this possiblity, it might be horribly
>> inefficient or expose unexpected issues.
> 
> Works fine with 1.4.

I understand what you mean (I think :), but you can't really draw any
conclusions from that, I (also) think. The private key handling in the
agent is all different code, a new architecture. That GnuPG 1.4 in
practice works fine with many secret keys does not say anything about
what the agent will do, even though they basically perform the same task.

I might be overly cautious here; Werner might well say "well sure it
handles lots of keys fine". But being cautious sometimes pays off
tremendously well...

> I'm not sure whether gpg.exe can handle the concatenation of dozens
> of '--try-secret-key A7DD28F363B0924E3B735F22A49104AD3835E227'
> parameters and stop using keys not on that list even with their
> passphrases in the cache.

But you know which nym address the message was addressed to, right? When
somebody tries to open a message addressed to their me at nyma.com account,
you only try the key associated with me at nyma.com. Two keys at max, when
you're doing a key rotation and the old key is still valid.

There is no need to try their me at nymb.com key, because you know it was
addressed to me at nyma.com, and any message ending up there being
encrypted to me at nymb.com could even be an attempt to link those
identities: if me at nyma.com answers to the content of the mail, you now
know they actually have the private key for me at nymb.com, and you've
linked those accounts. It seems to me you *really* don't want any other
keys to be tried *at all*, even if the user owns them.

And similarly, if you could actually order the tried keys with
non-hidden recipients, you would only specify one or two keys which both
would be keys your user actually has. And --status-fd neatly tells you
which key was used to decrypt, so you can easily verify the intended key
was being used and not some other. However, right now, there is no way
to force trying specific keys first with non-hidden recipients.

> Don't get me wrong, but wasn't it just indolence to do without a 
> separate sec key folder for each keyring?

Well, since Werner would actually like to get rid of multiple keyrings
because of the problems it is giving, I can quite understand not
touching it with a forty feet pole when creating something new. In fact,
I wouldn't have been surprised if multiple public keyrings wasn't
implemented in GnuPG 2.1. But he did maintain that feature for now.

> Exactly. For a user it looks like he has a key pair listed on one 
> keyring, and when he adds and removes that key pair from a
> completely different keyring the secret key is removed from both.

Don't use --delete-secret-and-public-key, but --delete-keys and
--delete-secret-keys.

And as I said, multiple keyrings is asking for ambiguities when removing
keys, or using a key that has multiple different versions on different
keyrings.

GnuPG 1.4 didn't always do the right thing with one secring and multiple
pubring's either. Or, "the right thing"... I mean, "the thing the user
intended".

> But ending up with dozens if not hundreds of agents around, working
> or frozen? I hope you understand that I don't like to bear
> responsibility for such a freaky scenario.

No, but the freezing seems like a bug, a bug that should be fixed if it
is the agent's fault. And if you actually have hundreds of users logged
in at the same time, I would not think that hundreds of agents is
actually significant. Have you tried to run a test load, see what
resources those agents actually take? And whether that's actually
significant compared to the processing involved in handling all those
mails of which they are doing the assymetric decryption part?

I am assuming you kill an agent when a user logs off.

> It's a small tool running as a background task residing in the system
> tray.

Maybe I don't understand, your proxy serving hundreds of users with each
possibly dozens of nym accounts is a diminutive part of the server? Or
do you mean when it is running on the client?

> Your correspondent doesn't even have to know about your nym's key,
> which first and foremost is used to secure your proxy - nym server 
> communication.

The problem is the impersonation and who actually is the account holder
of a nym account. Your server is pretending to be the holder, or,
actually is the account holder. Your users don't own the nym account
anymore. They need to know this. The proxy might allow them to use the
nym address, but the proxy is the holder of the nym address. It holds
the private key. QED.

In the end, the nym server is actually the real /owner/. But this is
more easily understood by users. They might not realize that they are
actually authorizing your proxy to do their business on their behalf,
impersonate them even. But it is a pseudonym, so it's less bad than
impersonating them using their legal name.

> But if you think client-to-client encryption is necessary then create
> and send him an additional key. IMHO no issue at all, the user
> rules.

Iff they know how it works! User education is very important here,
because if they think "it's encrypted and pseudonymous" and don't use an
additional key, they are unwittingly including you (as server operator)
in their private communications!

> It's a transparent proxy server not caching any message. When the
> client sends a message, a '250 Ok<EOL>' isn't returned before the
> proxy forwarded it to the Internet. How could the client otherwise
> get knowledge of processing problems. So, apart from wasting time by
> adding hours of latency at the sender just to get a different
> signature timestamp, your client would time out and drop the
> connection.

This doesn't make sense to me. You don't want to expose the time the
signing is done, but then you go and expose the timing of it anyway by
sending the mail right away straight to its destination because your
user doesn't want to wait?

I think those users that can't wait also can't use anonymous remailers
then? Several hops of anonymous remailers takes longer than two delays
on the proxy. When they can't wait for the proxy to delay, they
certainly can't wait for the anonymous remailers taking even more time.
And if the anonymous remailers don't delay, they still leak the time of
sending as much as your signature timestamp does, and do so to all
passive listeners rather than just the nym server decrypting the message
and seeing the signature.

I can understand not wanting to change a design much that has been
running for many years, so I am not saying you should do everything
differently. But keep it as it is for the right reasons. This doesn't
seem to be one to me. Unless I'm once more missing something :-).

> Or think of someone who got the chance to send nym mail immediately
> through an open WLAN access point away from home. For him waiting is
> not an option.

I'm not suggesting that the proxy force the client to wait before
sending the message to the proxy, or to wait for confirmation from the
proxy. That would be silly, because the actual communication over the
public internet would still take place at the same time as signing, just
a bit later. You want to lose the temporal connection between the client
sending the message and it being processed further. I'm saying it should
accept the message (do sanity checks), hold it in a queue for a while,
and only then sign it. Hold on to it some more, and then send it on.

An anonymous remailer wouldn't force an incoming connection to wait for
a while either, right? It would accept the whole message, wait, send on.

> Of course that's a feature, an important feature protecting privacy, 
> worth to be backported to v1.4.

I think this distinction is important: *It's not a feature in any GnuPG
version*. That you can abuse things to do what you want does not make it
a supported feature!

I see a place for such a feature, but ultimately, the maintainers decide
whether it has a place in GnuPG or not, even if another developer did
the work of implementing it.

> Many thanks for your profound considerations.

I enjoy thinking about such stuff, and I hope it is useful to people I'm
thinking it aloud to...

By the way, thanks for working on solutions to let people protect their
privacy and identity. It's important work in today's society!

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>