<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Christof Meerwald <cmeerw,AT,web,DOT,de>
Subject: Re: CIPE-Win32: communication breakdown
From: "Damion K. Wilson" <dwilson,AT,ibl,DOT,bm>
Date: Fri, 6 Jun 2003 14:39:13 -0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <20030606162410.GA1240@hacking.cmeerw.net>
References: <20030606162410.GA1240@hacking.cmeerw.net>
Reply-to: dwilson,AT,ibl,DOT,bm

I don't think that this approach is wrong, and it's intentionally written 
that 
way. If A says to B: "I'm changing my  key, here it is" and B never says: "I 
got it, go ahead" then there has been no successful key exchange so both A 
and B must try again.

I didn't know that CIPE invalidates the key before receipt of the NK_IND has 
been acknowledged by the peer. It the NK_ACK wasn't necessary, why have it at 
all ?

Olaf, if you're listening, do you have any guidance ?

DKW

On Friday 06 June 2003 01:24 pm, Christof Meerwald wrote:
> Hi,
>
> I experienced some random communication breakdowns when using a CIPE link
> between CIPE-Win32 and (Linux)-CIPE. I finally tracked it down to a bug in
> CIPE-Win32 where it doesn't correctly implement the CIPE protocol.
>
>   "The key negotiation procedure normally runs as follows: The sender sends
>   a NK_IND with the new key, then invalidates its own sending key."
>
> But CIPE-Win32 doesn't invalidate the sending key, instead it keeps using
> the previous sending key until it receives an NK_ACK. So in case the NK_ACK
> is lost, CIPE-Win32 still encrypts using the previous sending key, but the
> remote end already expects the new key.
>
> A simple fix is to add the following statement to
> CipeBlowfishEncryptor::GenerateDynamicKeyData(CipeEncryptionKeyType
> p_KeyType):
>
>     m_HaveKey [p_KeyType] = FALSE;
>
>
> bye, Christof


<< | Thread Index | >> ]    [ << | Date Index | >> ]