Implications of a common private keys directory in 2.1

[Carola Grunwald]

Peter Lebbing <peter at digitalbrains.com> wrote:

>On 24/11/16 00:09, Carola Grunwald wrote:
>> When you deal with pseudonymity you have to avoid similarities of
>> your aliases. So the WME keys they use to secure their messages have
>> to be different.
>
>I still don't see why you need per-user keys.
>
>OpenPGP, or at least as produced by GnuPG, is Sign-Then-Encrypt. If each
>Message Submission Agent and each post office (POP3, IMAP) server had
>their own key (you could use --throw-keyids or --hidden-recipient), it
>could be as follows:
>
>User sends from <alice at example.org>. Intended recipient is
><chelsey at nowhere-special.org>.
>
>Message Submission Agent for example.org adds a header indicating it was
>alice who succesfully authenticated, and other interesting stuff. MSA
>then signs and encrypts the whole message. Encryption recipient is the
>nowhere-special.org post office server (but --throw-keyids). MSA creates
>a new shell RFC822 e-mail message with everything removed but the SMTP
>recipient <hidden at nowhere-special.org> (this is a special address I'm
>inventing for the protocol).
>
>We now have a message that only leaks the fact that nowhere-special.org
>is the receiving domain. The OpenPGP thingy itself leaks nothing. The
>signature has a correct, normal timestamp, but this data is encrypted.
>The recipient of the encryption is unknown (but can be inferred to be
>nowhere-special.org, so it's not that useful to use --throw-keyids
>perhaps). It's just an encrypted blob.
>
>This goes through all the remailers, is beamed into space, buried for
>some time on the dark side of the moon, etcetera.
>
>Once it reaches nowhere-special.org, the process listening on
><hidden at nowhere-special.org> decrypts the message using its own private
>key. It checks the signature is indeed from its established peer server
>at example.org. It knows when example.org signed the message. Then
>again, in your proposed scheme, the receiving server also has all data
>like when alice wrote it, and what she wrote. The timestamp from the
>signature adds nothing substantial. The post office server then delivers
>the message in the recipient mailbox, with some status headers.
>
>
>
>As I said, I don't see what different keys for different accounts add
>here. And I don't see why the intended recipient can't know of the
>signature timestamp, so you don't need --faked-system-time. You could
>use GnuPG 1.4, or you could use 2.1 with a gpg-agent daemon holding just
>the private key for the server doing the crypto.

WME combined with nym server usage for example requires an individual
WME key for each account, as otherwise at least the recipient, who may
communicate with different aliases is able to link them based on their
common signature key-ID.

Concerning faked timestamps you have to imagine that an adversary may
observe your Tor connections. When he sees high activity shortly after
the signature's timestamp you may have transmitted the respective
message. And with each positive correlation on follow up messages the
connection between you and the anonymous sender becomes more and more
certain. That's just one example.

>
>Oh, by the way, in reply to a bit from another mail:
>
>On 24/11/16 00:25, Carola Grunwald wrote:
>> Peter Lebbing <peter at digitalbrains.com> wrote:
>>> If you sign the data just before the interaction, the signature
>>> time and the time noted in the Received:-header are virtually
>>> identical, so the signature time doesn't leak data.
>> 
>> No, that isn't correct. Dependent on the length of the remailer
>> chain and the individual latency of the involved hops there may be
>> hours, even days between the signing process at the sender and the
>> final message transfer from the exit remailer to the recipient's
>> MTA.
>
>It's not really that relevant, but anyway: as I said in the next
>paragraph, this was all assuming you were using a regular mail
>transport, not remailers.

I know, but unfortunately this thread became more and more a discussion
about my project, which I didn't intend, and not the problem why I
started it.

Kind regards

Caro