Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing wrote:

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

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!

Today I added symmetric dummy encodings to my application, performed in
5 minute intervals to keep gpg - agent IPC alive. So far no more
259/$103 GPG_ERR_ASS_CONNECT_FAILED (IPC connect call failed) errors.
Let's see. I can't believe that I'm the only one who has to deal with
such problems.

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

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.

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

The nym server doesn't know who you are nor, with additional end-to-end
encryption, will he know about the data you exchange. He can only cease
his service for whatever reason, which doesn't mean any security risk.

And there is the user, who is in complete control of the sending
machinery. It's only about whom you see as the user. If it's an
individual who acts on his own responsibility he has to deploy the proxy
within his sphere of influence, e.g. on his computer side by side with
the mail client. 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.

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

See my comments above about business rules. For a corporation it's
important to centralize communication and to keep the ordinary user of
its infrastructure from having access to crucial information like
communication keys.

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

I see no relevant difference between a client - proxy server connection
within a LAN and through the Tor network to the proxy's .onion address.
With some Tor cover traffic on the client and proxy side an adversary
won't have a chance to detect the mail message transfer via the Tor
network.

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

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

Btw, apart from regular remailer messages the proxy sends randomly dummy
messages to invalid addresses to disguise true communication.

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

No. The proxy user logs i with jdoe:PaSsWoRd, the nym / WME key's true
passphrase, stored at the proxy, looks like
"8OSdA0cKTHrxtfJ7ii+s3VtssXtUf4w2x1wfXN75F+U".

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

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

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

TLS isn't very expensive, it's active here even with localhost
connections. And connections to Tor hidden services at home can be seen
as anonymous VPN connections, not much worse than true LAN 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.

Don't get me wrong, but what I see here is the difference between
enlightened thinking and servile obedience overinterpreting the wording.
Tools have to serve purposes, and if they are imperfect in doing so they
have to be adapted, at least as long as the author(s) have no objections
to the given purpose, which here means anonymous communication. So I'll
immediately shut up in case Werner says Internet anonymity is a bad
thing.

Kind regards

Caro