From: Lance Cottrell <loki@infonex.com>
Date: Mon, 9 Sep 1996 14:44:03 +0800
To: Adam Back <mix-l@jpunix.com
Subject: Re: forward secrecy in mixmaster
In-Reply-To: <v03007803ae5817d08aba@[206.170.115.3]>
Message-ID: <v03007808ae59495b4215@[206.170.115.3]>
MIME-Version: 1.0
Content-Type: text/plain


At 11:29 AM -0700 9/8/96, Adam Back wrote:
>Lance Cottrell <loki@infonex.com> writes on several lists:

>I suspected RSAs weird license might be the problem.  (Given the
>situation with PGP 2.x, I presume that the license does not permit you
>to increase the max arithmetic precision.)

Our options will open up alot when the patent expires next year.

>> That is one of the reasons I have each remailer creat its own DH
>> modulus, and allow it to change it periodically.
>
>Each remailer with it's own prime doesn't buy you a whole lot of
>entropy because there aren't many mixmaster remailers, 4 bits
>currently?.  The entropy from having rekeying every day instead of say
>every year, another 9 bits, 13 bits tops?  I'm not sure what the
>precise entropy increase is from going to 1024 to 4096, but it's got
>to be many orders of magnitude better than 13 bits.
>
>I'd say junk RSAREF for the DH operations, use one of the other libs.
>(You can do this for DH, without violating patents, right?  But not
>for RSA, so I guess if you care about the patent/license agreement
>mess, you've got to use RSAREF for RSA signatures at least).  Or maybe
>you could just wait for PGP 3.0 which uses El Gamal, for sigs and pk
>encryption, and presumably will have less restrictive key sizes.

I agree it does not make much difference mathematically, but one DH modulus
always makes me uneasy. DH is still patented though. I think I will continue
to use RSAREF, but compose the standard so the protocol supports unlimited
key sizes.

>So as well as having bigger signing keys, for the sake of paranoia
>(it's contagious), as you were saying, I guess you may gain some
>security by not having a common modulus, and making the protocol allow
>re-keying.
>
>If you used a different password for RSA and DH keys, and your machine
>is compromised, you can sign a new DH key with RSA, and use El Gamal
>signatures with the DH key normally.  Hows that for paranoid :-)
>
>(Or another temporary RSA key, and RSA sigs, rather than El Gamal
>sigs, whatever.  You sign by proxy, that is the receiver mixmaster
>gets a the temporary key signed by the long term RSA key, checks the
>signature on the temporary key, and then checks the signature made by
>the temporary key on the object in question).
>
>Greatly reduces the risk of having the password in the binary.  You'd
>need to manually type the RSA keys password to rekey, or if you were
>real paranoid, you could keep the RSA key on your laptop, and copy the
>new signed DH public key on to the remailer.  Do this once a month, or
>as often as you wish.
>
>This is a similar approach to that taken by people who have a huge
>signing only PGP key, which they are careful to keep only on machines
>they physically control, and have smaller keys which they use on
>multi-user systems.

For now I think we might just suggest that the operator keep a big PGP key
to sign new key releases with. Key management is a whole nother thorny
issue. I would love to see that whole part of Mixmaster reworked. Some deep
thought should go into managing and distributing keys (it was almost an
afterthought in my design).

<SNIP>
>> >a) include the DH key signed by the RSA key in the remailers public key
>> >   (may break backwards compatibility with existing versions of
>> >   mixmaster)
>> >
>> >b) send the DH public key at the start of each session
>> >
>> >c) send the DH public key on request
>>
>> I chose C. The in protocol I developed the sending remailer (A) sends a
>> hash of the DH modulus to the receiving remailer (B). If B has it, they use
>> it. If not, A sends it. I use the modulus from A because it has the stake
>> in privacy. B will take messages from anyone, but A wants to know the
>> messages it has goes to the correct other remailer B.
>
>sounds fine.
>
>Also, you might want to migrate to SHA1 in place of MD5, at some
>point.  Or to one of those megahashes like
>
>	SHA1(MD5(x))||MD5(SHA1(x))

It is something to consider. Right now the software is not that flexible,
but it should be in the next major revision. I too would like to move from
total MD5 dependence.

>Also mixmaster has capabilities like type 1 remailers right?  If so
>you would presumably add a capability indicating that the remailer
>supports direct socket delivery.  And another capability for forward
>secrecy (the other thread "non-interactive forward secrecy" discusses
>ways to retro-fit a less interactive forward secrecy mechanism into
>email delivered mixmaster packets).

Mixmaster recognizes type 1 messages, and passes them to a type 1 remailer.

>The socket capability presumably would be useful to know that it is
>likely to react more quickly.  Forward secrecy is obviously nice to
>know about for other reasons.
>
>Adam

Socket support for type 1 is more complicated. The known RSA key is now the
PGP key which encrypted the message. It is going to be a lot more
complicated to go in a get all the info needed using PGP. Given a PGP
library it could be done within Mixmaster, but it seems outside the scope
of the program. My personal feeling is that as Mixmaster improves and gets
more widely ported, type 1 should phase out.

	-Lance

----------------------------------------------------------
Lance Cottrell   loki@obscura.com
PGP 2.6 key available by finger or server.
Mixmaster, the next generation remailer, is now available!
http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche
----------------------------------------------------------