Implications of a common private keys directory in 2.1

[Peter Lebbing]

I'm going to respond to a few points that I already know my answer to. I
might not actually have all that much interesting to say about the more
complicated points, though...

> But what do you mean by 'deprecated for server use'?

I meant that GnuPG 1.4 is not deprecated for server use. By which I mean
it is pretty much advised against for desktop use.

I didn't mean that GnuPG 2.x was deprecated for anything at all :-).

> which is only about a more complex deployment, not about security risks.

It does say "targeted to the desktop", by the way.

> In my view crypto software that leaks information, for example caches
> passphrases for unauthorized access, doesn't qualify for any kind of
> use.

That's because it is assumed that if someone can access your ordinary
agent socket, that would mean they have full access to your user account
and are thus qualified to use it. It doesn't leak any information if it
is simply handing that information to the user. It's just that your
definition of "user" is quite different than the definition that was
used in the design of the agent!

(I kinda thought we had established this by now...)

> Initial problems with new software are okay as long as they can be fixed
> when they arise.

I'm not talking about /problems/, I'm talking about /design/. I
atrociously hate car analogies in IT, so I'm going to do one. If you
compete with a lorry in the 24 hours Le Mans, and you finish last, would
you say this is an "initial problem" in the design of your new lorry?
And if you tried to deliver a load of 50 liter beer kegs to a bar in the
center of a city with a lot of speedbumps, using a Le Mans Prototype
racing car, would you then complain that it seems not to work altogether
that brilliantly?

I'm not even saying that the agent is incapable of handling a large
amount of keys. I'm just saying that since it is possible that the agent
was designed for use by a single human with a usual amount of keys, you
could run into unforeseen problems when you use it in a totally
different way.

Such as that the agent doesn't have the required bottom clearance to go
over speed bumps.

> I now added --try-secret-key to all asymmetric decoding calls, which
> made processing a bit faster and possibly counters the passphrase cache
> weakness with asymmetric decryption.

I really don't think it will prevent a cached passphrase from being used!

Also, I doubt it serves any purpose without hidden recipients.

> That's only critical with a common secret key depository.

But this is what you're doing right now with GnuPG 2.1, right? AIUI, you
have one agent and multiple public keyrings. This is similar to one
secret keyring and multiple public keyrings in GnuPG 1.4.

> Who would use a single secret keyring with different public keyrings?

Erm... see above? :-)

Apart from that, it's actually something people do use. It's why you
need --no-default-keyring if you don't want to use multiple keyrings
with --keyring. If everybody only ever used one public keyring at the
same time, --no-default-keyring would be implied.

>> I am assuming you kill an agent when a user logs off.
> 
> No, I don't, as a user can hold multiple nym accounts and WME related
> addresses, which e.g. with a POP3 download are processed in common.

First of all, I'm saying "in this scenario of how you could solve it,
I'm assuming part of the way you solve it is by killing the agent when a
user logs off". So "No, I don't" is not an answer I'd expect, I'd then
expect "No, I would not".

Furthermore, I don't understand. When this user logs off why would it be
bad to kill their agent? They've sent "QUIT" to your POP3 server and
closed the TCP/IP connection: they've logged off your proxy! You can
just restart the agent when they log back in. It has no relation with
how many nym accounts this user has whatsoever, that's a non-sequitur to me.

> With your interpretation of 'holder' gmail is the holder of all the mail
> accounts hosted there.

No, I said this correctly, I think. I used two different words, owner
and holder. GMail is the /owner/ of all the e-mail accounts. If they
decide to go bankrupt, you can balk all you want, you won't get your
<itsa-me at gmail.com> name back to use it. It's gone together with its
owner, GMail / Google. You don't have any rights to the gmail.com name.

The /holder/ is the one who has the passphrase.

And since a nym account is not protected by a passphrase but by an
OpenPGP keypair, the one holding the private key is the holder. And your
proxy has the private key. Not your user. You yourself say they don't
even need to know the key's ID, let alone its private key.

If I know your GMail passphrase, and I log in and change that
passphrase, I've taken your account. Would you say you still hold that
account? By rights you perhaps should, but you *don't*.

If you decide you quite like being the pseudonym <me at nyma.com> and take
it from your user, would you say they still hold that account?

That's the crux of the matter.

Your users know that the server operator of nyma.com can just say to
them "Hey, it's my server, I don't want you to use <me at nyma.com>
anymore". They need to know this goes for your proxy as well.

> Of course users have to know that only the route between the proxy and
> the nym server is secured.

I hope you mean "of course I need to inform them", not "of course users
should figure this out", because it's slightly ambiguous the way you say
it :-).

> Delay on the way to the recipient is a
> bothersome though extremely important characteristic of anonymous
> delivery. But delay at the sender is more of a hindrance than a help.

I'm saying you should

delay delivery
sign
delay delivery
deliver to first remailer
it delays delivery
....

Don't delay the action of sending, delay the action of delivery.

> I think we are agreed that delay in a conversation, though indispensable
> for anonymity, can't be infinite. 

Delay in a conversation serves no purpose at all.

What the people doing conversation see:

(TCP/IP connection from client to proxy)

12:00 C> Please send my message
12:00 P> Alright, please accept a delay...
12:05 P> Okay, I'm done pondering the great truths, deliver!
12:05 C> <My message>
12:05 P> Thanks

and

(TCP/IP connection from proxy to first remailer)
12:05 P> Got a message for ya
12:05 R> Go ahead
12:05 P> <Message>
12:05 R> Thanks

What an observer sees:

TCP/IP connection to proxy, originating at client:
12:00 C> <Encrypted>
12:00 P> <Encrypted>
12:05 P> <Encrypted>
12:05 C> <Encrypted>
12:05 P> <Encrypted>

TCP/IP connection from proxy to first remailer:
12:05 P> <Encrypted>
12:05 R> <Encrypted>
12:05 P> <Encrypted>
12:05 R> <Encrypted>

The temporal connection between the two is glaringly obvious! You know
when the client sent this message!

Delay in a conversation doesn't help. You need to put a delay /between/
conversations.

I can agree that delays shouldn't be infinite. Kinda goes without
saying, although this would be a *very* secure system.

> And remember, without a faked timestamp, no matter how long you wait,
> your signature still unveils that you had access to a computer at the
> time you signed the message.

It only reveals that your computer was running if your proxy is running
at the client. If the proxy is on a server, you could use the delay
tactic and it would severely limit the use of knowing the timestamp.

But when the proxy is on the client, then I think that a faked timestamp
is useful. Also when you don't want to change your whole design. But how
do/did you handle timestamps with GnuPG 1.4?

> I hope I gave convincing reasons now.

Yes. Also; when I didn't reply to things you said earlier in the
discussion, that was sometimes because I agreed so had nothing
interesting to say about. This tactic does make it seem like I only have
counterpoints and never agree with anything, so I should probably be
more aware of this effect...

> But I do, as there's no other way to tell the proxy account holder
> whether local message processing succeeded.

This depends on the intelligence of the proxy. If it depends on the
first remailer to do checks and report success, then it won't work. But
if it can check the sanity of the message without doing any connections
to the outside world, it can do all of those checks and only delay the
signing. And I already said that I see no reason to use the user's
password to encrypt the private key, so signing can't fail due to a
wrong passphrase.

> You're at the client site, where it's only about forwarding messages as
> fast and convenient as possible without revealing any important
> information.

This seems to presume the proxy runs at the client. I've already said
above that the delay tactic only makes sense when the proxy runs on a
server, so I agree.

> After all that discussion you still think suppressing the true timestamp
> of a message is 'abuse', possibly even fraud?

No, I said using --faked-system-time to fake a signature timestamp is
abuse of functionality.

The man page says "This option is only useful for testing", and that's
not what you're using it for.

Please read what I say. I said:

I think this distinction is important: *It's not a feature in any GnuPG*
*version*. That you can abuse things to do what you want does not make
it a supported feature!

Deconstruction:

do what you want -> fake signature timestamps

abuse things -> use an option that says "for testing only"


You said "worth to be backported to 1.4". This seemed to imply to me you
thought the worth was in faking signature timestamps, but a backport
implies that we're talking about an actual feature. To which I say:
*it's not a feature*.

> I have to thank all of you to render projects like mine possible.

Heh, well, I can't take credit for that, so I'll happily pass these
thanks on to the people that do :-).

Oops, this mail has gotten so much larger than I intended...

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>