Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt

From: Glen Zorn <[email-masked]>
Date: Wed, 22 Sep 1999 13:31:31 -0700 (PDT)

On Wed, 22 Sep 1999, David Wagner wrote:

> > Not wrong.  Since I was (undoubtedly inadvertantly) dropped from this list
> > and only recently re-subscribed, perhaps you could fill me in.
> 
> Sure, no problem.  Here's a copy of the note I sent to the list
> a few days ago.  Criticisms / flames are welcome if I'm off-base.
> 
> Thanks for taking the time to look into this,
> -- David
> 
> 
> 
> 
> Some feedback on the MPPE draft:
> 
> The MPPE key derivation process uses a fixed prefix, 0xD1269E, to
> derive 40-bit RC4 session keys.
> 
> I find this use of a "magic number" very suspicious.  Where did
> this value come from?  Who picked it?  Why should we believe that
> it is not a trapdoor?  Was it randomly chosen, or does it have
> special properties?

Nobody knows where it came from.  It's been suggested that it was picked
out of thin air by someone who left the company a long time ago.  As far
as anyone knows there are no "special properties".

> 
> Most cryptographers (justifiably) have a widespread distrust of
> "magic numbers" like this, because there are examples where they
> can be used to secretly weaken a system.  Thus, most block cipher
> designs today explain how their S-boxes were chosen (e.g., the
> digits of pi, the contents of the Declaration of Independence,
> the SHA-hash of zero), so the reader can be sure that they were
> not chosen as a special backdoor.
> 
> I propose that, for an IETF standard such as PPP, either (1) the
> choice of this "magic number" must be clearly and thoroughly explained,
> or (2) the "magic number" must be eliminated from the standard.
> 

Actually, I'm not sure what the uproar is about (given the (relative)
ease of breaking 40-bit RC4).  At any rate, since the recent loosening of
export controls, I would think that the question is moot: if a customer is
concerned at all, they can use 128-bit keys.

> Just my opinion.  -- David Wagner, [email-masked]
>