Project

General

Profile

Task #1157

Rethink protocol and encoding options of the QKD framework

Added by Oliver Maurhart 12 months ago. Updated 12 months ago.

Status:
Assigned
Priority:
High
Target version:
Start date:
21.12.2016
Due date:
% Done:

0%


Description

The dawning of continuous variable protocols in AIT QKD R10 causes a lot of troubles and discussions.

  • opposed to DV QKD we do now have different protocol values. E.g. snr, holevo-information, transmission, etc. compared to a simple QBER.
  • opposed to DV QKD we now have a variety of different data/base encoding. I.e. the key data may be single bits, but also floats, doubles, dual-bits, triple-bits, signed short, etc.

Currently (ab977297) we do have a solution.

But it is inferior. We mixed protocol details with type encoding of key data which turned out to be two different concepts.

Therefore: rethink protocol and encoding strategies in AIT QKD R10 (again).


Related issues

Related to Feature #1152: What is a reasonable behavior if qkd-pseudo-correction does not find a SNR value in the key? Assigned 05.12.2016
Related to Feature #1133: Add snr to qkd-statistics New 02.11.2016
Related to Bug #1149: remove <discrete> and <continuous> tags from metadata of a fresh key Closed 30.11.2016

History

#1 Updated by Oliver Maurhart 12 months ago

Suggestion 1: introduce a hierarchical scheme of protocols (like "dv/bb84", "cv/qpsk/homodyne").
Suggestion 2: separate protocol and encoding. The bit representation layout in the key may not directly be bound to a protocol, but may be shared by different protocols.
Suggestion 3: "data variant" - in the same protocol we might have different data particles to work on (e.g. Q and P value sets).
Suggestion 4: relax on protocol and encoding mechanisms. Let the user introduce her own protocol and encoding variants.

Examples:

  • protocol = "dv/bb84", encoding = "quad bits" ---> discrete BB84 protocol, key data is 4bit-tuple holding detector clicks, no data variant.
  • protocol = "dv/bb84", encoding = "single bits" ---> discrete BB84 protocol, key data is single bits (eventual final shared bits), no data variant.
  • protocol = "cv/qpsk/heterodyne/q", encoding = "float" ---> continuous QPSK Heterodyne, key data are float values, data variant: "Q"
  • protocol = "cv/qpsk/homodyne/p", encoding = "signed short" ---> continuous QPSK Homodyne, key data are 16 bit values, data variant: "P"
  • protocol = "cv/qpsk/heterodyne/base", encoding = "single bits" ---> continuous QPSK Heterodyne, key data single bits, data variant: "Base: Q or P"
  • protocol = "cv/qpsk/heterodyne/data", encoding = "single bits" ---> continuous QPSK Heterodyne, key data single bits, data variant: "Data: -1 or +1"
  • protocol = "cv/qpsk/heterodyne", encoding = "single bits" ---> continuous QPSK Heterodyne, key data is single bits (eventual final shared bits), no data variant. This has formerly been a "cv/qpsk/heterodyne/..." with some data variant attached. However, due to the process in the QKD pipe the data variants have been merged.

As a consequence:

  • we need new medthods like:
    std:string protocol() const;
    

    and
    void set_protocol(std::string p);
    
  • we need a new way to define key encoding
  • we need a "unknown" protocol and "other" encoding to give users flexibility for their own protocol and encoding ideas.

RFC!

#2 Updated by Christoph Pacher 12 months ago

IMHO this is still a bit ambiguous:

protocol = "dv/bb84", encoding = "quad bits"

I think for Alice AND Bob from the meta-data it should be completely clear what PROTOCOL is being used. The data REPRESENTATION of the other party is probably not useful and may be omitted.

Maybe we could also indicate the ORIGIN of the data
  1. state preparation (typical done by Alice but not existing in an entangled protocol)
  2. measurement result (typical done by Bob, or by both in an entangled protocol)
  3. already post-processed data (i.e. after discretization (analog to digital conversion), or after any qkd modul has modified the data-type (e.g. error correction may modify a float measurement to a bit or integer value)

Something like

protocol = "dv/bb84-entangled", subprotocol = "four detectors", origin = "measurement", encoding = "four bits" or similar would be better.
It should be really clear what the meaning of the original "quad bits" is.

[this looks a bit strange to me:

protocol = "cv/qpsk/heterodyne/ base", encoding = "single bits" ---> continuous QPSK Heterodyne, key data single bits, data variant: "Base: Q or P"
you mean "base data", correct? ]

maybe instead of "single bits", we could use "bit" (like "float") or we could use enums such as:

enum CV_base_encoding : bool {
 Q = false;
 P = true;
};

enum DV_base_encoding : bool {
 plus = false;
 diagonal = true;
};

enum DV_data_encoding : bool {
 no_click = false;
 click = true;
};

Hopefully, this bool enum works... see http://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum?rq=1

tbc

#3 Updated by Oliver Maurhart 12 months ago

Christoph Pacher wrote:

IMHO this is still a bit ambiguous:

protocol = "dv/bb84", encoding = "quad bits"

I think for Alice AND Bob from the meta-data it should be completely clear what PROTOCOL is being used. The data REPRESENTATION of the other party is probably not useful and may be omitted.

Maybe we could also indicate the ORIGIN of the data
  1. state preparation (typical done by Alice but not existing in an entangled protocol)
  2. measurement result (typical done by Bob, or by both in an entangled protocol)
  3. already post-processed data (i.e. after discretization (analog to digital conversion), or after any qkd modul has modified the data-type (e.g. error correction may modify a float measurement to a bit or integer value)

Something like

protocol = "dv/bb84-entangled", subprotocol = "four detectors", origin = "measurement", encoding = "four bits" or similar would be better.
It should be really clear what the meaning of the original "quad bits" is.

Mhm, isn't this too much over-administration of a key? Maybe there's a better, more simple way to do this. I think of

a) KISS: Keep It Simple Stupid.
b) Do not add data unless you are going to test it.

E.g. I do not sense any test for origin in the algorithms. Is it for curiosity or should there be a real test? Since we should demand some intelligence on the QKD admin side. The user orchestrating a pipeline should know on which side he resides and should know how to interconnect modules.


[this looks a bit strange to me:

protocol = "cv/qpsk/heterodyne/ base", encoding = "single bits" ---> continuous QPSK Heterodyne, key data single bits, data variant: "Base: Q or P"
you mean "base data", correct? ]

Mhm, well a "key data" is the data of a key, isn't it? So this is the memory BLOB associated with the key. I should have written "key data are single bits". In this is case the key data (memory blob of the key) are interpreted as single base bits of the heterodyne realm.


maybe instead of "single bits", we could use "bit" (like "float") or we could use enums such as:

[...]

Hopefully, this bool enum works... see http://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum?rq=1

Sure this works:

$ cat bool_enum.cpp
#include <iostream>

enum b_t: bool {
    foo = false,
    bar = true
};

int main(int argc, char ** argv) {

    b_t b;

    b = b_t::foo;
    std::cout << "b=" << b << std::endl;

    b = b_t::bar;
    std::cout << "b=" << b << std::endl;

    std::cout << "sizeof(b)=" << sizeof(b) << std::endl;

    return 0;
}
$ g++ bool_enum.cpp
$ ./a.out
b=0
b=1
sizeof(b)=1

As a summary, I still suggest to split encoding and protocol. For the protocol we need some flexible scheme. The real impact of the protocol is, that we can deduce the existence of certain values in a key's metadata which are necessary for further computation.

E.g. a "continuous/qpsk/..." protocol will have a transmission value set among others. Something a discrete protocol does not.

I would not split this information across several fields (e.g. subprotocol, origin, etc.) within the key object, since this makes key management unnecessarily complex.

The problem we face is that we should have an error estimation, error correction, privacy amplification, ... qkd-blah instance which is capable of working on any key of any protocol/subprotocl/origin combination. Now, to build a one-fits-all solution is contrary to modern system/software design. Instead this is why God invented object oriented programming.

As a consequence (which seems a radical idea now, but I think this is the way to go):

  • There ain't one module (one error-estimation, one privacy-amplifcation, ...) but there is an abstract error-estimation, an abstract privacy-amplification, etc.
  • The key is read from the previous module and handed out to a object factory.
  • Based on the protocol field the object factor returns the proper object instance (error-estimation discrete, privacy-amplification qpsk/discrete, etc.)
  • The instance further checks if the key does comply to the rules given by the protocol identifier (e.g. if the key states it is a continuous key, then it must have a "continuous" entry in it's metadata).
  • If the protocol does not yield a valid object instance: error (protocol_error).
This approach has several advantages:
PRO:
  • we can easily extend and introduce new error-estimation, error-correction, etc. modules for new protocols.
  • changes for one protocol implementation do not have any impact on other implementations
  • the factory object approach does have the ability to fine check the existence of expected values bound to a given protocol identifier by responsibility delegation to the concrete instance.
Bit we also have:
CON:
  • Slightly more complicated design at first glance
  • Work

But I see the PROs outweighs the CONs by far.

Intended workflow (for e.g. privacy amplification):
  1. key is read by the framework
  2. key is handed out to the module (qkd-privacy-ampliciation)
  3. the key is given to a privacy-amplification-factory which returns abstract privacy-amplification instance
  4. within the factory the protocol field is examined
  5. depending on the protocol field value, the factory instantiates a concrete privacy-amplification module (derived from the abstract class)
  6. the new instance is handed out the key
  7. the concrete instance checks, if the key indeed does fulfill the requirements, i.e. or all the fields given we expect from a key stating a certain protocol value
  8. if this check is ok, the factory returns with the concrete instance
  9. the "process" or "work" method is called and the key is processed

I currently do not see any other way out of our protocol/subprotocol/encoding dilemma.

#4 Updated by Oliver Maurhart 12 months ago

  • Related to Feature #1152: What is a reasonable behavior if qkd-pseudo-correction does not find a SNR value in the key? added

#5 Updated by Oliver Maurhart 12 months ago

#6 Updated by Oliver Maurhart 12 months ago

  • Related to Bug #1149: remove <discrete> and <continuous> tags from metadata of a fresh key added

Also available in: Atom PDF