CQP Tool kit

Il sistema fornisce vari componenti per integrare QKD in un sistema di sicurezza. È scritto in C++11 ma utilizza interfacce GRPC che permettono l'integrazione con molti linguaggi diversi.

Avvio Rapido

Per eseguire il software in modo nativo, è possibile:

scaricare e installare i pacchetti deb per Ubuntu oppure
clonare il sorgente, assicurandosi che i sottomoduli siano aggiornati, e compilare localmente

Per clonare il sorgente inclusi i sottomoduli:```bash git clone --recurse-submodules [email protected]:QComms/cqptoolkit.git

> Se hai clonato senza usare `--recurse-submodules`, i sottomoduli possono essere aggiornati eseguendo `git submodule update --init` dalla cartella sorgente.

Ecco un elenco delle dipendenze necessarie per compilare il progetto (leggi più avanti per maggiori dettagli sull'installazione):```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

Test rapido

Dalla cartella di build, per eseguire due siti (sullo stesso computer locale) ciascuno con un dispositivo QKD, avvia prima il sito "A" avviando un agente del sito e collegandovi un "dummy driver" di Alice: (Se i binari sono stati installati, ometti i percorsi dei comandi dalle istruzioni.)```bash ./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8000 & ./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8000 -a

Le prestazioni, l'affidabilità e la compatibilità di ogni strumento possono variare in base al tuo caso d'uso specifico e all'ambiente.```bash
./src/Tools/SiteAgentRunner/SiteAgentRunner -p 8001 &
./src/Drivers/DummyQKDDriver/DummyQKDDriver -r localhost:8001 -b

Questo non inizierà a generare la chiave immediatamente, poiché questo sistema è progettato per essere controllato da un sistema di gestione; la connessione deve essere stabilita con il comando SiteAgentCtl.

Innanzitutto, puoi verificare l'elenco dei dispositivi disponibili con:```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -d -c localhost:8000

che dovrebbe produrre qualcosa di simile a questo per impostazione predefinita, se *SiteAgentRunner* e *DummyQKDDriver* fossero avviati senza specificare un argomento di file di stringa JSON di configurazione:```json
{
 "url": "<hostname>:8000",
 "devices": [
  {
   "config": {
    "id": "dummyqkd__0__16_alice",
    "kind": "dummyqkd"
   },
   "controlAddress": "<hostname>:34219"
  }
 ]
}

e la porta 8001 dovrebbe produrre qualcosa di simile a```json { "url": ":8001", "devices": [ { "config": { "id": "dummyqkd__0__16_bob", "side": "Bob", "kind": "dummyqkd" }, "controlAddress": ":38367" } ] }

- Ora, la connessione può ora essere effettuata chiamando:```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -j localhost:8001

Questo creerà un singolo salto da un sito al successivo; ancora, rotte più complesse possono essere definite utilizzando l'opzione -a con una stringa JSON che specifica il percorso.

Dopo alcuni secondi dovrebbe essere disponibile una chiave, che può essere testata richiedendo una chiave.

NOTA: Il parametro -k deve essere l'url mostrato nei dettagli del secondo sito, non "localhost:8001"```bash ./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -k hostname:8001

Il collegamento può essere fermato con il comando unjoin:```bash
./src/Tools/SiteAgentCtl/SiteAgentCtl -c localhost:8000 -u localhost:8001

Non che la chiave sia ancora disponibile anche se la generazione è cessata, fintanto che gli agenti del sito sono in esecuzione. Può essere richiesta con lo stesso comando di richiesta chiave sopra.

Esempio di crittografia

Con gli agenti del sito e i driver avviati sullo stesso computer locale come descritto sopra e dopo aver avviato il collegamento per lo scambio di chiavi, è possibile testare anche le funzionalità di crittografia.

Per prima cosa, avviare un lato della "VPN" su bob, che rimarrà in ascolto sulla porta 9010 e si collegherà al deposito chiavi di Bob:``` ./src/Tools/QTunnelServer/QTunnelServer -p 9010 --keystore-url=hostname:8001

- Ora avvia il lato Alice della VPN, definendo il tunnel da creare. Verranno aperte due porte, una per ogni lato sulle porte 9000 e 9001, tutto ciò che entra in queste porte verrà crittografato, trasferito all'altro lato, decrittografato e prodotto sull'altra 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

Qualsiasi cosa che utilizza comunicazioni tcp può quindi usare questa porta, netcat è un semplice programma che invierà dati attraverso le porte, avvia una da un lato:``` nc localhost 9000

e uno sull'altro:```
nc localhost 9001

Qualsiasi cosa digitata in un lato apparirà sull'altro quando viene premuto Invio. Ispezionando i pacchetti che viaggiano attraverso le porte 9000 e 9001 con uno strumento come wireshark, si vedrà che i dati sono crittografati e verrà mostrato l'ID della chiave utilizzato.

Altre forme di connessione possono essere create, invece di tcpserv:

Avanzamento

Funzionalità pianificate e completate

Si spera che questo progetto possa dimostrarsi utile sia per il lavoro di ricerca scientifica che per grandi progetti. Maggiori dettagli sul progetto si trovano in questo articolo.

Per contribuire a questo progetto, consulta il file Contribution.

Installazione

Il sistema attualmente funziona su Linux - Windows è pianificato per il futuro. Il metodo più semplice è la compilazione dal sorgente al momento

Immagine Docker

C'è un'immagine docker pronta all'uso nel gitlab registry. Puoi eseguirla con sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime. Aggiungi un comando alla fine per eseguire direttamente qualcosa, ad esempio per eseguire una simulazione della generazione di chiavi QKD con QKDSim:```bash sudo docker run -it --rm registry.gitlab.com/qcomms/cqptoolkit/runtime AlignmentTests

### Ubuntu 18.04+

Puoi installare i pacchetti binari da [Gitlab](https://gitlab.com/QComms/cqptoolkit/-/jobs/artifacts/master/download?job=package%3Adeb). Estrai il file zip e installa gli strumenti con `dpkg`, si lamenterà delle dipendenze mancanti ma non preoccuparti, la seconda riga le risolverà.```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

Per installare i file di sviluppo (header e librerie statiche) esegui invece sudo dpkg -i build/gcc/CQP-*-Linux-*-dev.deb ; sudo apt install -fy.

Dal sorgente

Naturalmente, se non vuoi cambiare le versioni delle librerie e delle dipendenze di sistema, puoi compilare all'interno di un contenitore docker che ha già tutte le dipendenze installate con:```bash sudo docker run -it registry.gitlab.com/qcomms/cqptoolkit/buildenv

Altrimenti, compilare dal sorgente richiede di installare le dipendenze elencate in `setup/setupbuild.sh`, attualmente funziona per Ubuntu e Arch Linux.

Clona il sorgente da [gitlab](https://gitlab.com/QComms/cqptoolkit.git) con [git][] e compila con [CMake][] e [gnu make](https://www.gnu.org/software/make/):
L'opzione `--recurse-submodules` aggiunge gli extra opzionali - l'accesso ad alcuni di questi è limitato a UoB e ai suoi partner, la compilazione funzionerà anche senza.```bash
git clone --recurse-submodules https://gitlab.com/QComms/cqptoolkit.git

Se vuoi ottenere tutti i sottomoduli e hai i login appropriati, esegui:```bash git submodule update --checkout

Ora, puoi andare nel tuo repository locale e installare le dipendenze con lo script (forse è necessario modificare i permessi del file):```bash
cd cqptoolkit/setup
./setupbuild.sh

Poi, puoi costruire il progetto in una nuova cartella:```bash mkdir build-cqptoolkit cd build-cqptoolkit cmake ../cqptoolkit && nice make -s -j

this can be installed with

sudo make install

Il build utilizza [CMake][] per generare makefile/soluzioni/ecc. per molte piattaforme diverse e viene richiamato da una cartella di build vuota che conterrà tutti i file di output. Le build di debug produrranno pacchetti con suffisso "D".
È possibile controllare il build passando opzioni a cmake, ad esempio `-DBUILD_TESTING=OFF`. Eseguire cmake con l'opzione `-LH` per elencare gli switch disponibili.

Per apportare modifiche e sviluppare la libreria si consiglia di installare [QT Creator](http://doc.qt.io/qtcreator/) e aprire il progetto [selezionando il file CMakeLists.txt](https://codeyarns.com/2016/01/26/how-to-import-cmake-project-in-qt-creator/). È consigliabile utilizzare build paralleli andando su Projects->Build Steps-> Details e aggiungendo `-j<numero>` ai parametri dello strumento, vedere [so](https://stackoverflow.com/questions/8860712/setting-default-make-options-for-qt-creator).
Una volta costruiti, i file si trovano, per impostazione predefinita, allo stesso livello della cartella del progetto denominata `build-<nome progetto>-<piattaforma>-<target>`.

> **Nota su protobuf + QT su Ubuntu**
> La libreria `qt5-gtk-platformtheme` è collegata a una vecchia versione di protobuf che impedirà l'esecuzione dei nostri programmi QT.
> Questa dipendenza opzionale può essere rimossa con `apt-get remove qt5-gtk-platformtheme`

## Esplorare la libreria

    @startuml
        title Panoramica dell'applicazione

        component "Driver dispositivi QKD" as drv
        interface IDevice as idev
        drv - idev

        component "Controllo dispositivo e\n archiviazione chiavi" as sa
        interface IKey as ikey
        sa - ikey
        sa ..> idev

    package "Consumatori di chiavi" as kc {
        component "VPN personalizzata" as tun
        component "Server Web personalizzato" as nginx
        component "Bridge HSM" as hsm
    }
    tun ..> ikey
    nginx ..> ikey
    hsm ..> ikey

    package Utilità {
        component "GUI Config/Controllo" as gui
        component "Simulatori/Test" as sim
        component "Estrazione dati" as stats

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

Di seguito è riportato un diagramma di flusso per aiutare a trovare l'area pertinente, poiché il progetto copre molti aspetti diversi di QKD e gestione delle chiavi - i contributori sono i benvenuti per rendere questo progetto più specializzato.
QKD richiede una qualche forma di comunicazione [non-clonabile](https://en.wikipedia.org/wiki/No-cloning_theorem), solitamente utilizzando singoli fotoni su fibra ottica. Possono operare punto a punto o uno-a-molti, ma hanno intrinsecamente una posizione fisica (dove termina la fibra) - non possono essere virtualizzati! Il punto in cui il fotone viene trasmesso o rilevato è il confine del sistema sicuro - quasi come il [firewall](https://en.wikipedia.org/wiki/Firewall_(computing)) di una rete. Una volta che i fotoni indivisibili sono stati trasformati in una stringa di bit per formare una [chiave simmetrica](https://en.wikipedia.org/wiki/Key_(cryptography)), si applicano le regole standard della sicurezza informatica come autenticazione, controllo degli accessi, ecc. La differenza è che una volta prodotte queste chiavi, ciascun dispositivo QKD possiede un numero che [nessun altro conosce](https://en.wikipedia.org/wiki/Shared_secret) [provato scientificamente](https://arxiv.org/pdf/quant-ph/0003004.pdf).

La natura di questo effetto "firewall" implica che i sistemi che controllano i dispositivi QKD devono essere sicuri e considerati fidati - chiamati anche "nodo fidato" - dove e come tracciare il confine può variare da guardie armate a semplicemente [chiudere a chiave la porta del server room](https://www.youtube.com/watch?v=rnmcRTnTNC8).

Se non riesci a vedere il diagramma sottostante, vai alla [documentazione online](https://qcomms.gitlab.io/cqptoolkit/), può anche essere generata tramite il target `doc`.

    @startuml
    title Da dove iniziare \n

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

    start
    if (Hai un dispositivo QKD?) then (Sì)
        if (Il tuo dispositivo QKD ha un driver?) then (No)
            :Dovrai [[./index.html#CreatingDrivers creare un driver]] che implementi le
            interfacce <b>IDriver</b> e <b>IReporting</b>.;
            if (Usare la libreria?) then (Sì)
                :Vedi l'esempio [[./index.html#RunningDummyQKDDriver DummyQKDDriver]].;
            else (No)
            endif
        else (Sì)
        endif
    else (No)
        :Scopri come eseguire il
        [[./index.html#RunningDummyQKDDriver DummyQKDDriver]];
    endif

    if (Vuoi chiavi per più
    posizioni in una rete?) then (Sì: Siti)
        :[[./index.html#Registering Registra il tuo driver]] con l'agente del sito
        utilizzando l'interfaccia <b>ISiteAgent</b>.
        Le chiavi possono essere ottenute usando l'interfaccia [[./index.html#IKeyInterface IKey]];

        if(Vuoi che le chiavi siano memorizzate/persistenti tra i riavvii?) then (Sì)
            if (Le chiavi devono essere protette?) then (Sì)
                :Usa le opzioni di archiviazione [[./index.html#HSMs HSM]];
                if (Il tuo HSM è supportato?) then (No)
                    :Crea un driver che implementi
                    l'interfaccia <b>IBackingStore</b>.
                    Aggiungi la creazione del driver al
                    <b>BackingStoreFactory</b>;
                else (Sì)
                endif
            else (No)
                : Quando esegui SiteAgentRunner,
                usa l'opzione ""-b file"" o
                imposta ""backingStoreUrl"" su
                ""file:///filename.db"";
            endif
        else (No)
        endif
    else (No: Punto a Punto)
        :Usa l'[[./index.html#IDeviceInterface interfaccia IDevice]] per
        controllare il driver del tuo sistema.
        Quando le chiavi diventano disponibili, verranno
        inviate tramite la chiamata a <b>WaitForSession</b>.;
    endif

    if (Vuoi usare la chiave per qualcosa?) then (Sì)
        :Vedi la [[./index.html#Encryption sezione crittografia]]
        per un esempio di utilizzo dell'[[./index.html#IKeyInterface interfaccia IKey]];
    else (No)
    endif
    stop

    @enduml


### Esecuzione di DummyQKDDriver <a name="RunningDummyQKDDriver" />

Questa sezione è solo un commento sulla funzionalità utile di DummyQKDDriver per simulare l'output di un dispositivo QKD. Si prega di fare riferimento alla sezione successiva per un esempio guidato su come configurare un semplice collegamento con essi.
Come per la maggior parte dei programmi, passare `-h` mostrerà le opzioni disponibili. DummyQKDDriver esegue una serie standard di fasi di post-elaborazione su rilevamenti fotonici simulati utilizzando la classe cqp::DummyQKD. Devono essere eseguite due istanze del programma, una per Alice e una per Bob.

Esegui Bob per primo sulla porta 8000 chiamando:```bash
DummyQKDDriver -b -k 0.0.0.0:8000

Ora esegui Alice, dicendole di connettersi a Bob e iniziare a scambiare la chiave (in modalità manuale):```bash DummyQKDDriver -a -m localhost:8000

Se ha funzionato, riceverai un diluvio di messaggi di errore come questo: `ERROR: OnKeyGeneration No listener for generated key`. Questo perché, sebbene eseguire il sistema in questo modo sia piacevole per vederlo fare qualcosa, non è molto utile: non c'è un posto dove mettere la chiave generata. I driver sono progettati per essere usati da qualcosa.
Il progetto ha un sistema per gestire le chiavi chiamato [Site Agents](#SiteAgents) oppure puoi parlare direttamente ai driver usando l'[interfaccia IDevice](#IDeviceInterface)

### Configurazione degli Site Agents <a name="SiteAgents" />

Gli agenti del sito, i driver e i tunnel VPN devono essere parametrizzati per ogni nodo della rete con file di stringhe JSON, poiché il comando predefinito senza argomenti non specifica tutti i campi necessari di default e funziona solo per test sulla stessa macchina locale.

Gli agenti del sito possono essere eseguiti con SiteAgentRunner, possiamo eseguire due siti con:```bash
SiteAgentRunner -c site-a.json

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

con ogni file JSON che indica opportunamente una porta diversa per Alice e Bob (ad es. 9000/9001). La stringa JSON è simile a questa:```json
		{
		    "name":"",
		    "id":"",
		    "netManUri":"",
		    "bindAddress":"0.0.0.0",
		    "listenPort":9000,
		    "connectionAddress":"",
		    "credentials": {},
		    "useAutoDiscover":false,
		    "backingStoreUrl":"",
		    "fallbackKey":""
		}

Ora possiamo collegare i nostri DummyQKDDriver's, uno per ogni sito:```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

con ogni file JSON che indica appropriatamente una porta diversa per Alice e Bob (ad es. 9000/9001). La stringa JSON si presenta così:```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" }, }

> Il campo dell'indirizzo di controllo può essere 0.0.0.0:0 se non ci sono firewall da gestire. In tal caso, è necessario indicare l'IP effettivo dell'host e scegliere una porta appropriata che il firewall non bloccherà.

Non accadrà ancora nulla poiché gli agenti del sito non sanno cosa fare con questi dispositivi. Possiamo istruirli per iniziare a generare chiavi (-b come begin) inviando il 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"}}]}'

I computer devono essere in grado di risolvere i nomi host e questi dovrebbero essere usati qui al posto dell'indirizzo IP statico. Quindi si dovrebbe modificare il file /etc/hostnames su entrambe le macchine se non è già così.

Questo è un modo verboso di dire collega A a B, ma è molto potente, permettendo di specificare più hop per produrre una chiave sicura end-to-end da una catena di dispositivi. Questa stringa JSON può essere specificata nel campo di configurazione "staticHops" degli agenti del sito per far sì che ciò accada automaticamente una volta che tutti i dispositivi sono disponibili. Il collegamento può quindi essere interrotto con:```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"}}]}'

> Nota il `-e` invece di `-b` per *terminare* il link invece di *iniziarlo*.

Configurazioni più complesse possono essere realizzate implementando da soli l'interfaccia cqp::remote::INetworkManager per emettere i comandi. Il feedback dai dispositivi arriva tramite l'interfaccia cqp::remote::IReporting sullo stesso socket, in modo da poter reagire ai cambiamenti nel sistema. [Qui](#Reporting) puoi vedere come estrarre informazioni dall'interfaccia di reporting con lo strumento StatsDump.

### Creazione dei Driver <a name="CreatingDrivers" />

L'applicazione driver è un ponte tra le interfacce interne del dispositivo (cqp::IQKDDevice) e l'interfaccia esterna cqp::remote::IDevice. La classe cqp::RemoteQKDDevice gestisce la maggior parte del lavoro per te, l'applicazione deve gestire la configurazione e la creazione del dispositivo.

Il vero lavoro consiste nel creare un driver per configurare il dispositivo e leggere la chiave. Se il tuo dispositivo produce solo rilevamenti grezzi, allora dovrai configurare una [pipeline di elaborazione](#ProcessingPipelines) come cqp::DummyQKD o cqp::PhotonDetectorMk1 e cqp::LEDAliceMk1. Se il tuo dispositivo genera chiavi pronte all'uso come cqp::Clavis3Device, devi leggerle e pubblicarle tramite l'interfaccia cqp::IKeyCallback (usa cqp::KeyPublisher).

Entrambi questi approcci richiedono una forma di gestione delle sessioni, fornita da cqp::session::SessionController e cqp::session::AliceSessionController, che implementano l'interfaccia cqp::ISessionController e cqp::remote::ISession e sono utilizzati da cqp::RemoteQKDDevice per avviare e fermare il dispositivo e il suo peer. Di solito sono tutto ciò che serve, ma in alcune situazioni devono essere specializzati per soddisfare i requisiti del 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

### Registrazione di un driver <a name="Registering" />

Al momento della scrittura, tutti i driver possono essere registrati con un agente del sito usando l'opzione `-r`. Questo fa sì che cqp::RemoteQKDDevice chiami cqp::remote::ISiteAgent::RegisterDevice su cqp::SiteAgent, che poi utilizzerà l'interfaccia cqp::remote::ISession per avviare/fermare il dispositivo.

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

Questa interfaccia consente un accesso più diretto al dispositivo rispetto al passaggio attraverso gli agenti del sito. Le chiavi generate dal dispositivo vengono immediatamente restituite al chiamante. Prima chiama cqp::remote::IDevice::WaitForSession, poi cqp::remote::IDevice::RunSession. Chiama cqp::remote::IDevice::EndSession per fermare la generazione della chiave.

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

[Gli HSM](https://en.wikipedia.org/wiki/Hardware_security_module) sono dispositivi di archiviazione che sono cassette di sicurezza digitali fisicamente sicure. Esiste un'interfaccia standard per essi chiamata [PKCS#11](https://en.wikipedia.org/wiki/PKCS_11). Ogni produttore ha le proprie interfacce e il supporto per PKCS#11 è approssimativo, tuttavia esiste un'implementazione software che usiamo come riferimento chiamata [SoftHSM2](https://www.opendnssec.org/softhsm/). La classe cqp::keygen::HSMStore fornisce un'implementazione che collega cqp::SiteAgent con l'interfaccia cqp::IBackingStore.

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

I siti forniscono chiavi per molti endpoint (i key store disponibili possono essere recuperati chiamando cqp::remote::IKey::GetKeyStores), possono essere richiesti usando l'interfaccia cqp::remote::IKey. Una volta che una nuova chiave è stata richiesta, l'altra parte può solo recuperarla come chiave esistente - questo previene conflitti e uso improprio delle chiavi.

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

Maggiori dettagli su implementazioni specifiche si trovano in:
* [Tunnels](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/Tunnels.md)

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

Le modifiche ai valori nel sistema vengono pubblicate esternamente tramite l'interfaccia cqp::remote::IReporting e internamente con la classe cqp::stats::Stat.
Puoi registrarti per tutte le statistiche chiamando cqp::remote::IReporting::GetStatistics con il campo cqp::remote::ReportingFilter::listIsExclude impostato su `true` oppure possono essere specificati filtri specifici.

### Pipeline di Elaborazione <a name="ProcessingPipelines" />

Il [protocollo BB84 QKD](https://en.wikipedia.org/wiki/BB84) standard richiede fasi di post-elaborazione per trasformare i rilevamenti grezzi in chiavi utilizzabili.

- **Allineamento** Trovare l'inizio e la fine della trasmissione reale.
    + Regolazione per differenze/deriva temporali, ecc.
    + Compensazione per differenze di fase o altre differenze tra trasmettitore e ricevitore, ecc.
- **Setacciamento** Eliminare i rilevamenti non validi
- **Correzione errori** Correggere i rilevamenti errati - senza divulgare i valori
- **Amplificazione della privacy** Hashing della chiave per rendere inutili eventuali bit divulgati

Un esempio di pipeline di elaborazione può essere visto in cqp::DummyQKD::ProcessingChain.

## Compilazione

Le build sono gestite dal [sistema di integrazione continua](https://about.gitlab.com/product/continuous-integration/) di GitLab definito nel file `.gitlab-ci.yml`.

Le immagini Docker possono essere costruite manualmente eseguendo `setup/makeDocker.sh`.

### Windows

Questo è un lavoro in corso.
Questa configurazione è stata testata su Windows 10 e Windows Server 2016 con Visual Studio 15 (2016).
Le seguenti configurazioni sono supportate

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

#### IDE

- [Visual Studio 2016][]
    + Esegui lo script [InstallVcPkg.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/InstallVcPkg.bat) una volta per installare vcpkg in C:\vcpkg
    + Esegui lo script [SetupMSBuild.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/SetupMSBuild.bat)
    + Apri la soluzione [cqp.sln](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/vs2017_x64/cqp.sln)
    + Seleziona Build->Solution
- [QT Creator for windows][]
    + QT Creator può usare sia il compilatore Microsoft nativo che MSYS2. Installa MSYS2 separatamente, non è necessario installare il compilatore MinGW fornito con il programma di installazione di QTCreator. Oppure installa il [Windows 10 SDK][]
    + Sotto il menu dei componenti, seleziona i componenti per il compilatore che stai usando. Ad esempio msvc2017
    + Usando "Open Project", seleziona il file `CMakeLists.txt` alla base dell'albero del codice sorgente.
- [MSYS2][] e [Codeblocks][]
    + Installa il pacchetto [MSYS2][].
    + Esegui lo script [installMSYS2Dependencies.bat](https://gitlab.com/qcomms/cqptoolkit/-/blob/master/build/installMSYS2Dependencies.bat)
    + Sotto Settings->Debugger -> "Create config" chiamata "MSYS2 GDB"
        - Cambia il debugger per puntare a gdb.exe (es. C:\\msys64\\mingw64\\bin\\gdb.exe)
    + Sotto Settings->Compiler
        + Copia le impostazioni del compilatore GCC, chiamalo "GCC - Old"
        + Cambia la directory di installazione del toolchain nella posizione di installazione di mingw64 di MSYS2 (es. C:\\msys64\\   mingw64)
        + In ciascuno dei campi sotto "Program Files" eccetto il programma "make", rimuovi il prefisso `mingw32-`.
        + Nel campo make, aggiungi l'opzione -j per permettere la compilazione multi-core: `mingw32-make.exe -j`
        + Seleziona il debugger "MSYS2 GDB" creato in precedenza
        + Se preferisci un output leggibile dal compilatore, "Other Settings"->"Compiler Logging" su "Task   description"
    + Nella directory di compilazione CodeBlock (\\build\\CodeBlocks)
    + Esegui il file `SetupCodeBlocks-MSYS2.bat`
    + Apri il file di progetto CodeBlocks "CQP.cbp".

Se il file del tuo progetto ha una struttura di cartelle profonda (questo è un bug), può essere migliorata facendo clic destro sul workspace e:

- Deselezionando "Display folders as on disk"
- Selezionando "Hide Folder Name"

## Citazione di questo 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}
}

Ulteriori Letture

Per maggiori dettagli su come scrivere codice per il kit di strumenti, consulta la Guida alla codifica Per domande e problemi, consulta le FAQ

//: ##Note a piè di pagina

CQPToolkit

Più Popolari