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> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
