* Using a more secure deniable key exchange algorithm, instead of naive Diffie-Hellman
* Using a more practical algorithm, rather than the peer-to-peer signature key exchange
* Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys.
* Offering provably secure models for every aspect of the algorithm which formalizes the critical security properties of ''(n)sec''.
In designing ''(n)sec''’s deniable authentication and key agreement protocol, we have followed [ACMP10] by choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] instead of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.
* Using a more practical algorithm, rather than the peer-to-peer signature key exchange
We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication (even though it offers a slightly weaker form of deniability). We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.
Another major difference between * Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys. Following conclusions in [RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability from our requirements since protocol deniability is based on a deniable key exchange. This significantly improves protocol efficiency, a primary focus for ''(n)sec'' . The deniability of the authentication scheme prevents users not present in a chat session from forging a part of the transcript, however it allows them to forge a whole session with false participants and a complete transcript. Another major departure from the suggested protocol for mpOTR in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or sends a message. Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the assumption that the XMPP server provides a reliable and orderly message delivery. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants. We also equip ''(n)sec'' with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.
Finally, we propose the possibility of using block-based, rather than stream-based, encryption for the symmetric encryption primitives.