[Mixmaster-devel] mixmaster v3 keys

[Peter P. <pe...@pa...>]

In v2 of the mix protocol each remailer has one key which is used to
encrypt messages to it. No method for signing mix keys in a standard
way is used in this version of mixmaster.


I propose the following scheme:


Each mixmaster remailer has one =BBmaster key=AB, which is used for signing
purposes only. No message is ever encrypted to this key.

Additionaly it has one or more =BBgeneral encryption keys=AB. End users
encrypt their messages to the general encryption key. A public key
block for a general encrypt key contains the following:
  - Name of remailer
  - Date of expiry (YYYY-MM-DD)
  - key data (dependend on algorithm used
      (eg: for RSA: key size, modulus and exponent)
  - _Signature_ of the previous information.

The signature is be made with the master key.  There may be more than
one signature block. If at least one of them verfies successfully the
key block is considered authentic (Rationale: Changing master keys can
easily be performed).

Each remailer must return to =BBremailer-key=AB requests:
  - the latest public master key
  - one or more public general encryption keys

The master key is only used for signing general encryption keys. If a
mix2mix protocol is implemented it may also be used to negotiate a
session key[1].



Rationale: Many users fetch their public keyrings from centralized
pinger services. If the chose to do so, their security is completly at
the pinger's mercy. Reasons for taking this risk might be the amount
of work needed to maintain a current keyring themselves.

Using this scheme users could collect the master keys, which are quite
long term (6 to 24 months?), themselves. When they fetch the general
encryption keys from a pinger service they can then easily verify the
authenticity of each encryption key (a mixmaster client should refuse
to use a unverified encryption key).

The same applies to remailer operators.



Remailer operators may chose to provide two different types of general
encryption keys: short term and long term. Remailer users may then use
the more suitable for their purpose.




Comments?
					yours,
					peter

1. signing only - if a /passive/ attacker gets to know the private
master key it should not be possible to get session keys with it.

--=20
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
    messages preferred.    | : :' :      The  universal
                           | `. `'      Operating System
 http://www.palfrader.org/ |   `-    http://www.debian.org/