[guardian-dev] ChatSecure & TextSecure

[Dev Random]

On 08/26/2013 04:36 PM, Patrick Baxter wrote:
> On Mon, Aug 26, 2013 at 3:53 PM, Dev Random <c1.devrandom at niftybox.net> wrote:
>> We don't store the ephemeral keys in SQLCipher, just in memory.
> But, if you needed to start storing keys for asynchony, would
> SQLCipher help with this?
It would, but we would lose the PFS guarantee just like TextSecure.

>> DH does:
>>
>> A -> B: e^Sa where Sa is a secret
>> B -> A: e^Sb where Sb is a secret
>> each computes: e^(Sa*Sb) as the shared secret
>>
>> so for the pre-keys to work, A has to store Sa for each of the pre-keys,
>> and transmit e^Sa to the server.
>>
>> So given that, I'm realizing that the server stored pre-keys are not an
>> issue, since they are not secret.
>>
>> However, you still don't have PFS unless you can secure erase the secret
>> keys on A.
>>
>> Does this make sense?
>>
> Thanks for that explanation. Makes sense to me. So for a receiver
> computing pre-keys, the reciever must insure secure deletion of both
> the ephemeral key and pre-key secret.
>
> This also means that storage of n iterations of Sa becomes a slight
> attack vector if someones phone is locally exploited. I think its only
> slight because its only a slight advantage over just monitoring the
> user's plaintext in that to read N future chat conversations, an
> attacker only need exploit the device, steal N pre-key secrets and
> then leave instead of persistently monitoring and storing plaintext.
> Helps avoid detection and makes for a simpler exploit payload when the
> attacker wishes to remain passive and monitor future conversations.
They would only be able to see the first message in a conversation. 
After the first key rotation, they would not be able to decrypt
anymore.  But I would consider a local exploit to mean "all is lost".

> I also just realized an assumption I previously made about DH
> key-exchanges that may or may not be true, but i'm only going on
> wikipedia right now and could use some clarification:
>
> A DH-key exchange produces an ephemeral key and is only defeated by an
> active MITM attack. If you have verified the sender's identity this
> would allow you to detect a MITM attack. Now I'm not how this
> verification is normally done.
>
> Is there a variation of the DH-key exchange that accounts for this? Or
> are DH-exchanges normally just wrapped by being encrypted to the
> recipients public-key?

You need to prevent MITM, by binding the peer DH pubkey to an identity.

As you said, you first sign it with a long term key.  Then, you can
either check the long term pubkey fingerprint in a side channel with
your intended peer, or you can use a small shared secret with the
Socialist Millionaire protocol.  OTR implementations usually have both
(Adium doesn't implement the latter).