Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing <peter at digitalbrains.com> wrote:

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

I see. Thanks for that clarification.

>
>I'm not talking about /problems/, I'm talking about /design/. I
[brilliant car analogy removed]

With 'problems' i referred to the GenKey bug/feature I reported a few
hours ago and the IPC instabilities I experienced. Sure, the
single-sec-keys-depository : multiple-pub-keyrings configuration is a
design decision, though one I don't quite understand.

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

I hope it at least plugs the security hole of a key in the sec keys
folder different from the one defined with --try-secret-key being used
together with a passphrase from the cache to decrypt data without any
authorization.

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

You mean --try-secret-key doesn't overrule the key parameter that comes
along with the encoded material?

--try-all-secrets doesn't look at the possibly 'bogus key ID' (page 61)
and the manual doesn't say anything different concerning
--try-secret-key.

>>>
>>> And as I said, multiple keyrings is asking for ambiguities when removing
>>> keys, or using a key that has multiple different versions on different
>>> keyrings.
>>
>> That's only critical with a common secret key depository.
>
>But this is what you're doing right now with GnuPG 2.1, right?

That's only because v2.1 forces me to do so, which is what I complain
about, a common secret key depository.

The only alternative to avoid ambiguities with v2.1 would be to confine
oneself to a single public keyring for everything, in my case

- WME keys (pub/sec)
- nym account keys (pub/sec)
- nym server keys (pub)
- remailer keys (pub)

For a more complex application such a restriction means chaos.

http://danner-net.de/omom/tutornymsetup.htm provides some insight.

> AIUI, you
>have one agent and multiple public keyrings. This is similar to one
>secret keyring and multiple public keyrings in GnuPG 1.4.

With 1.4 I have a one-to-one sec:pub keyring relationship, where such
ambiguities don't matter, and where it's foreseeable what happens when I
delete a key pair from such a single keyring pair.

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

User login/logoff represents in no way crypto task granularity, as a
user may hold several nym accounts and WME related addresses and so on.
If I'd take your proposal seriously the agent would have to be restarted
with nearly every en-/decoding call to clear the passphrase cache. Is
that what you have in mind?

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

So the maintainer of the proxy is the owner, right?

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

Which is the account holder, who has the proxy login credentials.

When he logs into the proxy to send a nym message (From:
myaccount at mynymserver.org) the proxy checks whether the account holder
also holds the respective nym account and, if that's the case,
transforms and forwards the message to the nym server. The same holds
true for signing the message of a WME supported From address.

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

I see that differently. The nym service consists of two parts, the proxy
represents the local non-anonymous one, the nym server is the remote
part in anonymity land, both separated but also joined by the
anonymizing message transfer cascade. Those parts can't do without each
other, only together they function correctly, which is why they have to
be seen as an indivisible unit.

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

The same goes with a proxy account.

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

Me as the proxy administrator? Well, the situation is similar to a GMail
administrator, who can also use any GMail account to send messages. He's
the admin, he's God.

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

When the observer sits in your LAN you're doomed anyway. It's only about
an external adversary controlling the Internet.

>
>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'm not sure what you mean by delay in a conversation vs. between
conversations.

What you need is delay between forwarding the message to entry remailers
(multiple copies to increase reliability) and the delivery by the exit
remailer either to the nym server or directly to the final recipient.
Delay at the sender's LAN adds nothing to anonymity.

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

Bad enough.

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

With each signature creation step my application running with admin
rights temporarily changes system time on a random basis.

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

No, no, it's okay.

Let me add that I truly mean no harm though my remarks may sometimes
sound eager or even offensive. For me open discussions are important to
get rid of mindcuffs.

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

The possibly short proxy user's passphrase is different from the key's
passphrase, which is randomly created.

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

Even the client-server interaction in a corporate LAN environment has to
be assumed secure.

>Deconstruction:
>
>do what you want -> fake signature timestamps
>
>abuse things -> use an option that says "for testing only"

So key 'Creation-Date' (page 84)

| Creation-Date: iso-date
|   Set the creation date of the key as stored in the key information and which is
|   also part of the fingerprint calculation. Either a date like "1986-04-26" or a full
|   timestamp like "19860426T042640" may be used. The time is considered to be
|   UTC. The special notation "seconds=N" may be used to directly specify a the
|   number of seconds since Epoch (Unix time). If it is not given the current time
|   is used.

a v1.4 and v2 'feature', is abusive as well? I see no 'testing only'
phrase in that explanation.

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

It depends on what you're aiming at. Sure, PGP/GnuPG was initially
developed to provide privacy by protecting contents. And it does a great
job in this respect. But times have changed. We can no longer ignore
that surveillance also concentrates on metadata resulting in a worldwide
sociogram of the population, making social networks transparent to
intelligence agencies, multinationals and whomever else. The knowledge
of relationships between individuals, groups and organizations opens the
way to social engineering and political oppression. That's why anonymity
including the obfuscation of temporal connections isn't a negligible
gimmick but a crucial measure, which IMHO GnuPG should also be obligated
to. So why not reconsider the 'only useful for testing' statement and
see timestamp invalidation as an important anti-surveillance strategy?

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

Support is in no way less important than development.

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

Being the instigator I take full responsibility for that. ;-)

Kind regards

Caro