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

From: Vernon Schryver <[email-masked]>
Date: Fri, 8 Oct 1999 20:48:10 -0600 (MDT)

> From: David Wagner <[email-masked]>

> On the contrary, my preliminary statistical tests show two "special properties"
> for the class of RC4 keys starting with prefix 0xD1269E:
>
>   * The first byte of output takes on the value 0x09 with prob. 0.0054,
>     which is noticeably higher than the 1/256 = 0.0039 probability you
>     get for a secure cipher (or for RC4 with a random prefix).
>
>   * The RC4 key schedule mixes some entries in the state table poorly,
>     for this class of keys.  For instance, S[1] = 0xF8 holds with prob.
>     1/e = 0.38, and S[2] = 0x98 holds with a similarly large probability.
>
> Neither of these seem directly usable in any practical attack on the cipher.
> Still, I find them suspicious, and perhaps indicative of more subtle flaws.
>
> It is these special properties of the 0xD1269E prefix which raises a red flag
> in my mind.

That's interesting in an academic sense.  (Not pejoratively "academic,"
since such "special properties" of major cyphers like RC4 are important.)
(I assume the implication that RC4 with reasonably sized keys is insecure
in the phrase "for a secure cipher (or for RC4" was not intended.)

However, what about Greg Zorn's overriding point?  How can it be of more
than historical, sociological, or political interest whether someone at
Microsoft chose especially weak 40-bit keys for MPPE, instead of someone's
birthday or the next value from some random process?  In both theory and
in practical demonstrations, 40-bit RC4 has such poor security that it is
almost a joke.  Isn't the expected time to brute-force 40-bit RC4 less
than a dozen hours if you have a gross or two of mid-1990's workstations,
and only a week or two if you're limited to a single machine?  Given the
increase in CPU clock speeds for small cheap, computers since the 40-bit
RC4 brute forcing excitement of 1996, or Deepcrack, it seems safe to assume
that anyone who really cares about cracking 40-bit RC4 keys doesn't care
what prefix might be used and can crack 40-bit RC4 key in real time.
Deepcrack breaks 56-bit DES in 56 hours.  An RC4-Deepcrack version as fast
could break 40-bit RC4 in 36 hours/256=10 minutes.  With a couple dozen
RC4-Deepcracks you could break any 40-bit RC4 session key quickly enough
to modify packets as they fly by, regardless of any special properties of
the non-key bits.

Let's assume that the prefix makes cracking 40-bit RC4 100 times quicker
for those who know the secret, and forget about it here where network
technical instead of cryptoanalytic, historical, political, commercial
and other issues are paramount.  The sci.crypt newsgroup might be an
appropriate forum.

Vernon Schryver    [email-masked]

---

From: David Wagner <[email-masked]>
Date: Mon, 11 Oct 1999 06:52:24 +0000 ()

Vernon Schryver <[email-masked]> wrote:
> almost a joke. [..]

As others have noted, the 40-bit keylength is just short enough that
targeted keysearch attacks are trivial, but just long enough that
indiscriminate large-scale traffic decryption is rendered quite a bit
more painful than some would probably like.  Thus, anything that can
help reduce the cost of exhaustive keysearch, even by a constant
factor, is going to be of great interest to large-scale eavesdroppers.

If the special prefix makes cracking 40-bit keys 100x easier, that
will make a huge difference to anyone involved in vacuum-cleaner-style
interception of PPTP traffic, and might just tip the scales in the
favor of making such large-scale attacks practical.  Surely this
can't be a desired feature of the protocol!

If you mean that security issues aren't appropriate for this forum,
then I agree that this is off-topic.  I don't mean to be a pest,
but I do believe that security was a stated goal of the drafts under
consideration.

(I have specifically avoided discussing any historical, sociological,
political, or commercial issues, so I don't know why you brought it up.)

Maybe I'm naive, but if there's a security flaw -- or a credible
possibility of a security flaw -- in the protocol, shouldn't it be
fixed with all due speed?

---

From: Glen Zorn <[email-masked]>
Date: Tue, 12 Oct 1999 16:06:21 -0700 (PDT)

> can't be a desired feature of the protocol!

I think you're missing the point:  40-bit RC4 is obsolete, don't use it!

> but I do believe that security was a stated goal of the drafts under

Security issues are certainly appropriate for this forum.  However, the
draft in question is informational, not standards-track (as I believe
others have pointed out).  To be completely blunt, MPPE is a proprietary
Microsoft protocol and the purpose of the document is _only_ to provide
information on how it works, so that other vendors can implement if
they want to.  No technical comments are solicited, only comments on
clarity, understandability, etc.  If you can't understand the document
well enough to implement it, I want to hear about that; if you just think
it sucks, I don't care.  Note that if this _was_ a standards-track
document, it would be a completely different story: any and all technical
comments would be welcome.

> Maybe I'm naive, 

Maybe.

> but if there's a security flaw -- or a credible

Just to level-check, are you seriously suggesting that I tell my boss that
we need to force the update of a couple hundred million PCs because the
'preliminary analysis' of a (no offense intended) Berkeley grad student
makes him 'nervous'?