<filewiki_vars>
title=Cryptography
menu=$title
</filewiki_vars>


# 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][asymmetric] 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.

[asymmetric]: https://en.wikipedia.org/wiki/Public-key_cryptography "Public-key cryptography"
