1. Underlaying Cryptographic Systems

1.1 Introduction

The DarkChannel protocol heavily relies on an underlaying cryptographic system to provide the needed cryptographic primitives for the protocol to function properly.

One of the goal of the DarkChannel protocol is to be cryptographic system agnostic. The protocol does not rely on a specific cryptographic system but allows any system providing a certain set of generic features and primitives to be used.

In essence this means that a crypto system to be used within the DarkChannel protocol MUST be a asymmetric system with public and private key material.

A cryptographic system MUST provide the following primitives to be used as an underlaying cryptographic system for the DarkChannel protocol:

• key material generation
• message encryption
• message decryption
• message signature
• detached message signature
• signature verification
• finger printing of key material
• import and export of the generated key material

Should a cryptographic system provide all the above requirements it MAY be suited to be used as an underlying cryptographic system in a further iteration of the DarkChannel protocol.

1.2 Supported Cryptographic Systems

1.2.1 GnuPG

GnuPG is widly accepted and trusted. It has been proven very secure when used correctly and within the right context. GnuPG was designed with Email message encryption in mind and chat messages are not so different from emails, aside from the fact that they are a lot shorter, most of the times.

GnuPG was implemented at a time when computing costs where high and computing power was low, compared to today. Today's computer no longer need to invest substantial cpu power for the cryptographic primitives provided by GnuPG.

GnuPG provides all required features and primitives needed for usage as an underlaying crypto system for the DarkChannel protocol. We chose GnuPG as the underlying crypto system for the first iteration of the DarkChannel protocol.

1.3 Key Material

This section describes how the DarkChannel protocol uses key material to protect it's communications and the client's and user's identity.

1.3.1 Privacy, Surveilance and Trust

The DarkChannel protocol recognizes today's problems of mass surveilance.

To guard against such privacy invasion, the protocol tries to rely on the chosen cryptographic system only, without using other cryptographic means for protection of the communication.

This means that the DarkChannel protocol does not use TLS or similar mechanisms to guarantee authentication or authorisation. Nor does it use any outside trust mechanism or framework except it's own.

The DarkChannel relies on an underlaying cryptographic system but it does not use trust frameworks implemented by those systems. Specifically even tough the current protocol iteration uses GnuPG as the underlying cryptographic system, it does not use the GnuPG web of trust.

The DarkChannel protocol together with it's underlying cryptographic system is self-complete and does not rely on any outside help to provide it's service.

1.3.1 Nodes

All participating DarkChannel client nodes MUST generate new key material for every server node it connects to. The client MAY generate new key material on every connection or it MAY reuse the key material for the same connection it was generated for.

The DarkChannel protocol guarantees that all communication between communicating nodes (except for the first welcome message from the listener) happens encrypted to the receiver and signed by the sender. Services identify themselfes by cryptographic means allowing clients to assure that no man-in-the middle attacks are taking place.

1.3.2 Users

To allow users to be able to be recognized and identified by other users the DarkChannel clients allow the users to generate specific key material for nick name and operator registration with a channel server.

A channel server accepting such a nick name or operator key registration will sign the given key material to prove to other clients that the registration took place and was accepted.

The nick name or operator key material is private to the client and MAY be used by the client to sign messages in the name of the user to prove the message author's identity to the recipient(s).

Users MUST be free to choose if they sign a message with nick name or operator key material or not.

If they do not sign a message the message can only be associated to the current channel key of the client, which MAY be swapped by the client whenever he choses so.