Everhart,Glenn
From:	Alan Ramsbottom [acr@als.co.uk]
Sent:	Sunday, April 26, 1998 1:19 PM
To:	ntsecurity@iss.net
Subject:	Re: [NTSEC] Is PPTP secure?

TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net
Contact ntsecurity-owner@iss.net for help with any problems!
---------------------------------------------------------------------------

On 19 Apr 98 at 15:33, Alan Ramsbottom wrote:

> Besides the origin/quality of the session encryption key, we still 
> have the implications of PPTP (or rather MPPE) using the same RC4 
> stream derived from that key in both directions - an issue mentioned 
> in the PPTP debate between Aleph One and Paul Leach on this list in 
> October(?) last year.
> 
> Did anyone ever explore, confirm or disprove this *apparent*
> vulnerability? 

Hmm.. it's a week later, so either everyone's secretly giggling behind
my back, no one uses PPTP, or no ones got a clue what I'm talking
about. Well, I'm stubbornly gonna try again, but please bear in mind
that I've verified NONE of the following discussion and I'm also going
for a conceptual approach that skips over more than a few of the
technical corners ..I hope none of those are relevant, but life's just
too short.

                            *******

Firstly a quick tour of RC4. For the sake of argument it's just like a
pseudo-random number generator i.e. give it a seed, kick it and it
churns out a stream of binary gobbledygook. Give RC4 the same seed
again, another kick and it churns out exactly the same stream. 

To encrypt stuff (plaintext), you simply XOR your data with the RC4 
stream and volia, you've got some ciphertext. To get the plaintext 
back again, you XOR the ciphertext with the original RC4 stream:

  Alice.txt XOR AlansRC4Stream = Alice.rc4

  Alice.rc4 XOR AlansRC4Stream = Alice.txt

We can also recover the RC4 stream:

  Alice.rc4 XOR Alice.txt = AlansRC4Stream

Course, I could use the *same* RC4 stream to also encrypt some other 
plaintext:

  Bob.txt XOR AlansRC4Stream = Bob.rc4

That might not be such a good idea though, because then:

  Alice.rc4 XOR Bob.rc4 = Alice.txt XOR Bob.txt

How useful is this? Well, it only works for the number of bytes in the 
smallest plaintext file and also depends on what Alice and Bob keep in 
their plaintext files.

Let's say Alice is an 3lite hacker and in her file she's got a copy of 
Armegeddon v.27 that she just downloaded from the NSA. Well, I say 
"she", but I suspect Alice is really a guy pretending to be a gal so 
they'll get more attention on mailing lists and the like. OTOH, Bob is 
an overworked net-admin who keeps a list of his social contacts in his 
file. 

Okay, I could use a good office lottery program so I'm gonna try and
recover Alice.txt. Well, I figure that Bob works way too much to have 
any friends, so even though Bob.txt mysteriously happens to be the 
biggest file, I figure it's just gotta be full of spaces. Assuming my 
suspicions about Bob are correct then:

  (Alice.rc4 XOR Bob.rc4) XOR Spaces.txt = Alice.txt

Woohoo! I'm gonna be rich!! ;-)

                       *******

Alright enough of the lame jokes ..back to PPTP. Allegedly, PPTP uses
the *same* RC4 stream to encrypt both outbound and inbound data. The
initial "seed" or key used to generate that stream is derived from a
user's credentials i.e. password hashes. Furthermore, after every
256(?) packets the key is changed (a function of the previous key?).

But in this discussion we don't care about the keys. Let's say the Bad
Guy can observe and capture all of the PPTP data passing through some
hostile territory between A and B. With a bit of work he'll end up
with two lumps of data that have been encrypted with the same RC4
stream(s):

  Outbound.rc4
  Inbound.rc4

In the real-world this is very unlikely to constitute anything close
to *all* the PPTP tunnelled traffic i.e. it will depend on things like
the size of the packets and the number that are flowing in each
direction, key changes etc. Still, if Outbound.txt and Inbound.txt are
the "raw" un-encrypted packets then in principle:

  (Outbound.rc4  XOR Inbound.rc4) XOR Oubound.txt  = Inbound.txt

In other words if we have knowledge of, or can predict some part of the 
data headed in one direction, then we should be able to recover an 
equal amount of data that was travelling the other way.

How big a problem is this? Well, I'm currently tempted to think this
ISN'T such a big problem because AFAIK, PPTP encrypts *complete* PPP
packets so there'll be no really useful things exposed e.g. the IP
headers for any tunnelled IP packets. Further, I believe PPTP applies
LZ(?) compression to a PPP packet before the RC4 encryption and I
guess that might complicate recovery of the plaintext a little.

But I don't know ..I certainly wasn't the first to remark on this
*potential* problem and furthermore I really wouldn't care to nail my
flag to *any* of it. Nonetheless, it does seem like another reason to
be a little uneasy about the use of PPTP and is an issue I haven't
seen discussed in any great detail. Hence my original question to be
found way back at the top of this post..

..which of course still stands. So, has anyone got any comments about 
this whole thing?

--Alan--
acr@als.co.uk