Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing <peter at digitalbrains.com> 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 left in it.

If I only had a --faked-system-time option ...  :-(

That was the only reason why I migrated to 'modern' v2.1 - and slipped
into a disaster.

But what do you mean by 'deprecated for server use'? Where in
https://www.gnupg.org/documentation/manuals/gnupg.pdf is GnuPG 2.1
restricted to a single-user scenario? I only found

| In contrast to the standalone command gpg from GnuPG 1.x, which might be
| better suited for server and embedded platforms, the 2.x version is
| commonly installed under the name gpg2 and targeted to the desktop as it
| requires several other modules to be installed.

which is only about a more complex deployment, not about security risks.
In my view crypto software that leaks information, for example caches
passphrases for unauthorized access, doesn't qualify for any kind of
use.

Btw, a spelling error on page 102 line 15:

| The encryption is done by using the command
      ^^
| DECRYPT

>
>> 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.

I addressed my problems at the devel list.

>
>>> 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.

Initial problems with new software are okay as long as they can be fixed
when they arise.

>
>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.

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=myaccount at nym.mixmin.net
| O-Nym-Sig: Good signature (SHA1:[562619C278247C3B] Bananasplit Pseudonym Server (Bananasplit Pseudonymous Email Server) <config at nym.mixmin.net>; Sat, 10 Dec 2016 02:25:44 +0000)

>
>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.

I now added --try-secret-key to all asymmetric decoding calls, which
made processing a bit faster and possibly counters the passphrase cache
weakness with asymmetric decryption.

But there still remains the possibility of a symmetric decryption even
with an invalid passphrase when the correct one is in the cache. And
that will remain undetected, as there's no key-ID indicating the
deviation from the given passphrase.

>
>> 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.

When finally, what I still hope, the instabilities of the Windows build
are cured, I think about running separate agents dedicated to the
keyrings that hold secret keys, which I then would combine with pure
public keyrings used for encryption and signature checks. That still
adds a lot of complexity, but prevents erroneous secret key removal.

It's not the user, it's the application that has to care about the
structure and integrity of key storage. It's hard to tell users about
the purpose of different key families when all of them are lumped
together in one basket.

>
>> 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.

That's only critical with a common secret key depository.

>
>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".

Who would use a single secret keyring with different public keyrings?

>
>> 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?

For security reasons currently all gpg calls are chained to avoid any
interference.

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

No, I don't, as a user can hold multiple nym accounts and WME related
addresses, which e.g. with a POP3 download are processed in common.

>
>> 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?

Sure. It's upon the user how to deploy the software, either locally on
his private computer or in an enterprise environment.

>
>> 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.

With your interpretation of 'holder' gmail is the holder of all the mail
accounts hosted there. In my view the one who is allowed to use an
account is its holder. My software only adds the mechanisms to interact
with nym servers in an easy way, which has to include to be in control
of the nym acccount's key to prove one's identity when sending server
commands. But this key does in no way have to be used for end-to-end
encryption between dialog partners. The nym holder doesn't even have to
know about the key's ID.

>
>In the end, the nym server is actually the real /owner/.

In fact it's the proxy server resp. its administrator. The mail message
you send to the nym server when creating an account includes your nym's
public key, which then is used to check signatures authorizing further
mail you send to the server.

> 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.

With standard mail it's always up to you to care about end-to-end
encryption. No system can know about the capabilities of your mail's
recipients. You may agree on WME or normal OpenPGP encryption or no
encryption at all. Nyms only provide anonymous/pseudonymous delivery.

>
>> 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!

Of course users have to know that only the route between the proxy and
the nym server is secured.

>
>> 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?

Nope. It's the sender who won't understand why to waste time while
getting rid of his message. Delay on the way to the recipient is a
bothersome though extremely important characteristic of anonymous
delivery. But delay at the sender is more of a hindrance than a help.

>
>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 think we are agreed that delay in a conversation, though indispensable
for anonymity, can't be infinite. You now have to make a decision,
either to burn much of the time you have to invest at your computer, or
to fake signature timestamps and send the message immediately through a
significantly longer remailer chain.

And remember, without a faked timestamp, no matter how long you wait,
your signature still unveils that you had access to a computer at the
time you signed the message. Allow an opponent who suspects you as the
nym holder to gather a few of your nym's timestamps and you're toast.

>
>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 :-).

I hope I gave convincing reasons now.

>
>> 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.

But I do, as there's no other way to tell the proxy account holder
whether local message processing succeeded.

> 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.

You're at the client site, where it's only about forwarding messages as
fast and convenient as possible without revealing any important
information. Chaum mixes as realized in the Mixmaster remailer network
are much better in using time efficiently.

>
>> 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!

After all that discussion you still think suppressing the true timestamp
of a message is 'abuse', possibly even fraud?

As already discussed in the 'Proof for a creation date' thread you have
to adopt other measures to provide solid evidence for the validity of a
signature timestamp, which on its own is of now value at all. No sacred
cow worth being protected at all hazards.

>
>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!

I have to thank all of you to render projects like mine possible.

Kind regards

Caro