[OTR-dev] 1-step 3DH ratchet, no handshakes, useable for small-scale mpOTR

[Trevor Perrin]

On Sat, Dec 28, 2013 at 9:09 PM, Ximin Luo <infinity0 at gmx.com> wrote:
> On 29/12/13 02:17, Trevor Perrin wrote:
>> Hi Ximin,
>>
>> I think this has worse forward-secrecy than Axolotl [1].
>>
>> Suppose Alice sends a stream of messages (M1, M2, M3) to Bob.  With
>> Axolotl, Bob destroys the key for each message immediately after
>> decrypting the message.
>>
>> With your ratchet, Bob cannot do this, since (M1, M2, M3) are all
>> encrypted to Bob's same secret keys.
>>
>
> Hm, you are right. I originally was only thinking about the derived message key. But a network attacker who has sniffed the traffic, i.e. who has A's per-message ephemeral keys (g^ephemeral secret), and later compromises B's ephemeral secret, can re-derive the message keys for all of M1, M2, M3.
>
> It does have better future-secrecy properties, but this is much less important than forward-secrecy, since real-world compromises presumably have the ability to compromise those future "healed" keys too.

Agreed that a per-message sender ephemeral key gives more immediate
"future secrecy".

We considered adding that to Axolotl, but there's no great option for
which recipient key to use for the DH:
 - if you use the recipient's identity key, you have a roll-over
problem and no "self-healing"
 - if you use the recipient's ratchet key, then the ratchet key has to
be kept around for longer, so there's a security trade-off

So you'd probably have to add another recipient ratchet-type key for
use with the sender's per-message ephemeral.  It didn't seem worth the
cost in complexity (and also increases computation and message size).


> George Kadianakis later mentioned to me that there might have been an impossibility result for 1-step ratchets (he can't remember), does that bring anything to mind for you? (If not, then I might keep trying. :p)

I'm not totally sure what you mean by 1-step ratchet, so I'm not sure.


>> As far as using a TripleDH instead of a single DH for each ratchet
>> message: we decided against that, since it makes key rollover harder.
>> Alice might periodically wish to destroy her old identity key and
>> introduce a new one, and it seemed better for this not to interrupt
>> all of Alice's conversations.
>>
>
> OK, I see now. This way, the long term keys are only needed at the start; the security of the rest of the conversation only depends on recent history.

Right, that's how it's done in TextSecure and Pond.


Trevor