Implications of a common private keys directory in 2.1

Carola Grunwald caro at
Thu Nov 24 14:16:36 CET 2016

Peter Lebbing <peter at> 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>. Intended recipient is
><chelsey at>.
>Message Submission Agent for 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
> post office server (but --throw-keyids). MSA creates
>a new shell RFC822 e-mail message with everything removed but the SMTP
>recipient <hidden at> (this is a special address I'm
>inventing for the protocol).
>We now have a message that only leaks the fact that
>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
>, 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, the process listening on
><hidden at> decrypts the message using its own private
>key. It checks the signature is indeed from its established peer server
>at It knows when 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> 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


More information about the Gnupg-users mailing list