I think I've made my point, but more importantly, I feel that you understood what I tried to get across. You reach a different conclusion than I, but I think any further discussion on these points would lead to rehashing of previously made arguments.
On 12/12/16 04:06, Carola Grunwald wrote: > You're right, unbelievable. I specify --try-secret-key with a > > [GNUPG:] ENC_TO 0000000000000000 18 0 > > message and gpg still tries out two dozen WME keys with a passphrase > not valid for them. What a waste of time! Hmmmmm, it looks like --try-secret-key only suppresses passphrase queries for keys, any cached keys are tried anyway? I didn't notice this before. I did use 2.1.11 before and now I'm using 2.1.16, but I don't know if I tested this properly with 2.1.11. > No confusion. The proxy server just assembles mail from different > sources, which are a normal external POP3 account and a local > repository of newsgroups, where nym replies are stored for being > downloaded anonymously by the nym holder, e.g. > alt.anonymous.messages. Well, never mind the confusion, of which I still think there is some, as I fail to understand your conclusions. You say a logoff is so frequent it will not be a good idea to kill the agent then (I think, or something on that order). Okay. You don't need to use the logoff as the signal to stop the agent, you could easily do a timeout as well. First of all, in the following, assume a homedir and thus agent per proxy user account. Once you invoke a private key operation, you also put a timestamp somewhere. Maybe a file called "last_used" in the GnuPG homedir, it could also be a timestamp in a database. Everytime you use a particular homedir(/agent) to decrypt or sign, you update this timestamp. Now you have a reaper process that looks at all "last_used" stamps there are, every minute. Once it notices that "last_used" is more than a minute ago, it'll kill the agent for that homedir, and remove the "last_used" stamp. This way, as soon as your user has done nothing for a minute, their agent is stopped. When they do something again, the agent is just started up again, and stays alive until the client is idle again, at which point it is once again stopped. So, agents are only running for clients that where active in the last minute. This should not waste resources at any appreciable level. > When it's a corporation on behalf of which the proxy is used it won't > matter whether the corresponding employee and the proxy admin are > different persons, as both are bound to the company's rules to act in > concert. I actually thought you were also offering a proxy server to the wide public, not just as a corporation to its own employees. But you know what, never mind. You seem to have understood my point. > It's better than nothing. Nevertheless it's a compromise I see no > reason for when otherwise there's a chance to manipulate the > timestamp directly and avoid any latency between the client and the > entry remailer(s). I presented it as an alternative to fake timestamps, to avoid having to do them. When you say "I see no reason to do that when you have fake timestamps", well... Yeah. You'd be right. That's pretty much what alternatives are for. To do the same thing in a different way. > ??? It's about the protection of data in transit, not about securing > the proxy server. With compromized keys a single passphrase for > different nyms is a solid proof for a similar origin. I was talking about the encryption of the private keys sitting on the multi-user proxy; there's no need to use different "passphrases" for different keys. This is /not/ data in transit. These passphrases that encrypt the private key never leave the proxy, it's private information to the proxy. > Don't get me wrong, but what I see here is the difference between > enlightened thinking and servile obedience overinterpreting the > wording. Don't get me wrong, but... you know what? Let's just not. > So I'll immediately shut up in case Werner says Internet anonymity is > a bad thing. And that's an unnecessary, cheap shot. It will not make feature requests any more likely to succeed if you pour them in such a mould; on the contrary. Cheers, 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
