cryptoanarchy.wiki

Arise, you have nothing to lose but your barbed wire fences!

1998-06-02 - Re: Counterpane Cracks MS’s PPTP

Header Data

From: Brad Kemp <kemp@indusriver.com>
To: cypherpunks@toad.com
Message Hash: 7b9090c3cd19150b0fa7e7de7cacbc92e522489be57c87bbb89c17026b21bcd8
Message ID: <3.0.3.32.19980602090947.0317cc10@pop3.indusriver.com>
Reply To: <Version.32.19980601122218.00fbc410@pop.pipeline.com>
UTC Datetime: 1998-06-02 13:09:55 UTC
Raw Date: Tue, 2 Jun 1998 06:09:55 -0700 (PDT)

Raw message

From: Brad Kemp <kemp@indusriver.com>
Date: Tue, 2 Jun 1998 06:09:55 -0700 (PDT)
To: cypherpunks@toad.com
Subject: Re: Counterpane Cracks MS's PPTP
In-Reply-To: <Version.32.19980601122218.00fbc410@pop.pipeline.com>
Message-ID: <3.0.3.32.19980602090947.0317cc10@pop3.indusriver.com>
MIME-Version: 1.0
Content-Type: text/plain



This is a good paper. It covered almost all of the failures of MS PPTP.  
However, I think it missed a big one.
It is possible to recover all the clear text from a PPTP session,
even if most of the traffic is going in one direction only.
The failure is in MPPE.  When MPPE gets a sequenceing error, it
resets the key.  This causes the cipher stream to be reset.  It is
partially covered in section 5.4 .
Since RC4 is a stream cipher, it generates the same
cipher stream for a given key.  This cipher stream is XORed with the clear
text.
To recover the clear text, an attacker just needs to force a
resyncronization by
sending a packet that has a bogus coherency count.  
If the attacker captures the original stream and the resynchronized stream
a simple XOR of the two streams results in an XOR of the cleartext.
While compression does make it harder to determine what the cleartext is,
It is likely that a determined attacker can decrypt and decompress the
XORed result.  
Brad
Brad Kemp
Indus River Networks, Inc.                   BradKemp@indusriver.com
31 Nagog Park						 978-266-8122
Acton, MA 01720                              fax 978-266-8111

Thread