= IV. Security Properties =
<span style="font-size:200%">F</span>ollowing from the design rationales proposed in Section[[''(n)sec''#Design_rationale|III]], we give an informal description of the properties which ''(n)sec'' aims to secure in a multi-party chat session:<br /><br />
* <span>'''Participant deniable authenticity'''</span> based on their long term persistent identity: While a participant in a chat can be sure of another participant’s authenticity, they cannot prove their confidence to anybody else who has not actively participated in the chat session or who has not interacted with the authenticator prior to the session.
* <span>'''Confidentiality'''</span> of the conversation so its content is not accessible or readable by an outsider.
* <span>'''Forward secrecy'''</span> of the conversation, so its content remains inaccessible in the event that the long term private key of a participant (which represents their long term identity) is compromised after session key establishment. In addition in-session forward secrecy means that compromise of the ephemeral keys of a participant, or the session key during chat session which is live for long time, would reveal only a fraction of the transcript.
* <span>'''Room consistency'''</span>, where all participants are confident that they have been participating in the same room; they are confident that everybody in the room believes that everybody else sees the same participant list as they do.
* <span>'''Transcript consistency'''</span>, where all participants are confident that they have been participating in the same conversation; they are confident that they have seen the same sequence of messages.
For each of these requirements, it is necessary to formalize the above mentioned properties against an adversarial model which addresses the elements discussed requirements stated in [[''(n)sec''#Design_rationale|Section III]]. The next section will introduce formal definitions covering these elements.
= V. Chat Session Model =