Implications of a common private keys directory in 2.1

[Andrew Gallagher]

On 24/11/16 23:03, Carola Grunwald wrote:
> 
> Let's just say I hold two nym accounts at different nym servers
> 
> https://en.wikipedia.org/wiki/Pseudononymous_remailer#Contemporary_nym_servers
> 
> and send WME encapsulated mail through both of them to a single
> recipient making him believe he talks to two different persons.

In this case, you must have already created a separate PGP keypair on
your local machine for each nym username.

> WME encrypts the
> whole message for the recipient signing it with its individual WME key
> (which can be the nym server account key)

So the server can sign the WME encapsulation with it's own key. It
doesn't add anything for the server to use a per-userid key, because
the user must already have a per-userid key locally in order to use
nym, and so can sign the original message in the MUA.

> encrypts it for the nym
> server signed with the nym server account's key and sends the result
> through the remailer network to the nym server, which removes the nym
> server encoding layer checking the account signature and sends the
> resulting WME message to the recipient.

The same applies at the receiving end. The recipient must have a
per-userid PGP key, and therefore can decrypt messages in their own
MUA. Encryption to the receiving nym server's common key is sufficient
for confidentiality as far as the mailbox - at which point it gets
converted back to a standard PGP message.

So I can see why you want per-userid PGP keys. And I can see why you
want an encryption/signing layer at the MTA. What I don't get is how
implementing per-userid keys *at the MTA* gives you anything but grief.

Sorry if I'm diverting the subject of the thread, but my initial
suspicion was that your scalability issues are the inescapable result
of an over-egged design, and I haven't read anything since to change my
mind.

A


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161125/9f617749/attachment.sig>