From vlad.star at gmail.com  Tue Mar  2 08:44:05 2010
From: vlad.star at gmail.com (Vladimir)
Date: Tue, 02 Mar 2010 13:44:05 +0000
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
Message-ID: <4B8D1625.3090500@gmail.com>

Hello,

I'm currently using fingerprints to identify clients using my 
application on their mobile phones. The application uses J2ME. I am 
interested in using SMP but I doubt it will be possible because of the 
computationally intense calculations (power in particular). The example 
in the documentation talks about its uses on a BlackBerry, but the aim 
of my software is to be used on less powerful devices too. What effects 
on performance will SMP have on a less powerful processor?

Thanks,
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100302/26c65426/attachment.htm>

From louis.granboulan.developer at gmail.com  Tue Mar  2 12:10:21 2010
From: louis.granboulan.developer at gmail.com (Louis Granboulan)
Date: Tue, 2 Mar 2010 18:10:21 +0100
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <20100219123131.GL8930@yoink.cs.uwaterloo.ca>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
Message-ID: <7da5e7281003020910md89b5bak429f96c2b718b488@mail.gmail.com>

I did not know that OTR could do authentication using a shared secret,
because I see it in http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html

Anyway, password-based authentication is different of shared-key
authentication, because it uses a password of small entropy. The idea is
that enumerating all possible passwords is not feasible on-line, and the
protocol protects against off-line attacks.

Louis

On 19 February 2010 13:31, Ian Goldberg <ian at cypherpunks.ca> wrote:

> On Thu, Feb 18, 2010 at 06:42:33PM +0100, Louis Granboulan wrote:
> > Dear all,
> >
> > I would like to add to an instant messenging framework an end-to-end
> > password-based security layer. Therefore, instead of relying on a
> accepting
> > a public key like OTR, the authentication would rely on a shared password
> > (cf. http://en.wikipedia.org/wiki/Password-authenticated_key_agreement )
> > It appears that instead of re-doing everything from scratch, a better way
> > might be to add this possibility to the already existing OTR framework.
> >
> > However, this would imply some important changes to the OTR library, by
> > adding a non-OTR protocol, and I would like to know if these changes can
> go
> > mainstream when the implementation would be stable.
> > Moreover, I would like to extend the PAKE security to group PAKE if the
> > encryption is started within a multi-user group chat. I did not see any
> > discussion on how to interface the OTR library with group chat.
>
> OTR already has a mechanism for authenticating with a shared secret.
> Can you describe the advantages of your proposal over that?
>
> As for group chat, it's work in progress.  We had a paper a few months
> ago in ACM CCS describing a protocol for it, but quite a bit more work
> still needs to be done.
>
>   - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100302/58f50930/attachment.html>

From ian at cypherpunks.ca  Tue Mar  2 12:11:44 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 2 Mar 2010 12:11:44 -0500
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <4B8D1625.3090500@gmail.com>
References: <4B8D1625.3090500@gmail.com>
Message-ID: <20100302171144.GL22949@thunk.cs.uwaterloo.ca>

On Tue, Mar 02, 2010 at 01:44:05PM +0000, Vladimir wrote:
> Hello,
>
> I'm currently using fingerprints to identify clients using my  
> application on their mobile phones. The application uses J2ME.

Cool; which application is this?

> I am  interested in using SMP but I doubt it will be possible because
> of the  computationally intense calculations (power in particular).
> The example  in the documentation talks about its uses on a
> BlackBerry, but the aim  of my software is to be used on less powerful
> devices too. What effects  on performance will SMP have on a less
> powerful processor?

In regular OTR conversation, 2 modexps (the expensive operation) are
done every time one of the parties creates a new temporary encryption
key, which is generally done approximately every message.

In SMP, each side does about 9 modexps, but only once per person you
talk to.  So I'd say SMP should take way less power than the rest of the
conversation.

   - Ian

From ian at cypherpunks.ca  Tue Mar  2 12:18:12 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 2 Mar 2010 12:18:12 -0500
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <7da5e7281003020910md89b5bak429f96c2b718b488@mail.gmail.com>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003020910md89b5bak429f96c2b718b488@mail.gmail.com>
Message-ID: <20100302171812.GM22949@thunk.cs.uwaterloo.ca>

On Tue, Mar 02, 2010 at 06:10:21PM +0100, Louis Granboulan wrote:
> I did not know that OTR could do authentication using a shared secret,
> because I see it in http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html

See http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html (the current
version).  It's the "Socialist Millionaires' Protocol" (SMP).

> Anyway, password-based authentication is different of shared-key
> authentication, because it uses a password of small entropy. The idea is
> that enumerating all possible passwords is not feasible on-line, and the
> protocol protects against off-line attacks.

OTR's shared secret authentication indeed protects against offline
attacks.  The SMP yields a joint computation of w^{x-y} (mod a big
prime), where x and y are the parties' secrets, and w is a random number
known to nobody.  If x = y, this equals 1, and if x \not= y, this is a
random number which leaks no information about x or y, even if you know
the other one.  It's meant to be used exactly in the low-entropy
scenario.

   - Ian

From vlad.star at gmail.com  Tue Mar  2 13:08:25 2010
From: vlad.star at gmail.com (Vladimir)
Date: Tue, 02 Mar 2010 18:08:25 +0000
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <20100302171144.GL22949@thunk.cs.uwaterloo.ca>
References: <4B8D1625.3090500@gmail.com>
	<20100302171144.GL22949@thunk.cs.uwaterloo.ca>
Message-ID: <4B8D5419.4070604@gmail.com>

On 02/03/2010 17:11, Ian Goldberg wrote:
> On Tue, Mar 02, 2010 at 01:44:05PM +0000, Vladimir wrote:
>> Hello,
>>
>> I'm currently using fingerprints to identify clients using my
>> application on their mobile phones. The application uses J2ME.
> Cool; which application is this?
>
>> I am  interested in using SMP but I doubt it will be possible because
>> of the  computationally intense calculations (power in particular).
>> The example  in the documentation talks about its uses on a
>> BlackBerry, but the aim  of my software is to be used on less powerful
>> devices too. What effects  on performance will SMP have on a less
>> powerful processor?
> In regular OTR conversation, 2 modexps (the expensive operation) are
> done every time one of the parties creates a new temporary encryption
> key, which is generally done approximately every message.
My protocol is different from OTR in that respect. It uses public key 
encryption to exchange a symmetric key, which is used for the duration 
of the conversation. Both clients (A and B) have to generate a pair for 
every application startup. If A wants to speak to B, then A encrypts a 
freshly generated symmetric key using B's public key. Along with the 
encrypted symmetric key, A sends a hash fingerprint of both public keys 
to B. Then A and B have to contact each other to confirm the 
fingerprint. By confirming the fingerprint, we know that no MITM attack 
has taken place, since the keys used for encrypting them are the correct 
ones. In a way A says "I encrypted the symmetric key using this public 
key, is that ok?".
> In SMP, each side does about 9 modexps, but only once per person you
> talk to.  So I'd say SMP should take way less power than the rest of the
> conversation.
I'm not familiar with the modexps measurements but it seems to me that 
using 1536-bit primes is still more than generating a single RSA 
key-pair, which is enough of a burden right now. Please correct me if 
I'm wrong.

The application is not released yet, it is a project I'm working on at 
the moment for my dissertation. I'm glad to see interest in it.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100302/7d13d119/attachment.htm>

From ian at cypherpunks.ca  Tue Mar  2 13:46:37 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 2 Mar 2010 13:46:37 -0500
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <4B8D5419.4070604@gmail.com>
References: <4B8D1625.3090500@gmail.com>
	<20100302171144.GL22949@thunk.cs.uwaterloo.ca>
	<4B8D5419.4070604@gmail.com>
Message-ID: <20100302184637.GP22949@thunk.cs.uwaterloo.ca>

On Tue, Mar 02, 2010 at 06:08:25PM +0000, Vladimir wrote:
> On 02/03/2010 17:11, Ian Goldberg wrote:
>> On Tue, Mar 02, 2010 at 01:44:05PM +0000, Vladimir wrote:
>>> Hello,
>>>
>>> I'm currently using fingerprints to identify clients using my
>>> application on their mobile phones. The application uses J2ME.
>> Cool; which application is this?
>>
>>> I am  interested in using SMP but I doubt it will be possible because
>>> of the  computationally intense calculations (power in particular).
>>> The example  in the documentation talks about its uses on a
>>> BlackBerry, but the aim  of my software is to be used on less powerful
>>> devices too. What effects  on performance will SMP have on a less
>>> powerful processor?
>> In regular OTR conversation, 2 modexps (the expensive operation) are
>> done every time one of the parties creates a new temporary encryption
>> key, which is generally done approximately every message.
> My protocol is different from OTR in that respect. It uses public key  
> encryption to exchange a symmetric key, which is used for the duration  
> of the conversation. Both clients (A and B) have to generate a pair for  
> every application startup. If A wants to speak to B, then A encrypts a  
> freshly generated symmetric key using B's public key.

So no forward secrecy, then?  If B's private key is compromised at any
time in the future, all past messages to B are retroactively revealed?

> Along with the  encrypted symmetric key, A sends a hash fingerprint of
> both public keys  to B.

Why send the hash, if you're going to compare it offline anyway?  The
MITM can easily replace the hash with a hash of his own key and Bob's.

> Then A and B have to contact each other to confirm the  
> fingerprint. By confirming the fingerprint, we know that no MITM attack  
> has taken place, since the keys used for encrypting them are the correct  
> ones. In a way A says "I encrypted the symmetric key using this public  
> key, is that ok?".

Right.  If only you could get users to actually contact each other
out-of-band to confirm hashes.  :-)

>> In SMP, each side does about 9 modexps, but only once per person you
>> talk to.  So I'd say SMP should take way less power than the rest of the
>> conversation.
> I'm not familiar with the modexps measurements but it seems to me that  
> using 1536-bit primes is still more than generating a single RSA  
> key-pair, which is enough of a burden right now. Please correct me if  
> I'm wrong.

Hmm?  Generating an RSA key pair is much more expensive than a modexp.
I just did a quick timing test on my desktop machine.  A 1536-bit RSA
key generation takes between 300 and 900 ms.  A 1536-bit modexp takes
less than 4 ms.

If RSA key gen is a burden, why aren't you using a DH-based system,
where the keygen is super-cheap (one modexp)?

   - Ian

From vlad.star at gmail.com  Tue Mar  2 16:39:31 2010
From: vlad.star at gmail.com (Vladimir)
Date: Tue, 02 Mar 2010 21:39:31 +0000
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <20100302184637.GP22949@thunk.cs.uwaterloo.ca>
References: <4B8D1625.3090500@gmail.com>	<20100302171144.GL22949@thunk.cs.uwaterloo.ca>	<4B8D5419.4070604@gmail.com>
	<20100302184637.GP22949@thunk.cs.uwaterloo.ca>
Message-ID: <4B8D8593.2050004@gmail.com>

On 02/03/2010 18:46, Ian Goldberg wrote:
> On Tue, Mar 02, 2010 at 06:08:25PM +0000, Vladimir wrote:
>    
>> On 02/03/2010 17:11, Ian Goldberg wrote:
>>      
>>> On Tue, Mar 02, 2010 at 01:44:05PM +0000, Vladimir wrote:
>>>        
>>>> Hello,
>>>>
>>>> I'm currently using fingerprints to identify clients using my
>>>> application on their mobile phones. The application uses J2ME.
>>>>          
>>> Cool; which application is this?
>>>
>>>        
>>>> I am  interested in using SMP but I doubt it will be possible because
>>>> of the  computationally intense calculations (power in particular).
>>>> The example  in the documentation talks about its uses on a
>>>> BlackBerry, but the aim  of my software is to be used on less powerful
>>>> devices too. What effects  on performance will SMP have on a less
>>>> powerful processor?
>>>>          
>>> In regular OTR conversation, 2 modexps (the expensive operation) are
>>> done every time one of the parties creates a new temporary encryption
>>> key, which is generally done approximately every message.
>>>        
>> My protocol is different from OTR in that respect. It uses public key
>> encryption to exchange a symmetric key, which is used for the duration
>> of the conversation. Both clients (A and B) have to generate a pair for
>> every application startup. If A wants to speak to B, then A encrypts a
>> freshly generated symmetric key using B's public key.
>>      
> So no forward secrecy, then?  If B's private key is compromised at any
> time in the future, all past messages to B are retroactively revealed?
>    
B's private key will not exist once the application is shut down/restarted.
>    
>> Along with the  encrypted symmetric key, A sends a hash fingerprint of
>> both public keys  to B.
>>      
> Why send the hash, if you're going to compare it offline anyway?  The
> MITM can easily replace the hash with a hash of his own key and Bob's.
>    
If MITM replaces the hash, then A and B will know about it during the 
fingerprint (hash) verification.
>    
>> Then A and B have to contact each other to confirm the
>> fingerprint. By confirming the fingerprint, we know that no MITM attack
>> has taken place, since the keys used for encrypting them are the correct
>> ones. In a way A says "I encrypted the symmetric key using this public
>> key, is that ok?".
>>      
> Right.  If only you could get users to actually contact each other
> out-of-band to confirm hashes.  :-)
>    
Yes that is why I am so interested in SMP. :-)
>    
>>> In SMP, each side does about 9 modexps, but only once per person you
>>> talk to.  So I'd say SMP should take way less power than the rest of the
>>> conversation.
>>>        
>> I'm not familiar with the modexps measurements but it seems to me that
>> using 1536-bit primes is still more than generating a single RSA
>> key-pair, which is enough of a burden right now. Please correct me if
>> I'm wrong.
>>      
> Hmm?  Generating an RSA key pair is much more expensive than a modexp.
> I just did a quick timing test on my desktop machine.  A 1536-bit RSA
> key generation takes between 300 and 900 ms.  A 1536-bit modexp takes
> less than 4 ms.
>
> If RSA key gen is a burden, why aren't you using a DH-based system,
> where the keygen is super-cheap (one modexp)?
>    
I always thought D-H is more computationally expensive. I need to check 
my sources :) thanks for pointing this out.

Regards,
Vladimir

From paul at cypherpunks.ca  Tue Mar  2 18:37:21 2010
From: paul at cypherpunks.ca (Paul Wouters)
Date: Tue, 2 Mar 2010 18:37:21 -0500 (EST)
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <20100302171812.GM22949@thunk.cs.uwaterloo.ca>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003020910md89b5bak429f96c2b718b488@mail.gmail.com>
	<20100302171812.GM22949@thunk.cs.uwaterloo.ca>
Message-ID: <alpine.LFD.1.10.1003021836430.32519@newtla.xelerance.com>

On Tue, 2 Mar 2010, Ian Goldberg wrote:

> See http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html (the current
> version).  It's the "Socialist Millionaires' Protocol" (SMP).

> OTR's shared secret authentication indeed protects against offline
> attacks.  The SMP yields a joint computation of w^{x-y} (mod a big
> prime), where x and y are the parties' secrets, and w is a random number
> known to nobody.  If x = y, this equals 1, and if x \not= y, this is a
> random number which leaks no information about x or y, even if you know
> the other one.  It's meant to be used exactly in the low-entropy
> scenario.

Anyone knows why Adium still does not support that?

Paul

From ian at cypherpunks.ca  Tue Mar  2 19:37:44 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 2 Mar 2010 19:37:44 -0500
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <4B8D8593.2050004@gmail.com>
References: <4B8D1625.3090500@gmail.com>
	<20100302171144.GL22949@thunk.cs.uwaterloo.ca>
	<4B8D5419.4070604@gmail.com>
	<20100302184637.GP22949@thunk.cs.uwaterloo.ca>
	<4B8D8593.2050004@gmail.com>
Message-ID: <20100303003744.GA8717@yoink.cs.uwaterloo.ca>

On Tue, Mar 02, 2010 at 09:39:31PM +0000, Vladimir wrote:
>> So no forward secrecy, then?  If B's private key is compromised at any
>> time in the future, all past messages to B are retroactively revealed?
>>    
> B's private key will not exist once the application is shut down/restarted.

Ah, so you have to do the out-of-band check *every time* you talk.  Why
don't you use long-term authentication keys?

>>> Along with the  encrypted symmetric key, A sends a hash fingerprint of
>>> both public keys  to B.
>>>      
>> Why send the hash, if you're going to compare it offline anyway?  The
>> MITM can easily replace the hash with a hash of his own key and Bob's.
>>    
> If MITM replaces the hash, then A and B will know about it during the  
> fingerprint (hash) verification.

Exactly.  So why send the hash at all?  Each side can separately compute
the hash without it being sent, and they'll compare the results
out-of-band.

>>> Then A and B have to contact each other to confirm the
>>> fingerprint. By confirming the fingerprint, we know that no MITM attack
>>> has taken place, since the keys used for encrypting them are the correct
>>> ones. In a way A says "I encrypted the symmetric key using this public
>>> key, is that ok?".
>>>      
>> Right.  If only you could get users to actually contact each other
>> out-of-band to confirm hashes.  :-)
>>    
> Yes that is why I am so interested in SMP. :-)

I doubt even SMP would be used if you had to run it every time you
talked.

> I always thought D-H is more computationally expensive. I need to check  
> my sources :) thanks for pointing this out.

D-H is more computationally expensive than an RSA encryption (with a
small e), but somewhat less expensive in decryption (with ~256-bit
exponents) and *way less* expensive in key generation.

   - Ian

From louis.granboulan.developer at gmail.com  Wed Mar 10 10:02:09 2010
From: louis.granboulan.developer at gmail.com (Louis Granboulan)
Date: Wed, 10 Mar 2010 16:02:09 +0100
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <20100219123131.GL8930@yoink.cs.uwaterloo.ca>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
Message-ID: <7da5e7281003100702q7a9c5ac1ub896c3b3e74751e7@mail.gmail.com>

Ian Goldberg answers:

> OTR already has a mechanism for authenticating with a shared secret.
> See http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html (the current
> version).  It's the "Socialist Millionaires' Protocol" (SMP).
>

OK. I did not look at the lastest version of OTR.

Can you describe the advantages of your proposal over that?
>

I am not sure that there is a true advantage in practice, but for example
EKE is less computationally intensive that OTR+SMP. Not using long-term
public keys has some advantages in terms of efficiency.


> As for group chat, it's work in progress.  We had a paper a few months
> ago in ACM CCS describing a protocol for it, but quite a bit more work
> still needs to be done.
>

I guess that you refer to http://www.cs.uwaterloo.ca/~iang/pubs/mpotr.pdf
I would not be as strict on the authentication as you appear to be.
For group chat, I would not require one-to-one authentication, but simply
that every participant has proved that he knows the shared password. It
would be the digital world version of a meeting of a secret society, where
one has to prove membership, but not identity.

-- 
Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100310/06190700/attachment.html>

From louis.granboulan.developer at gmail.com  Wed Mar 10 10:31:11 2010
From: louis.granboulan.developer at gmail.com (Louis Granboulan)
Date: Wed, 10 Mar 2010 16:31:11 +0100
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <alpine.LFD.1.10.1003021836430.32519@newtla.xelerance.com>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003020910md89b5bak429f96c2b718b488@mail.gmail.com>
	<20100302171812.GM22949@thunk.cs.uwaterloo.ca>
	<alpine.LFD.1.10.1003021836430.32519@newtla.xelerance.com>
Message-ID: <7da5e7281003100731v700c15aay824428da40dadb1c@mail.gmail.com>

On 3 March 2010 00:37, Paul Wouters <paul at cypherpunks.ca> wrote:

> Anyone knows why Adium still does not support that?


I found the answer to that question.
http://trac.adium.im/ticket/9768

The work is stalled since 18 months.

-- 
Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100310/faa08776/attachment.htm>

From ian at cypherpunks.ca  Fri Mar 12 08:17:44 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 12 Mar 2010 08:17:44 -0500
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <7da5e7281003100702q7a9c5ac1ub896c3b3e74751e7@mail.gmail.com>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003100702q7a9c5ac1ub896c3b3e74751e7@mail.gmail.com>
Message-ID: <20100312131744.GB19789@thunk.cs.uwaterloo.ca>

On Wed, Mar 10, 2010 at 04:02:09PM +0100, Louis Granboulan wrote:
> Ian Goldberg answers:
> 
> > OTR already has a mechanism for authenticating with a shared secret.
> > See http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html (the current
> > version).  It's the "Socialist Millionaires' Protocol" (SMP).
> >
> 
> OK. I did not look at the lastest version of OTR.
> 
> Can you describe the advantages of your proposal over that?
> >
> 
> I am not sure that there is a true advantage in practice, but for example
> EKE is less computationally intensive that OTR+SMP. Not using long-term
> public keys has some advantages in terms of efficiency.

If you don't have long-term public keys, won't you have to authenticate
*every time* you talk to someone?  OTR+SMP binds your shared knowledge
to your long-term fingerprint, so that you don't have to do it every
time.

> > As for group chat, it's work in progress.  We had a paper a few months
> > ago in ACM CCS describing a protocol for it, but quite a bit more work
> > still needs to be done.
> >
> 
> I guess that you refer to http://www.cs.uwaterloo.ca/~iang/pubs/mpotr.pdf

That's right.

> I would not be as strict on the authentication as you appear to be.
> For group chat, I would not require one-to-one authentication, but simply
> that every participant has proved that he knows the shared password. It
> would be the digital world version of a meeting of a secret society, where
> one has to prove membership, but not identity.

But secret society meetings aren't held in dark rooms, where you can't
even see who's speaking.  (And even if some crazy ones are, that's not
the model most people have in mind for "secure chat room"; imagine the
UI: it would have to show what people are saying, but not who's saying
it.  I can't imagine that's what people are looking for.)  *Within* the
private chat room, there's value in being able to have secure and
authenticated communications.  The challenge is in ensuring that
participants end up with proof about who said what, but that proof is
not transferrable (even by a corrupted participant) to outside parties.
Two-party OTR does this with a simple MAC, but for more than two people,
it's quite a bit more complicated.

   - Ian

From vlad.star at gmail.com  Fri Mar 12 09:26:28 2010
From: vlad.star at gmail.com (Vladimir)
Date: Fri, 12 Mar 2010 14:26:28 +0000
Subject: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
In-Reply-To: <20100303003744.GA8717@yoink.cs.uwaterloo.ca>
References: <4B8D1625.3090500@gmail.com>	<20100302171144.GL22949@thunk.cs.uwaterloo.ca>	<4B8D5419.4070604@gmail.com>	<20100302184637.GP22949@thunk.cs.uwaterloo.ca>	<4B8D8593.2050004@gmail.com>
	<20100303003744.GA8717@yoink.cs.uwaterloo.ca>
Message-ID: <4B9A4F14.2020603@gmail.com>

On 03/03/2010 00:37, Ian Goldberg wrote:
> On Tue, Mar 02, 2010 at 09:39:31PM +0000, Vladimir wrote:
>    
>>> So no forward secrecy, then?  If B's private key is compromised at any
>>> time in the future, all past messages to B are retroactively revealed?
>>>
>>>        
>> B's private key will not exist once the application is shut down/restarted.
>>      
> Ah, so you have to do the out-of-band check *every time* you talk.  Why
> don't you use long-term authentication keys?
>
>    
>>>> Along with the  encrypted symmetric key, A sends a hash fingerprint of
>>>> both public keys  to B.
>>>>
>>>>          
>>> Why send the hash, if you're going to compare it offline anyway?  The
>>> MITM can easily replace the hash with a hash of his own key and Bob's.
>>>
>>>        
>> If MITM replaces the hash, then A and B will know about it during the
>> fingerprint (hash) verification.
>>      
> Exactly.  So why send the hash at all?  Each side can separately compute
> the hash without it being sent, and they'll compare the results
> out-of-band.
>    
Thanks for pointing this out for me. I have adjusted the protocol 
accordingly.
>    
>>>> Then A and B have to contact each other to confirm the
>>>> fingerprint. By confirming the fingerprint, we know that no MITM attack
>>>> has taken place, since the keys used for encrypting them are the correct
>>>> ones. In a way A says "I encrypted the symmetric key using this public
>>>> key, is that ok?".
>>>>
>>>>          
>>> Right.  If only you could get users to actually contact each other
>>> out-of-band to confirm hashes.  :-)
>>>
>>>        
>> Yes that is why I am so interested in SMP. :-)
>>      
> I doubt even SMP would be used if you had to run it every time you
> talked.
>    
The keys are now stored on the client's device, but I'm still using 
out-of-band fingerprint comparison. SMP did sound like the best choice 
but the time for the project has run out and it won't be included.
>    
>> I always thought D-H is more computationally expensive. I need to check
>> my sources :) thanks for pointing this out.
>>      
> D-H is more computationally expensive than an RSA encryption (with a
> small e), but somewhat less expensive in decryption (with ~256-bit
> exponents) and *way less* expensive in key generation.
>    
Thanks for the help Ian.
>     - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>    


From louis.granboulan.developer at gmail.com  Wed Mar 17 08:24:08 2010
From: louis.granboulan.developer at gmail.com (Louis Granboulan)
Date: Wed, 17 Mar 2010 13:24:08 +0100
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <20100312131744.GB19789@thunk.cs.uwaterloo.ca>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003100702q7a9c5ac1ub896c3b3e74751e7@mail.gmail.com>
	<20100312131744.GB19789@thunk.cs.uwaterloo.ca>
Message-ID: <7da5e7281003170524m5ae9e6deu24d59ef0a2713b3a@mail.gmail.com>

On 12 March 2010 14:17, Ian Goldberg <ian at cypherpunks.ca> wrote:

> If you don't have long-term public keys, won't you have to authenticate
> *every time* you talk to someone?  OTR+SMP binds your shared knowledge
> to your long-term fingerprint, so that you don't have to do it every
> time.
>

If the PAKE is used to generate a long-term shared secret key that will be
memorized, then you don't need to re-authenticate to the same partner. With
OTR+SMP, you need to memorize your secret key and one public-key per
partner; with this option, you need to memorize one secret key per partner,
which has the slight drawback of needing a larger trusted memory to store
this nformation.

But secret society meetings aren't held in dark rooms, where you can't
> even see who's speaking.  (And even if some crazy ones are, that's not
> the model most people have in mind for "secure chat room"; imagine the
> UI: it would have to show what people are saying, but not who's saying
> it.  I can't imagine that's what people are looking for.)  *Within* the
> private chat room, there's value in being able to have secure and
> authenticated communications.


There are two different things that the autentication can prove: the right
to be a participant to the chat room, or the identity. They need different
trust models.
I would clearly accept that in a private chat room I don't know personally
everyone, and therefore not everyone is issuing authenticated communications
(from my point of view). However, I want that everyone that participate to
the chat room has the right to know what is told in there.
I don't put the emphasis on the authentication of the sender of messages,
but on the authentication of the receiver.

Louis

PS: by the way, thank you for this interesting discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20100317/7b6d6e78/attachment.html>

From ian at cypherpunks.ca  Wed Mar 17 08:59:17 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 17 Mar 2010 08:59:17 -0400
Subject: [OTR-dev] OTR using PAKE and for group chat
In-Reply-To: <7da5e7281003170524m5ae9e6deu24d59ef0a2713b3a@mail.gmail.com>
References: <7da5e7281002180942j769f1c23hb672bf45b514696e@mail.gmail.com>
	<20100219123131.GL8930@yoink.cs.uwaterloo.ca>
	<7da5e7281003100702q7a9c5ac1ub896c3b3e74751e7@mail.gmail.com>
	<20100312131744.GB19789@thunk.cs.uwaterloo.ca>
	<7da5e7281003170524m5ae9e6deu24d59ef0a2713b3a@mail.gmail.com>
Message-ID: <20100317125917.GF2423@thunk.cs.uwaterloo.ca>

On Wed, Mar 17, 2010 at 01:24:08PM +0100, Louis Granboulan wrote:
> On 12 March 2010 14:17, Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > If you don't have long-term public keys, won't you have to authenticate
> > *every time* you talk to someone?  OTR+SMP binds your shared knowledge
> > to your long-term fingerprint, so that you don't have to do it every
> > time.
> >
> 
> If the PAKE is used to generate a long-term shared secret key that will be
> memorized, then you don't need to re-authenticate to the same partner. With
> OTR+SMP, you need to memorize your secret key and one public-key per
> partner; with this option, you need to memorize one secret key per partner,
> which has the slight drawback of needing a larger trusted memory to store
> this nformation.

That's fair.  But in IM settings, people don't realistically run the
authentication step with each of their buddies.  In such situations, OTR
gives "ssh-style" protection: you're safe against passive attacks, and
you also have some protection against non-constant active attacks.  In
addition, you can *retroactively* become assured that your past
conversations were private by running SMP at any time.  (This gives you
confidence that there's no MITM both backward and forward in time.)

> > But secret society meetings aren't held in dark rooms, where you can't
> > even see who's speaking.  (And even if some crazy ones are, that's not
> > the model most people have in mind for "secure chat room"; imagine the
> > UI: it would have to show what people are saying, but not who's saying
> > it.  I can't imagine that's what people are looking for.)  *Within* the
> > private chat room, there's value in being able to have secure and
> > authenticated communications.
> 
> 
> There are two different things that the autentication can prove: the right
> to be a participant to the chat room, or the identity. They need different
> trust models.

Yes, that's true.  I've yet to see a plausible proposal for a UI for the
former, though, but I'd love to!

> I would clearly accept that in a private chat room I don't know personally
> everyone, and therefore not everyone is issuing authenticated communications
> (from my point of view). However, I want that everyone that participate to
> the chat room has the right to know what is told in there.

But I'd also suggest that even if you don't know who personally Bob and
Charlie are, you'd be upset if an adversary would be able to trick you
into thinking Charlie said something that was actually said by Bob,
while keeping most of their messages correctly attributed.

> I don't put the emphasis on the authentication of the sender of messages,
> but on the authentication of the receiver.
> 
> Louis
> 
> PS: by the way, thank you for this interesting discussion.

It takes two.  ;-)

   - Ian