CQP Tool kit

O sistema fornece vários componentes para integrar QKD em um sistema de segurança. É escrito em C++11, mas usa interfaces GRPC, portanto pode ser integrado com muitas linguagens diferentes.

Início Rápido

Para executar o software nativamente, siga uma das opções:

baixe e instale os pacotes deb do Ubuntu ou
clone o código-fonte, garantindo que os submódulos sejam atualizados e construa localmente

Para clonar o código-fonte incluindo submódulos:```bash git clone --recurse-submodules [email protected]:QComms/cqptoolkit.git

> Se você clonou sem usar `--recurse-submodules`, os submódulos podem ser atualizados executando `git submodule update --init` a partir da pasta de origem.

Aqui está uma lista de dependências necessárias para compilar o projeto (leia mais abaixo para mais detalhes sobre a instalação):```bash
sudo apt install pkg-config ca-certificates file build-essential cmake ninja-build libusb-1.0-0-dev libcurl4-openssl-dev \
	libcrypto++-dev libcap-dev uuid-dev libssl-dev libsqlite3-dev libprotobuf-dev libgrpc++-dev \
	libssl-dev protobuf-compiler protobuf-compiler-grpc checkinstall
mkdir build-cqptoolkit
cd build-cqptoolkit
cmake -G Ninja ../cqptoolkit && ninja

Teste rápido

A partir da pasta de compilação, para executar dois sites (no mesmo computador local) cada um com um dispositivo QKD, primeiro inicie o site "A" iniciando um agente de site e conectando um "dummy driver" Alice a ele: (Se os binários foram instalados, omita os caminhos para os comandos das instruções.)```bash ./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8000 & ./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8000 -a

ENTRADA:```bash
./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8001 &
./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8001 -b

Isso não começará a produzir chave imediatamente, pois este sistema foi projetado para ser controlado por um sistema de gerenciamento; a conexão precisa ser estabelecida com o comando SiteAgentCtl.

Primeiro, você pode verificar a lista de dispositivos disponíveis com:```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -d -c localhost:8000

o que deve produzir algo semelhante a isto por padrão, se *SiteAgentRunner* e *DummyQKDDriver* forem iniciados sem especificar um argumento de arquivo de string de configuração JSON:```json
{
 "url": "<hostname>:8000",
 "devices": [
  {
   "config": {
    "id": "dummyqkd__0__16_alice",
    "kind": "dummyqkd"
   },
   "controlAddress": "<hostname>:34219"
  }
 ]
}

e a porta 8001 deve produzir algo semelhante a```json { "url": ":8001", "devices": [ { "config": { "id": "dummyqkd__0__16_bob", "side": "Bob", "kind": "dummyqkd" }, "controlAddress": ":38367" } ] }

- Agora, a conexão pode ser feita chamando:```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -j localhost:8001

Isso criará um único salto de um site para o próximo, novamente, rotas mais complexas podem ser definidas usando a opção -a com uma string JSON especificando o caminho.

Após alguns segundos, deve haver uma chave disponível que pode ser testada solicitando uma chave.

NOTA: O parâmetro -k deve ser a url mostrada nos detalhes do segundo site, não "localhost:8001"```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -k hostname:8001

O link pode ser interrompido com o comando unjoin:```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -u localhost:8001

Observe que a chave ainda está disponível mesmo que a geração tenha parado, desde que os agentes do site estejam em execução. Ela pode ser solicitada com o mesmo comando de solicitação de chave acima.

Exemplo de criptografia

Com os agentes do site e drivers lançados no mesmo computador local conforme descrito acima e após ter iniciado o link para troca de chaves, também é possível testar os recursos de criptografia.

Primeiro, inicie um lado da "VPN" no bob, que escutará na porta 9010 e se conectará ao repositório de chaves do Bob:``` ./src/Tools/QTunnelServer/QTunnelServer -p 9010 --keystore-url=hostname:8001

- Agora inicie o lado Alice da VPN, definindo o túnel a ser criado. Duas portas serão abertas, uma para cada lado nas portas 9000 e 9001, qualquer coisa que entrar nessas portas será criptografada, transferida para o outro lado, descriptografada e entregue na outra porta.```
./src/Tools/QTunnelServer/QTunnelServer --keystore-url=`hostname`:8000 --remote=localhost:9010 --start-node=tcpsrv://0.0.0.0:9000 --end-node=tcpsrv://0.0.0.0:9001

Qualquer coisa que use comunicações tcp pode então usar esta porta, netcat é um programa simples que enviará dados pelas portas, inicie um de cada lado:``` nc localhost 9000

e um no outro:```
nc localhost 9001

Qualquer coisa digitada de um lado aparecerá do outro quando Enter for pressionado. Inspecionar os pacotes que viajam pelas portas 9000 e 9001 com uma ferramenta como o Wireshark mostrará os dados sendo criptografados e o ID da chave usado.

Outras formas de conexão podem ser criadas, em vez de tcpserv:

Progresso

Funcionalidades planeadas e concluídas

Espera-se que este projeto possa ser útil tanto para trabalho de investigação científica como para grandes projetos. Mais detalhes sobre o projeto podem ser encontrados em este artigo.

Para contribuir com este projeto, por favor consulte o ficheiro Contribution.

Instalação

O sistema funciona atualmente no Linux - O Windows está planeado para o futuro. A maneira mais fácil é compilar a partir do código fonte neste momento

Imagem Docker

Há uma imagem Docker pronta para executar no gitlab registry. Pode executar com sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime. Adicione um comando no final para executar algo diretamente, por exemplo para executar uma simulação da geração de chave QKD com QKDSim:```bash sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime AlignmentTests

### Ubuntu 18.04+

Pode instalar pacotes binários a partir do [Gitlab](https://gitlab.com/QComms/cqptoolkit/-/jobs/artifacts/master/download?job=package%3Adeb). Extraia o ficheiro zip e instale as ferramentas com `dpkg`, irá queixar-se de dependências em falta, mas não se preocupe, a segunda linha irá corrigi-las.```bash
sudo dpkg -i setup/*.deb build/gcc/CQP-*-Linux-{Algorithms,Networking,CQPToolkit,KeyManagement,QKDInterfaces,CQPUI,Simulate,Tools,UI,Drivers,IDQDevices}.deb
sudo apt install -fy

Para instalar os arquivos de desenvolvimento (cabeçalhos e bibliotecas estáticas) execute sudo dpkg -i build/gcc/CQP-*-Linux-*-dev.deb ; sudo apt install -fy ao invés disso.

A partir do código fonte

Claro, se você não quiser alterar as versões das bibliotecas e dependências do seu sistema, você pode compilar dentro de um container docker que já possui todas as dependências instaladas com:```bash sudo docker run -it registry.gitlab.com/qcomms/cqptoolkit/buildenv

Caso contrário, a compilação a partir do código-fonte requer que você instale as dependências listadas em `setup/setupbuild.sh`, atualmente funciona para Ubuntu e Arch Linux.

Clone a fonte de [gitlab](https://gitlab.com/QComms/cqptoolkit.git) com [git][] e compile com [CMake][] e [gnu make](https://www.gnu.org/software/make/):
A opção `--recurse-submodules` adiciona os extras opcionais - o acesso a alguns deles é restrito à UoB e seus parceiros, a compilação funcionará sem eles.```bash
git clone --recurse-submodules https://gitlab.com/QComms/cqptoolkit.git

Se você quiser obter todos os submódulos e tiver os logins apropriados, execute:```bash git submodule update --checkout

Agora, pode ir ao seu repositório local e instalar as dependências com o script (talvez precise alterar a permissão do ficheiro):```bash
cd cqptoolkit/setup
./setupbuild.sh

Em seguida, pode construir o projeto numa nova pasta:```bash mkdir build-cqptoolkit cd build-cqptoolkit cmake ../cqptoolkit && nice make -s -j

this can be installed with

sudo make install

A construção usa [CMake][] para gerar makefiles/soluções/etc para muitas plataformas diferentes e é invocada a partir de uma pasta de construção vazia que conterá todos os ficheiros de saída. As compilações de depuração produzirão pacotes com o sufixo "D".
A construção pode ser controlada passando opções ao cmake, ex. `-DBUILD_TESTING=OFF`. Execute o cmake com a opção `-LH` para listar as opções disponíveis.

Para fazer alterações e desenvolver a biblioteca, recomenda-se instalar o [QT Creator](http://doc.qt.io/qtcreator/) e abrir o projeto [selecionando o ficheiro CMakeLists.txt](https://codeyarns.com/2016/01/26/how-to-import-cmake-project-in-qt-creator/). É aconselhável usar compilações paralelas indo a Projetos->Passos de Compilação->Detalhes e adicionando `-j<número>` aos parâmetros da ferramenta, veja [so](https://stackoverflow.com/questions/8860712/setting-default-make-options-for-qt-creator).
Uma vez compilados, os ficheiros, por predefinição, estão ao mesmo nível da pasta do projeto chamada `build-<nome do projeto>-<plataforma>-<alvo>`.

> **Nota sobre protobuf + QT no Ubuntu**
> A biblioteca `qt5-gtk-platformtheme` está ligada a uma versão antiga do protobuf que impedirá os nossos programas QT de funcionar.
> Esta dependência opcional pode ser removida com `apt-get remove qt5-gtk-platformtheme`

## Explorando a Biblioteca

    @startuml
        title Applicaiton Overview

        component "QKD Device Drivers" as drv
        interface IDevice as idev
        drv - idev

        component "Device contol and\n Key storage" as sa
        interface IKey as ikey
        sa - ikey
        sa ..> idev

    package "Key consumers" as kc {
        component "Custom VPN" as tun
        component "Custom\nWeb Server" as nginx
        component "HSM bridge" as hsm
    }
    tun ..> ikey
    nginx ..> ikey
    hsm ..> ikey

    package Utilities {
        component "Config/Control GUI" as gui
        component "Simulators/Testing" as sim
        component "Data extraction" as stats

        gui -[hidden]down- sim
        sim -[hidden]down- stats
    }
    @enduml

Abaixo está um fluxograma para ajudar a encontrar a área relevante para si, pois o projeto cobre muitos aspetos diferentes do QKD e gestão de chaves – contribuidores são bem-vindos para conduzir este projeto para ser mais especializado.
O QKD requer alguma forma de comunicação de [não-clonagem](https://en.wikipedia.org/wiki/No-cloning_theorem), geralmente usando fotões individuais sobre um cabo de fibra ótica. Podem operar ponto-a-ponto ou um-para-muitos, mas inerentemente têm uma localização física (onde a fibra termina) – não podem ser virtualizados! O ponto onde o fotão é transmitido ou detetado é o limite do sistema seguro – quase como a [firewall](https://en.wikipedia.org/wiki/Firewall_(computing)) de uma rede. Uma vez que os fotões indivisíveis são transformados numa sequência de bits para formar uma [chave simétrica](https://en.wikipedia.org/wiki/Key_(cryptography)), aplicam-se as regras padrão de segurança informática como autenticação, controlo de acesso, etc. A diferença é que, uma vez produzidas essas chaves, cada um dos dispositivos QKD tem um número que [mais ninguém conhece](https://en.wikipedia.org/wiki/Shared_secret) [provado pela ciência](https://arxiv.org/pdf/quant-ph/0003004.pdf).

A natureza deste efeito de "firewall" é que os sistemas que controlam os dispositivos QKD precisam de ser seguros e considerados fiáveis – também chamado "nó fiável" – onde e como se traça a linha pode variar desde guardas armados até apenas [trancar a porta da sala de servidores](https://www.youtube.com/watch?v=rnmcRTnTNC8).

Se não conseguir ver o diagrama abaixo, por favor consulte a [documentação online](https://qcomms.gitlab.io/cqptoolkit/), também pode ser compilada pelo alvo `doc`.

    @startuml
    title Where to start \n

    skinparam activity {
      StartColor #EF476F
      BarColor #FFD166
      EndColor #EF476F
      BackgroundColor #06D6A0
      BorderColor #118AB2
    }

    start
    if (Do you have a QKD Device?) then (Yes)
        if (Does your QKD device have a driver?) then (No)
            :You will need to [[./index.html#CreatingDrivers create a driver]] which implements the
            <b>IDriver</b> and <b>IReporting</b> interfaces.;
            if (Use the library?) then (Yes)
                :See the [[./index.html#RunningDummyQKDDriver DummyQKDDriver]] for an example.;
            else (No)
            endif
        else (Yes)
        endif
    else (No)
        :Check out how to run the
        [[./index.html#RunningDummyQKDDriver DummyQKDDriver]];
    endif

    if (Do you want keys for multiple
    locations in a network?) then (Yes: Sites)
        :[[./index.html#Registering Register your driver]] with the site agent
        using the <b>ISiteAgent</b> Interface
        Keys can be obtained by using the [[./index.html#IKeyInterface IKey]] interface;

        if(Do you want keys to be stored/persist between restarts?) then (Yes)
            if (Do the keys need to be secured?) then (Yes)
                :Use the [[./index.html#HSMs HSM storage]] options;
                if (Is your HSM supported?) then (No)
                    :Create a driver that implements
                    the <b>IBackingStore</b> interface.
                    Add the driver creation to the
                    <b>BackingStoreFactory</b>;
                else (Yes)
                endif
            else (No)
                : When running SiteAgentRunner,
                use the option ""-b file"" or
                set ""backingStoreUrl"" to
                ""file:///filename.db"";
            endif
        else (No)
        endif
    else (No: Point-to-Point)
        :Use the [[./index.html#IDeviceInterface IDevice interface]] to
        control the driver for your system.
        As keys become available they will
        be sent via the call to <b>WaitForSession</b>.;
    endif

    if (Do you want to use the key for anything?) then (Yes)
        :See the [[./index.html#Encryption encryption section]]
        for an example of using the [[./index.html#IKeyInterface IKey interface]];
    else (No)
    endif
    stop

    @enduml


### Executando DummyQKDDriver <a name="RunningDummyQKDDriver" />

Esta secção é apenas um comentário sobre a funcionalidade útil do DummyQKDDriver para simular a saída de um dispositivo QKD. Consulte a secção seguinte para um exemplo guiado de configuração de uma ligação simples com eles.
Tal como na maioria dos programas, passar `-h` irá mostrar as opções disponíveis. O DummyQKDDriver executa um conjunto padrão de passos de pós-processamento em deteções de fotões simuladas usando a classe cqp::DummyQKD. É necessário que haja duas instâncias do programa em execução, uma para Alice e outra para Bob.

Execute Bob primeiro na porta 8000 chamando:```bash
DummyQKDDriver -b -k 0.0.0.0:8000

Agora execute Alice, dizendo a ela para conectar a Bob e iniciar a troca de chave (no modo manual):```bash DummyQKDDriver -a -m localhost:8000

Se funcionar, você receberá uma enxurrada de mensagens de erro como esta: `ERROR: OnKeyGeneration No listener for generated key`. Isso ocorre porque, embora executar o sistema dessa forma seja interessante para vê-lo fazendo algo, não é muito útil, não há onde colocar a chave que é gerada. Os drivers são projetados para serem usados por algo.
O projeto possui um sistema para gerenciar as chaves chamado [Site Agents](#SiteAgents) ou você pode conversar diretamente com os drivers usando a [interface IDevice](#IDeviceInterface)

### Configuring the Site Agents <a name="SiteAgents" />

Os agentes de site, drivers e túneis VPN precisam ser parametrizados para cada nó da rede com arquivos de string JSON, pois o comando padrão sem argumentos não especifica todos os campos necessários por padrão e só funciona para testes na mesma máquina local.

Os agentes de site podem ser executados com o SiteAgentRunner; podemos executar dois sites com:```bash
SiteAgentRunner -c site-a.json

e:```bash SiteAgentRunner -c site-b.json

com cada arquivo JSON indicando apropriadamente uma porta diferente para Alice e Bob (por exemplo, 9000/9001). A string JSON se parece com isto:```json
		{
		    "name":"",
		    "id":"",
		    "netManUri":"",
		    "bindAddress":"0.0.0.0",
		    "listenPort":9000,
		    "connectionAddress":"",
		    "credentials": {},
		    "useAutoDiscover":false,
		    "backingStoreUrl":"",
		    "fallbackKey":""
		}

Agora podemos anexar nossos DummyQKDDriver's, um para cada site:```bash DummyQKDDriver -c driver_config-a.json # run as Alice, register with site agent

e:```bash
DummyQKDDriver -c driver_config-b.json # run as Bob, register with site agent

com cada arquivo JSON indicando adequadamente uma porta diferente para Alice e Bob (por exemplo, 9000/9001). A string JSON se parece com isto:```json {
"controlParams": { "config": { "id": "dummyqkd__0__16_alice", "side": "Alice", "switchName": "", "switchPort": "", "kind": "dummyqkd", "bytesPerKey": 0 }, "controlAddress": "'hostnameIP':4423", "siteAgentAddress": "127.0.0.1:9000" }, }

> O campo de endereço de controle pode ser 0.0.0.0:0 se não houver firewall para lidar. Se for o caso, é necessário indicar o IP real do host e escolher uma porta apropriada que o firewall não bloqueie.

Nada acontecerá ainda, pois os agentes do site não sabem o que fazer com esses dispositivos. Podemos instruí-los a começar a fazer a chave (-b como begin) enviando o comando cqp::ISiteAgent::StartNode:```bash
SiteAgentCtl -c localhost:9000 -b '{"hops":[{"first":{"site":"'hostname':9000","deviceId":"dummyqkd__0__16_alice"},"second":{"site":"'hostname':9001","deviceId":"dummyqkd__0__16_bob"}}]}'

Os computadores têm que ser capazes de resolver nomes de host e isto deve ser usado aqui em vez do endereço IP rígido. Portanto, deve-se modificar os arquivos /etc/hostnames em ambas as máquinas se não for o caso.

Esta é uma maneira complicada de dizer conectar A a B, mas é muito poderosa, permitindo que múltiplos saltos sejam especificados para produzir uma chave segura de ponta a ponta a partir de uma cadeia de dispositivos. Esta string JSON pode ser especificada no campo de configuração "staticHops" dos agentes do site para que isso aconteça automaticamente assim que todos os dispositivos estiverem disponíveis. O link pode então ser interrompido com:```bash SiteAgentCtl -c localhost:9000 -e '{"hops":[{"first":{"site":"'hostname':9000","deviceId":"dummyqkd__0__16_alice"},"second":{"site":"'hostname':9001","deviceId":"dummyqkd__0__16_bob"}}]}'

> Observe o `-e` em vez de `-b` para *finalizar* o link em vez de *iniciá*-lo.

Configurações mais complexas podem ser alcançadas implementando você mesmo a interface cqp::remote::INetworkManager para emitir os comandos. O feedback dos dispositivos chega através da interface cqp::remote::IReporting no mesmo socket para que você possa reagir a mudanças no sistema. [Aqui](#Reporting) você pode ver como extrair informações da interface de relatório com a ferramenta StatsDump.

### Criando Drivers <a name="CreatingDrivers" />

O aplicativo driver é uma ponte entre as interfaces internas do dispositivo (cqp::IQKDDevice) e a interface externa cqp::remote::IDevice. A classe cqp::RemoteQKDDevice lida com a maior parte do trabalho para você, o aplicativo deve lidar com a configuração e criação do dispositivo.

O trabalho real está em criar um driver para configurar o dispositivo e ler a chave. Se o seu dispositivo apenas produz detecções brutas, você precisará configurar um [pipeline de processamento](#ProcessingPipelines) como cqp::DummyQKD ou cqp::PhotonDetectorMk1 e cqp::LEDAliceMk1. Se o seu dispositivo gera chave pronta para uso como o cqp::Clavis3Device, você precisa lê-la e publicá-la através da interface cqp::IKeyCallback (use cqp::KeyPublisher).

Ambas as abordagens requerem uma forma de gerenciamento de sessão, fornecida por cqp::session::SessionController e cqp::session::AliceSessionController, estes implementam a interface cqp::ISessionController e cqp::remote::ISession e são usados por cqp::RemoteQKDDevice para iniciar e parar o dispositivo e seu par. Geralmente é tudo o que é necessário, mas em algumas situações eles precisam ser especializados para lidar com os requisitos do dispositivo.

    @startuml Readme_Drivers
    title Anatomy of a driver
        package Application {
            namespace cqp #DDDDDD {
                class RemoteQKD
                interface IQKDDevice {
                    GetSessionController()
                }
                class "SessionController" as session
                interface "IDetector::Service" as detServ {
                    StartDetecting()
                    StopDetecting()
                }
                class "Provider<IDetectionEventCallback>" as provider {
                    Attach()
                    Dettach()
                    Emit()
                }

                RemoteQKD .r.> IQKDDevice : uses
                IQKDDevice -r[hidden]-> session
            }
            class Main {
                main()
            }
            class MyDriver
            class Detector

            MyDriver .u.|> cqp.IQKDDevice
            MyDriver o-u-> cqp.session
            Detector .u.|> cqp.detServ
            Detector -u-|> cqp.provider

            Main o-> MyDriver
            MyDriver o-> Detector
            Main o-u-> cqp.RemoteQKD

            note bottom of MyDriver
                In this case the driver is a simple detector
                which produces detection. Post processing detail not shown.
                MyDriver pull together all the parts to run the driver.
            end note

            note bottom of Detector
                The detector controls the device
                and outputs the data using the Provider
            end note
        }
    @enduml

### Registrando um driver <a name="Registering" />

No momento da escrita, todos os drivers podem ser registrados com um agente de site usando a opção `-r`. Isso faz com que o cqp::RemoteQKDDevice chame cqp::remote::ISiteAgent::RegisterDevice no cqp::SiteAgent, que então usará a interface cqp::remote::ISession para iniciar/parar o dispositivo.

### Interface IDevice <a name="IDeviceInterface" />

Esta interface permite um acesso mais direto ao dispositivo do que através dos agentes de site. As chaves geradas pelo dispositivo são imediatamente devolvidas ao chamador. Primeiro chame cqp::remote::IDevice::WaitForSession, depois cqp::remote::IDevice::RunSession. Chame cqp::remote::IDevice::EndSession para parar de gerar chave.

### HSMs <a name="HSMs" />

[HSMs](https://en.wikipedia.org/wiki/Hardware_security_module) são dispositivos de armazenamento que são cofres digitais fisicamente seguros. Existe uma interface padrão para eles chamada [PKCS#11](https://en.wikipedia.org/wiki/PKCS_11). Cada fabricante tem suas próprias interfaces e o suporte para PKCS#11 é irregular, no entanto, existe uma implementação de software que usamos como referência chamada [SoftHSM2](https://www.opendnssec.org/softhsm/). A classe cqp::keygen::HSMStore fornece uma implementação que vincula o cqp::SiteAgent com a interface cqp::IBackingStore.

### Interface IKey <a name="IKeyInterface" />

Os sites fornecem chaves para muitos endpoints (os armazenamentos de chave disponíveis podem ser recuperados chamando cqp::remote::IKey::GetKeyStores), eles podem ser solicitados usando a interface cqp::remote::IKey. Uma vez que uma nova chave tenha sido solicitada, o outro lado só pode recuperá-la como uma chave existente - isso evita conflitos e uso indevido de chaves.

### Criptografia <a name="Encryption" />

Mais detalhes sobre implementações específicas podem ser encontrados em:
* [Tunnels](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/Tunnels.md)

### Relatórios <a name="Reporting" />

As alterações nos valores do sistema são publicadas externamente através da interface cqp::remote::IReporting e internamente com a classe cqp::stats::Stat. Você pode se registrar para todas as estatísticas chamando cqp::remote::IReporting::GetStatistics com o campo cqp::remote::ReportingFilter::listIsExclude definido como `true` ou filtros específicos podem ser especificados.

### Pipelines de Processamento <a name="ProcessingPipelines" />

O protocolo [BB84 QKD](https://en.wikipedia.org/wiki/BB84) padrão requer etapas de pós-processamento para transformar as detecções brutas em chaves utilizáveis.

- **Alinhamento** Encontrar o início e o fim da transmissão real.
    + Ajustar diferenças de tempo/deriva etc.
    + Compensar diferenças de fase ou outras entre o transmissor e o receptor, etc
- **Peneiramento** Descartar detecções inválidas
- **Correção de Erros** Corrigir detecções incorretas - sem divulgar os valores
- **Amplificação de Privacidade** Hash da chave para tornar quaisquer bits divulgados inúteis

Um exemplo de um pipeline de processamento pode ser visto em cqp::DummyQKD::ProcessingChain.

## Compilação

As compilações são gerenciadas pelo [sistema de integração contínua](https://about.gitlab.com/product/continuous-integration/) do gitlab definido no arquivo `.gitlab-ci.yml`.

As imagens docker podem ser construídas manualmente executando `setup/makeDocker.sh`.

### Windows

This is work in progress.
Esta configuração foi testada no Windows 10 e Windows Server 2016 com Visual Studio 15 (2016). As seguintes configurações são suportadas

| SO        | VS 2017   | QT Creator    | Codeblocks    |
|:----------|-----------|---------------|---------------|
| Linux     |           | gcc           | gcc           |
| Windows   | MSVC      | MSVC / MSYS2  | MSYS2-Mingw   |

#### IDE

- [Visual Studio 2016][]
    + Execute o script [InstallVcPkg.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/InstallVcPkg.bat) uma vez para instalar o vcpkg em C:\vcpkg
    + Execute o script [SetupMSBuild.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/SetupMSBuild.bat)
    + Abra a solução [cqp.sln](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/cqp.sln)
    + Selecione Build->Solution
- [QT Creator para Windows][]
    + O QT Creator pode usar o compilador nativo da Microsoft ou o MSYS2. Instale o MSYS2 separadamente, você não precisa instalar o compilador minGW que vem com o instalador do QTCreator. Ou instale o [Windows 10 SDK][]
    + No menu de componentes, selecione os componentes para o compilador que você está usando. Exemplo: msvc2017
    + Usando "Open Project", selecione o arquivo `CMakeLists.txt` na base da árvore de origem.
- [MSYS2][] e [Codeblocks][]
    + Instale o pacote [MSYS2][].
    + Execute o script [installMSYS2Dependencies.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/installMSYS2Dependencies.bat)
    + Em Settings->Debugger -> "Create config" chamado "MSYS2 GDB"
        - Altere o depurador para apontar para gdb.exe (exemplo: C:\\msys64\\mingw64\\bin\\gdb.exe)
    + Em Settings->Compiler
        + Copie as configurações do compilador GCC, chame-o de "GCC - Old"
        + Altere o diretório de instalação do Toolchain para o local de instalação mingw64 do MSYS2 (exemplo: C:\\msys64\\   mingw64)
        + Em cada um dos campos em "Program Files", exceto o programa "make", remova o prefixo `mingw32-`.
        + No campo make, adicione a opção -j para permitir compilação multi-core: `mingw32-make.exe -j`
        + Selecione o depurador "MSYS2 GDB" criado anteriormente
        + Se você preferir uma saída legível do compilador, "Other Settings"->"Compiler Logging" para "Task   description"
    + No diretório de compilação do CodeBlock (\\build\\CodeBlocks)
    + Execute o arquivo `SetupCodeBlocks-MSYS2.bat`
    + Abra o arquivo de projeto do CodeBlocks "CQP.cbp".

Se o seu arquivo de projeto tiver uma estrutura de pastas profunda (isso é um bug), pode ser melhorado clicando com o botão direito no workspace e:

- Desmarcando "Display folders as on disk"
- Marcando "Hide Folder Name"

## Citando este software```
@Manual{,
title = {CQPToolkit: A QKD toolkit library},
author = {{Richard Collins, University of Bristol, UK}},
organization = {University of Bristol},
address = {Bristol, UK},
year = 2018,
url = {https://gitlab.com/QComms}
}

Leitura Adicional

Para mais detalhes sobre escrever código para o kit de ferramentas, consulte Coding Guide Questões e problemas, consulte o FAQ

CQPToolkit

Mais Populares