Implications of a common private keys directory in 2.1

[Carola Grunwald]

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 the localhost. This seems *so* much better than a server
>which can decrypt all client data! But let's take for granted that you
>want to do it as you want to do it, on a server.

You can do it either way. For several years now I myself run the proxy
server on my laptop computer, holding a few dozen nyms for different
purposes.

>
>I doubt you would run into any trouble just using a separate homedir per
>user account. I don't think agents take a lot of resources. When the
>user logs out, you make the agent quit as well. You could remove its
>socket; it will notice and quit within a short while. There's also the
>Assuan command KILLAGENT which does what it says on the tin. I don't
>know what interface to GnuPG you were planning to use, but I would
>strongly suggest GPGME; it's the official way of programmatically using
>GnuPG. That said, I don't know if GPGME offers a way to issue the
>KILLAGENT command.

It's not about planning, the proxy system is in use for years.

I started the project in 2006, for a short time with PGP 6.x DLLs, then
moved to GnuPG 1.4, which, apart from the missing --faked-system-time
option still works great, very reliable, extremely stable. Three months
ago I thought it was time to adapt it to GnuPG 2.1, and the problems
began. 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. The system is up now for no more than 48
hours. You can't run a server this way. Users ask what's going on. I'm
in trouble, seriously considering to return to 1.4.

I don't use the GPGME interface, rather call gpg.exe directly. I don't
think it makes any difference concerning performance. On program
shutdown I terminate gpg-agent.exe based on its ProcessID.

>
>A separate homedir per user means you get the separation you wanted.

So first of all I have to give every keyring its separate homedir to
avoid the side effect of unintentional secret key deletion across
keyrings, and to address the passphrase caching flaw I even have to keep
each single secret key isolated in its own directory.

>
>I don't see the purpose of using the password of the user account for
>encrypting the private key, though. It doesn't seem to add security and
>does seem to add problems. If you're worried about seizure of the data
>at rest, you could use a single server-wide passphrase to encrypt all
>private keys used by GnuPG. You could use disk encryption, that seems
>like an easy way out and would protect other sensitive data as well. Or
>you could use a specialized pinentry implementation, that always returns
>the same passphrase, which could be seeded when the server boots up.
>Pinentries are easy to write.

Full ACK. User accounts usually are LAN accounts, not that much under
attack as the encrypted message, which needs a strong key and
passphrase.

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

>
>(You could take the middle road and serve, say, 32 clients per agent.)
>
>However, that still presents a serious issue with private key ownership,
>both in the case of multiple recipients and with --throw-keyids, which
>you would not have with an agent per user.
>
>GPGME tells you which private key was used to decrypt the message.
>However, if there are multiple recipients on the same proxy and they
>share an agent, GnuPG will only use the first one that succeeds. If your
>proxy software would inspect the recipient and only allow the owner of
>the indicated key to read the message, the other recipients wouldn't be
>able to read the message, because the agent never needed to use their
>key in the first place. Argh.
>
>For hidden recipients, it would be a serious resource hog to try all
>keys, and would additionally have the same problem with multiple recipients.
>
>An option --only-try-secret <keyID> 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 option would
>be a good idea to implement. It would serve more scenarios than just
>yours. For instance, people with smartcards could use it when a message
>is also encrypted to an on-disk key, when they can't or don't want to
>insert their smartcard. And if somebody knows which key is the hidden
>recipient, but has multiple secret keys, it would save them declining
>all the dialogs for the keys that aren't the recipient.

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.

>
>You are worried about all other kinds of key management issues. I don't
>think that is really so worrisome. You could simply zap the revocation
>certificate already on creation, or periodically zap the contents of the
>openpgp-revocs.d dir altogether, I don't think they serve much of a
>purpose in your scenario.

Right. Revocation certificates are irrelevant.

> And once a user account is deleted, simply
>delete the accompanying secret key (--delete-secret-keys, not
>--delete-secret-and-public-key).

If it were that simple. Every user account can hold an unrestricted
number of nym and WME accounts. When the mail client starts a POP3
request mail is retrieved from different sources. That may be a normal
POP3 account as well as anonymous newsgroups repositories like
alt.anonymous.messages from where incoming messages are downloaded, if
necessary decoded, then sent to the client in one go.

>
>As long as you don't meddle with multiple public keyrings, this is just
>fine. You might say multiple keyrings "without doubt have stood the test
>of time in GnuPG 1.4", but I suspect this test of time is precisely what
>has shown the people actually maintaining this feature that it is
>riddled with hard issues.

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

>
>While we're touching on that subject, if you go the single agent route,
>you could just hold all public keys in one keyring. I think it's built
>to be big. GnuPG 2.1 is a lot more efficient with large keyrings than
>previous versions. And public data is public data, right? No need to
>wall it off.
>
>That does leave deletion of public keys, but you could do reference
>counting in your proxy server. If somebody, through your interface,
>imports a public key you already have, you increment its reference
>count. When the user deletes the public key or the account is deleted,
>you decrease the reference count. Once it hits zero,
>--delete-public-key. Perhaps multiple keyrings would have saved you of
>this, but it doesn't seem very complicated, there are no dependencies to
>track or anything, just a simple reference count.
>
>Or you could use --no-default-keyring along with --keyring and use a
>public keyring per user, that still works in GnuPG 2.1 right? Multiple
>keyrings at the same time has interesting ambiguities, like where to
>delete from and where to add to, which one to use when there are several
>versions of a key, etcetera. I think your issue stemmed from using
>--delete-secret-and-public-key rather than --delete-secret-keys. The
>former is a combination of --delete-secret-keys and --delete-keys, and
>with multiple public keyrings, --delete-keys gets "interesting".

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.

>
>Again, a large part of this mail could just be thrown away unread (or
>unwritten :) if you simply use a single homedir per user account. Is
>this perceived saving of resources worth all this trouble? Changing
>secret keyrings in GnuPG 1.4 is more or less replaced by changing
>homedirs in GnuPG 2.1. It's not this difference which you're coming up
>against here, it's the difference that 1.4 does everything in a single
>process that quits when it's done. In 2.1, there's the agent, which
>survives.

I think a different agent for each of my current keyrings may be an
option I could deal with. 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. It's a small
tool running as a background task residing in the system tray.

>
>Something totally different, but brought up by other people before. Do
>the generated private keys hold UID's? And if so, it's just the nym
>e-mail address, right? No name portion. You'd better *very* clearly
>inform your users then that your server is pretending to be the owner of
>their nym address, and very clearly inform them that your server can
>read all this encrypted data! You say they are free to add another layer
>of encryption. Sure, but make them realise that without this, they are
>placing a huge amount of trust in your server and its operators, and
>where it is housed etcetera. If your software would run on the client,
>this wouldn't be an issue. And it's a huge issue, IMHO.

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. He can use your nym's address as a normal mailbox without
any encryption at all. 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.

>
>> Simple answer: You never know who your opponents are. How can you be
>> sure the recipient of your mail isn't one of them? Or his network
>> infiltrated and his computer compromised?
>
>Right, yes, pseudonymity, the recipient could be the adversary. I'm not
>used to thinking about Alice or Bob that way.
>
>Anonymous remailers solve the time issue by random delays. You could do
>that here as well: hold onto the mail for a random time once it's
>submitted, then sign it, then hold onto it for some more time (random),
>and only then submit it to the anonymous remailers. It's just two hops
>extra random delay in the remailer network, in the sense of time spent.

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

>
>But if you want to drop timestamps, I doubt --faked-system-time is your
>friend. Like the manual says, "only useful for testing"! It affects
>everything. If someone creates a key and sends it to their
>correspondent, and the correspondent would use a --faked-system-time
>from before the creation date, *poof*. GnuPG will notice the key seems
>to come from the future and deny to encrypt to it. Everything breaks
>down. Same with expirations and extensions thereof. Also, there's the
>trust database, which is periodically rebuilt and timestamped.
>Interestingly, my GnuPG 2.1.11 didn't complain that the trust database
>was from the future, but I wouldn't depend on this staying this way.
>
>Another nice edge case: a key is created at 14:54, but it's trying to
>issue a signature at 12:00. Oops:
>
>$ echo hoi | gpg2 --faked-system-time "20161203T110000" -u 0E675C27 -s
>gpg: WARNING: running with faked system time: 2016-12-03 11:00:00
>gpg: key 0E675C27 was created 10495 seconds in the future (time warp or
>clock problem)
>gpg: key 0E675C27 was created 10495 seconds in the future (time warp or
>clock problem)
>gpg: skipped "0E675C27": Unusable secret key
>gpg: signing failed: Unusable secret key

http://danner-net.de/omom/tutor_issues_gpg_time.gif

With random time of yesterday (Day-1) for signatures or the day before
(Day-2) for key creation, all UTC, it's secure.

>
>(I'm on CET, and --faked... is in UTC).
>
>And I wouldn't be surprised if there are more snags when you pretend
>you're not living in the now.

Sure you have to do all your timestamp calculations in UTC. Otherwise
you'd even leak your timezone.

>
>I just checked the OpenPGP RFC, and though the signature timestamp is a
>separate subpacket that could be omitted, there is a MUST requirement
>that it is present. So to create an OpenPGP compliant message without a
>good timestamp, you do have to fake a timestamp, unfortunately. Maybe
>you could make the case that faking a signature timestamp should be a
>feature? I can imagine a different use case: not letting the recipient
>know you were still working on stuff at 3:00 in the night, even though
>you were. But it doesn't seem like a high-priority feature request to me
>(sorry).

Of course that's a feature, an important feature protecting privacy,
worth to be backported to v1.4. There always are situations where you
want to prove the Who but not the When, which can be faked anyway.

>
>> Footnote:
>> A pinch of paranoia helps develop solid anonymity software.
>> Act as if there's no one out there you can trust.
>
>Yes. My mind is used to thinking about the recipient as implicitly
>trusted with knowledge, which just isn't the case in a pseudonymous
>system. Anonymity is easier in that respect: signatures make no sense at
>all.

That's correct.

Many thanks for your profound considerations.

Kind regards

Caro