Implications of a common private keys directory in 2.1

[Peter Lebbing]

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.

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.

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>