On Sat, Dec 28, 2013 at 9:09 PM, Ximin Luo <[email protected]> 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 _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
