[Monotone-devel] Re: netsync transport encryption?

[Cem Karan]

> Message: 4
> Date: Wed, 25 Oct 2006 14:28:48 +0200 (CEST)
> From: Richard Levitte - VMS Whacker <address@hidden>
> Subject: Re: [Monotone-devel] netsync transport encryption?
> To: address@hidden
> Message-ID: <address@hidden>
> Content-Type: Text/Plain; charset=us-ascii
>
> ckaran> Here is my suggestion for what to do:
> ckaran>
> ckaran> 1) The initiating side generates a random session key,
> ckaran>    encrypts it with the receiving sides public key, and sends
> ckaran>    it on to the receiving side.
> ckaran> 2) The receiving side does exactly the same thing back.  This
> ckaran>    solves the really weird race condition where both sides
> ckaran>    want to initiate communications at the same time.
>
> Do we have the race condition problem?  SSH and SSL works by having a
> common session key for both directions of the communication, but your
> idea should work.

Just as a preface, note that I just downloaded the sources yesterday,  
so my understanding of Monotone's internals is necessarily weak.   
Some of what I say may not apply.

The race condition I'm talking about is one where we end up with two  
full duplex connections in tandem.  Imagine Alice and Bob decide they  
want to sync with each other, and happen to initiate their  
connections at the exact same moment.  If both connections go  
through, then Monotone is going to have to synchronize those  
connections somehow, to ensure that multiple commands aren't sent  
back and forth that cause some kind of corruption.  This would be  
vaguely like two threads accessing shared data without mutexes.   
Monotone could protect against this by killing one of the  
connections, but that would require some decision logic, that,  
depending on how its done, might result in both ends being killed  
off, and having to restart communications.

Half-duplex would work, but if I understand the netsync protocol  
correctly, its supposed to be asynchronous, right?  Half-duplex would  
force some level of synchronization...

However, by having two simplex connections, you never have the  
problem of the race conditions, and you have asynchronous connections.

Although... I just realized one serious drawback; firewalls.  If  
Alice is behind the a corporate firewall, she may be able to punch  
out to Bob easily, but he may not be able to connect back.... maybe  
something involving full duplex is going to be necessary after all.   
Monotone would just need to know how to ensure that any two hosts  
that connect simultaneously always do the right thing...

> ckaran> 3) [...] I'm suggesting compression because of what Brue
> ckaran>    Schneier says about how it make cryptanalysis harder, and
> ckaran>    makes encryption/decryption faster.  If Monotone already
> ckaran>    does a good job of compressing its data, then this isn't as
> ckaran>    necessary (this would require testing to see what works
> ckaran>    faster/better).
>
> Monotone already compresses most of the payload.  Cryptoanalysis is
> otherwise commonly made harder with CBC mode or similar (there are
> more complex modes).

Anything that works is fine by me.  I was just pointing out that  
Botan already has this.

Thanks,
Cem Karan