Implications of a common private keys directory in 2.1

[Peter Lebbing]

On 11/12/16 20:58, Carola Grunwald wrote:
> 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.

Oh, I thought you were referring to my warning that running the agent
with lots of private keys might hit some unforeseen issues.

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

No, it specifies which keys to try for a hidden recipient. This is easy
to investigate if you create a few test private keys and create some
test messages. I did that earlier, and I could see no overruling
behaviour or even a preference to --default-key or --try-secret-key.

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

This is comparable to a one-homedir-per-user setup in GnuPG v2.1.
However, that means multiple agents.

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

Okay, I don't really understand. In the POP3 usage scenarios I'm
familiar with, the client downloads all new mail since last time it
connected, and then disconnects. I get the feeling you do something
different, and that's what is causing the confusion.

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

The owner of <me at nym-a.com> is the nym-a.com's operator, not the proxy.

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

Surely you can use nym accounts without your proxy? Are you saying
everybody who uses a nym service uses your proxy?

I'd consider them an indivisible unit only if they are run by the same
operator. So if you run both nym server and the proxy, then yes, it's
one unit. But this seems rare: wouldn't it defeat the whole purpose of
spreading the message over so many systems? You hold entry and end
point, what is still anonymous about that?

If the nym server is run by someone else than the proxy, that means
there are two parties involved. You depend on the nym server operator to
keep operating your account for you on that end, and on the proxy server
operator to do the same on the other end.

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

Yes, they are. This, most people will realise.

That the proxy server operator is not only doing work on behalf of the
user, but is actually acting as account holder on behalf of the user is
something that I wouldn't think obvious.

Any proxy server that sees cleartext passphrases can abuse that power.
But normally, it is just a gateway passing passphrases. Your proxy is
actually the one *having* the passphrase so to say, not the user. This
is unusual and needs to be clearly communicated. That's all I'm
advocating: clearly communicating to the user that they are not the
holder of the nym account, but are only allowed to use it while the
proxy holds it on their behalf.

> I'm not sure what you mean by delay in a conversation vs. between
> conversations.

In my example, the client is forced to wait before the proxy will accept
the message. This is a delay in a conversation.

A delay between conversations would mean accepting the message without
delay, closing the connection to the client, and then not sending on the
message immediately. Only after a delay, open the conversation to the
remailer.

> Delay at the sender's LAN adds nothing to anonymity.

First of all, you talked about a Tor hidden service earlier, not merely
LANs.

Secondly, if the message is signed at 12:00, but the message is only
sent at 14:00, that means the signature time is no longer strongly
linked to the time the message was sent. I believe this was your goal,
rather than "adding mothing". It might not be the full day of difference
you advocated earlier (data signatures one day earlier, key management
operations two days earlier, you rougly said), but to dismiss it as
nothing...

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

Ah, so the proxy user can't enter a wrong passphrase for the signing
key, which was my point.

I don't see the use of a per-key or per-user passphrase at all, by the
way. Just use a proxy-wide key or disk encryption.

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

Again, I remember you mentioning Tor hidden services and TLS on
client->proxy connections.

> So key 'Creation-Date' (page 84)
> 
> [...]
> 
> a v1.4 and v2 'feature', is abusive as well? I see no 'testing only'
> phrase in that explanation.

That's an odd question, since you answered it so clearly, as I see it.
There's no 'testing only' there, so why would it be abuse? It's abuse to
use something that's clearly labeled as "for testing only" for something
that is so adamantly not testing.

>> To which I say: *it's not a feature*.
> 
> It depends on what you're aiming at.

"A feature" here meant: something that is supported by the program. If a
program does not have a certain feature, it means that the program
currently is not designed to do that.

I'm saying GnuPG does not have a feature to fake signature times.

It could be a worthy addition to its features, but it is not a feature
that the current program has.

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>