The np1sec library ( https://github.com/equalitie/np1sec ) needs a client that uses it, so that we can test it in practice during development. Proof of concept quality will do fine.
The basic user interface concept of np1sec is a chat Channel, which is an encrypted chat session that behaves much like a normal chat room. It contains a set of Participants, which can chat to each other, join and leave the channel, etc. np1sec channels should be implemented in the user interface as a chat window in the usual sense of the word, extended with some additional components to represent the security considerations.
== Participants ==
A Participant in an np1sec channel consists not only of a nickname or username as used by the transport chat system, but also a public key that represents the cryptographic identity of the participant. Participants in a channel are confirmed to possess the private key corresponding to their identity, and the authenticity of messages sent by participants is verified to match their public key. A production-quality client should probably maintain a database of nickname / public key associations, similar to most OTR plugins; but for the proof of concept client, a user interface that can show the verified public key of participants without trying to judge their validity would be preferable.
Besides having a set of participants, an np1sec channel also contains at any point a set of users that are trying to join the channel; that is, users that are trying to become Participants. Such a recruit needs to be accepted by all present participants before being allowed entry into the channel; and symmetrically, the recruit also needs to accept all participants in the channel. Until they have received all these blessings, aspirant participants cannot participate in the channel chat, nor participate in most other ways. They can, however, see both the list of current participants, and the list of aspirant participants, of the channel.
Aspirant participants have a lot of assorted status and interaction possibilities that the user interface needs to represent somehow:
each aspirant participant is at any time accepted by a certain set of the channel participants. Symmetrically, each aspirant participant has at any time accepted a certain set of the channel participants. The aspirant's user interface should make it explicit which participants have yet to accept them, in the form of nickname colorations / status flags / what have you; any other members of the channel (participants or aspirant participants) should be able to query this information via a popup dialog or something.
participants in a chat need some method of accepting or rejecting aspirant participants, and vice versa. The user interface approach that sounds sensible to me is to have accept/reject buttons next to all members that have yet to be accepted; though maybe a context menu button is sufficient. Ideally, the chat text widget should also display a line saying "Alice joined the room as an aspirant [Accept] [Deny]" with link-buttons to click on, to notify existing participants of the newcomer and the need to authorize them? (Discuss.) When an aspirant participant first joins a channel, they should probably automatically authorize everyone who is a participant at that time, but require active confirmation for anyone getting promoted to participant later? (Discuss.)
aspirant participants of a chat are not necessarily authenticated to their announced public key yet. That is to say, an aspirant participant may not have sent authentication information yet, or they may have sent invalid (malicious) authentication. Authentication is peer-to-peer, which means that Alice may have authenticated herself to Bob but not yet to Charlie. The user interface should represent this authentication status, and call special attention to any explicitly failed authentication. Theoretically, a member may authorize unauthenticated aspirant participants at their own risk, but it would probably be wiser to disallow this? (Discuss.)
When an aspirant participant gets promoted to a full participant, a two-step process starts. First, the np1sec system starts negotiating a new encryption key that the new participant has access to; when this is finished, people start using it. Only when all participants have switched to using this new encryption key does the user interface show the new participant as having joined, and can the new participant start sending messages. In between the start and the end of this process, there is a (hopefully short) period in which the new participant can decrypt some but not all of the messages sent to the channel. This has minor security consequences; for example, the start of the process is the point where existing participants should stop discussing topics that the new participant should not near, but the end of the process is the point where participants can start talking to the new participant. It is not clear whether this distinction should be visible in a practical production-level client, but the proof of concept client should make the distinction explicit, so that we can experiment with the consequences. This should probably take the form of two separate join-messages in the main chat window: one saying something like "Alice is joining the chat", followed later by "Alice has joined the chat".
The same consideration applies in reverse when a participant leaves the chat. A new key is renegotiated without the leaver; as long as that negotiation is in process, the leaver can probably not hear what is being said (as they have left the transport chatroom), but there are no cryptographic assurances of this until the key negotiation finishes.
== Transcript consistency ==
The np1sec system cryptographically verifies that different users in the channel all receive the same messages; for example, that it is not possible for Alice to send one message to Bob and a different message to Charlie without them noticing.
When this system detects an infraction, it knows that recent messages from a certain point onwards may not have been received correctly by a certain set of participants. Clearly, the user interface needs to represent this in some way. The details are as of yet unclear, though. (Discuss.)
== Channel searching ==
A transport chatroom, such as a jabber multi-user chat room, can host multiple different concurrent np1sec channels. This is unfortunate, but cannot be avoided.
As a consequence, when a user wants to join an np1sec channel in a certain transport chatroom, they first need to perform a search for available np1sec channels; after having found such a list, they can then either join one of the available channels, or start a channel of their own. A chatroom user can only be a member of one np1sec channel per room at any time.
The channel search procedure takes the form of the np1sec library maintaining a list of available channels, which gets updated continuously. The list starts empty, and as the search progresses, new channels get added to the list, and existing channels get their status updated as time passes. Channels on this list have the full set of attributes that channels of which the user is a member have; in particular, these channels all have lists of both full participants and aspirant participants, with all the assorted status that implies. As time progresses, these channels get updated in response to channel events: participants leave, aspirant participants get promoted to participants, new aspirant participants join, etc. Channels can also disappear when their last remaining participant leaves.
The user interface needs to represent this channel search procedure somehow. When a user tries to join an np1sec chat room, the user interface should first display a search window of available channels, and keep it updated in response to changes; each available channel should at least render a list of participants, and probably not more than that (but Discuss). Channels do not have much other metadata to render; in particular, they do not have names, or suchlike, which makes designing a practical user interface challenging. The search ends when the user either chooses to join a particular channel, or chooses to start their own channel.
The np1sec library ( https://github.com/equalitie/np1sec ) needs a client that uses it, so that we can test it in practice during development. Proof of concept quality will do fine.
The basic user interface concept of np1sec is a chat Channel, which is an encrypted chat session that behaves much like a normal chat room. It contains a set of Participants, which can chat to each other, join and leave the channel, etc. np1sec channels should be implemented in the user interface as a chat window in the usual sense of the word, extended with some additional components to represent the security considerations.
== Participants ==
A Participant in an np1sec channel consists not only of a nickname or username as used by the transport chat system, but also a public key that represents the cryptographic identity of the participant. Participants in a channel are confirmed to possess the private key corresponding to their identity, and the authenticity of messages sent by participants is verified to match their public key. A production-quality client should probably maintain a database of nickname / public key associations, similar to most OTR plugins; but for the proof of concept client, a user interface that can show the verified public key of participants without trying to judge their validity would be preferable.
Besides having a set of participants, an np1sec channel also contains at any point a set of users that are trying to join the channel; that is, users that are trying to become Participants. Such a recruit needs to be accepted by all present participants before being allowed entry into the channel; and symmetrically, the recruit also needs to accept all participants in the channel. Until they have received all these blessings, aspirant participants cannot participate in the channel chat, nor participate in most other ways. They can, however, see both the list of current participants, and the list of aspirant participants, of the channel.
Aspirant participants have a lot of assorted status and interaction possibilities that the user interface needs to represent somehow:
When an aspirant participant gets promoted to a full participant, a two-step process starts. First, the np1sec system starts negotiating a new encryption key that the new participant has access to; when this is finished, people start using it. Only when all participants have switched to using this new encryption key does the user interface show the new participant as having joined, and can the new participant start sending messages. In between the start and the end of this process, there is a (hopefully short) period in which the new participant can decrypt some but not all of the messages sent to the channel. This has minor security consequences; for example, the start of the process is the point where existing participants should stop discussing topics that the new participant should not near, but the end of the process is the point where participants can start talking to the new participant. It is not clear whether this distinction should be visible in a practical production-level client, but the proof of concept client should make the distinction explicit, so that we can experiment with the consequences. This should probably take the form of two separate join-messages in the main chat window: one saying something like "Alice is joining the chat", followed later by "Alice has joined the chat".
The same consideration applies in reverse when a participant leaves the chat. A new key is renegotiated without the leaver; as long as that negotiation is in process, the leaver can probably not hear what is being said (as they have left the transport chatroom), but there are no cryptographic assurances of this until the key negotiation finishes.
== Transcript consistency ==
The np1sec system cryptographically verifies that different users in the channel all receive the same messages; for example, that it is not possible for Alice to send one message to Bob and a different message to Charlie without them noticing.
When this system detects an infraction, it knows that recent messages from a certain point onwards may not have been received correctly by a certain set of participants. Clearly, the user interface needs to represent this in some way. The details are as of yet unclear, though. (Discuss.)
== Channel searching ==
A transport chatroom, such as a jabber multi-user chat room, can host multiple different concurrent np1sec channels. This is unfortunate, but cannot be avoided.
As a consequence, when a user wants to join an np1sec channel in a certain transport chatroom, they first need to perform a search for available np1sec channels; after having found such a list, they can then either join one of the available channels, or start a channel of their own. A chatroom user can only be a member of one np1sec channel per room at any time.
The channel search procedure takes the form of the np1sec library maintaining a list of available channels, which gets updated continuously. The list starts empty, and as the search progresses, new channels get added to the list, and existing channels get their status updated as time passes. Channels on this list have the full set of attributes that channels of which the user is a member have; in particular, these channels all have lists of both full participants and aspirant participants, with all the assorted status that implies. As time progresses, these channels get updated in response to channel events: participants leave, aspirant participants get promoted to participants, new aspirant participants join, etc. Channels can also disappear when their last remaining participant leaves.
The user interface needs to represent this channel search procedure somehow. When a user tries to join an np1sec chat room, the user interface should first display a search window of available channels, and keep it updated in response to changes; each available channel should at least render a list of participants, and probably not more than that (but Discuss). Channels do not have much other metadata to render; in particular, they do not have names, or suchlike, which makes designing a practical user interface challenging. The search ends when the user either chooses to join a particular channel, or chooses to start their own channel.