Changes

Np1sec

1,336 bytes removed, 9 years ago
/* VII. Protocol High Level Design */
= VII. Protocol High Level Design =
<span style="font-size:200%">T</span>o achieve the security properties mentioned listed in [[''(n)sec''#IV._Security_Properties|Section IV]], we break the protocol into the following sub-protocols:
# <span>'''Deniable authenticated signature key and session key exchange'''</span>, where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys.# <span>'''Communication'''</span>, where parties send authenticated confidential messages.# <span>'''Transcript consistency verification'''</span>, where parties verify that all have received and seen an identical transcript since the start of the chat session.
Our choice of sub-protocols for ''(n)sec'' has been the use of the same sub-protocols and primitives suggested followed suggestions made in [BGB04] and [GUVGC09], except where there has been a practical or security-related reason to deviate from those recommendations. We have completely replaced the session and signature key establishment protocol. This was done as the original choice of [GUVGC09] for this phase proved impractical in previous implementations. This choice was also motivated by the need to move to a provably secure key exchange. We have moved to elliptic curve cryptography to save on key and signature length in asymmetric primitives. Following the conclusion of [RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability. As it is argued in [RGK05] that the deniability of the protocol is based on deniable key exchange. While they increase the complexity of the algorithm, the above properties do not mathematically contribute to deniability. Taking this step also significantly improves the efficiency of the protocol which is a main focus for ''(n)sec''. In this sense, although users not participating in session are not be able to forge part of the session transcript, they can forge a whole session with false participants and a complete transcript due to the deniability of the authentication scheme. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants.
In the following section we briefly describe our choice of the sub-protocols for each of the required tasks for a multi-party chat session.
Bureaucrat, emailconfirmed, administrator, translator
662
edits