[guardian-dev] ChatSecure

Tim Prepscius timprepscius at gmail.com
Tue Aug 27 13:24:42 EDT 2013


I guess in pure simplified form, you wouldn't even need to SRP protocol.

You would just have Client A send KeyA (derived from password+something)
And Client B send KeyB (derived from Client B password+something)

And have the final Key be derived from both.

Client A stores Client B key.
Client B stores Client A.

But regenerate final Key as necessary.

Ok, I've babbled enough! ;-)

-tim

On 8/27/13, Tim Prepscius <timprepscius at gmail.com> wrote:
> I wonder if it would be possible to pre key without needing to store the
> key.
>
> The premise of ChatSecure seems to be, as long as the password is not
> compromised, PFS exists.
> I think it may be possible to use the password as a salt generator -- ?
>
>
> ---
>
> I'm thinking about how SRP works.
>
> Incoherent babble follows:
>
> Client A acts as an SRP server.
> Client B acts as an SRP client.
>
> --
>
> SRP but with a pre-step:
> Client A generates Salt A via password and something (timestamp?)
> Client B generates Salt B via password and something (timestamp?).
>
> Client B says hello to Client A, and sends Salt-B.
> Client A sends hello return to Client B, sends Salt-A.
>
> Client A uses Salt-A and Salt-B to generate Salt Final.
> Client B uses Salt-A and Salt-B to generates Salt Final.
>
> --
>
> SRP protocol takes places.
> Except when it's over it's over.  Both sides "forget" the generated AES-256
> key.
>
> In the process:
> Client A stores Client-B publicKey.
> Client B stores Client-A publicKey.
>
> But neither Client A nor Client B stores the salt-final.
> They both store opposite side component of the salt.
>
> So client A stores Client B salt.
> Client A stores Client A salt.
>
> ---
>
> So, when Client B wants to send a message to Client A.
> It re-generates Salt Final by recomputing Salt B and multiplying by
> stored Salt A.
>
> Then it has all the requisite information to complete the protocol,
> find the final AES-256 key.
>
> --
>
> This idea occurred to me, could be nonsense.
> But maybe there is something of use.
>
> -tim
>
>
>
>
>
>
> On 8/27/13, Abel Luck <abel at guardianproject.info> wrote:
>> Nathan of Guardian:
>>> On 08/27/2013 11:09 AM, Abel Luck wrote:
>>>> Moxie's proposal doesn't modify OTR at all, maybe you misunderstood it?
>>>> Instead it is a very nice example of making an app a bit smarter and
>>>> less desktop-centric :)
>>>
>>> How about "enhances" OTR? All in all, the TextSecure flavor of OTR is
>>> not interoperable with vanilla OTR, be it the use of ECC, or the
>>> expectation of pre-keys in a certain location.
>>>
>>
>> Ah, yea, when it comes to TextSecure's OTR as awhole, he definitely
>> changed/enhanced the protocol.
>>
>> However the pre-keying sessions thing to make it play nice for the async
>> usecase is more about making the app smarter I think. It's on the same
>> tier as Chris' push notification proposal, or our future voice support
>> detection between ChatSecures.
>>
>>> What I am wondering is how far we can push a standard, interoperable OTR
>>> implementation, such that it, to the user, achieves nearly the same
>>> thing.
>>>
>>
>> Yes, now this is something I'd like to investigate more. I think Moxie's
>> pre-keying could work (maybe with some tweaks) between one "enhanced"
>> client and a "dumb/standard" OTR client.
>>
>> ~abel
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit:
>> https://lists.mayfirst.org/mailman/options/guardian-dev/timprepscius%40gmail.com
>>
>> You are subscribed as: timprepscius at gmail.com
>>
>


More information about the Guardian-dev mailing list