Implications of a common private keys directory in 2.1

[Peter Lebbing]

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>