Implications of a common private keys directory in 2.1

[Peter Lebbing]

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 accounts, that would link them up as
all using the same proxy. That makes sense, I didn't know you were also
hiding the proxy you're building.

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.

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.

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

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.

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.

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

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. And once a user account is deleted, simply
delete the accompanying secret key (--delete-secret-keys, not
--delete-secret-and-public-key).

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.

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

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.

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.

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

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

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

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

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

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>