[prev in list] [next in list] [prev in thread] [next in thread]
List: otr-dev
Subject: Re: [OTR-dev] Socialist millionaire efficiency on J2ME platforms
From: Vladimir <vlad.star () gmail ! com>
Date: 2010-03-12 14:26:28
Message-ID: 4B9A4F14.2020603 () gmail ! com
[Download RAW message or body]
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@lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic