[OTR-dev] Socialist millionaire efficiency on J2ME platforms

[Vladimir]

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
>
>