[winswitch] Reworking Encryption in Xpra

[Antoine Martin]

On 11/01/2012 12:10 AM, Michael Vrable wrote:
> On Wed, Oct 31, 2012 at 01:48:32PM +0700, Antoine Martin wrote:
>> On 10/31/2012 12:50 PM, Michael Vrable wrote:
>>> Does the mailing list strip attachments?  I'm not sure it went 
>>> through, so here it is again inline.
>> It looks like it does, even though mailman's "Scrub attachments of 
>> regular delivery message?" is turned off..
> 
> I noticed later that my original message was flagged as spam by 
> mail.nagafix.co.uk for some reason, so perhaps that was related to the 
> attachment scrubbing?  The second message was not marked as spam.
I cannot find the first message at all anywhere, which is odd in itself.

One easy way to get around that is to attach the patches to the ticket
and just link to it - also makes it easier for me to read/apply.

>>> This assumes that both sides have run some type of key-agreement 
>>> protocol to establish a shared session secret.  I'm working on the 
>>> key exchange part in a separate patch which will follow.
>> Out of curiosity, what sort of key exchange are you interested in?
> 
> The code I'm working on currently simply does a basic Diffie-Hellman key 
> exchange with an HMAC to prevent a man-in-the-middle attack, but this 
> does leak information about the password to an active attacker.
> 
> After I get the basics working, I was considering implementing something 
> based on EAP-EKE since that is standardized.
It is, but it isn't very easy to implement, and there is little in
pycrypto to help you. Also, it seems to require a more complicated
handshake than just sending a value as with SPEKE..

> SPEKE is nice and simple, 
> but there might be patent issues (I haven't fully investigated) so that 
> might be worth avoiding.
I happen to live in countries with mostly sane IP laws, where
mathematics cannot be patented. For reference, here's the SPEKE
"innovation":
(((g**a)%p)**b)%p == (((g**b)%p)**a)%p

Making the code more difficult or complicated (and potentially also more
insecure) because of ludicrous IP laws in some countries is not
something I am very fond of..

>  In any case, it should be fairly easy to plug 
> in different mechanisms once I get the framework for it.
Let's hope so / try to make it so. Then those who live in lame IP
countries can change the build to disable whatever they need.

Cheers
Antoine

> 
>> (I may move the crypto import stuff to where it is used to allow one 
>> to build xpra without the crypto options - no biggie)
> 
> Good point, I'll do that to my patches here.
> 
> --Michael Vrable
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>