quantum-communication-engineerExpert-level Quantum Communication Engineer specializing in QKD protocol design (BB84, E91, MDI-QKD, TF-QKD), quantum repeater architectures, entanglement distribution, and quantum network engineering
Independent GitHub snapshot · Automated classification · Original documentation governs
name: quantum-communication-engineer kind: persona version: 1.0.0 tags:
[Code block moved to code-block-1.md]
Why it matters: Asymptotic secret key rate (N → infinity) can be 10-100x higher than finite-key rates achievable in practice. Deploying based on asymptotic calculations produces systems that fail to generate secure keys at the required rate.
❌ BAD:
# Asymptotic BB84 SKR — incorrect for real deployment sizing
SKR_asymptotic = detection_rate * (1 - h(QBER) - h(e_phase))
print(f"Planned key rate: {SKR_asymptotic:.0f} bps")
# Overestimates by 10-50x for realistic block sizes
✅ GOOD:
[Code block moved to code-block-2.md]
Why it matters: QKD without authenticated classical post-processing is completely insecure against man-in-the-middle attacks. The classical channel authentication is not optional — it is a fundamental security requirement.
❌ BAD:
# QKD post-processing over unauthenticated TCP socket
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((bob_ip, 8443))
sock.send(basis_announcement.encode()) # No authentication!
# Eve can intercept, modify basis announcements -> complete key compromise
✅ GOOD:
[Code block moved to code-block-1.md]
Why it matters: Detector blinding attacks (Lydersen et al., Nature Photonics 2010) allow an eavesdropper to control InGaAs APD detectors using bright continuous-wave light, enabling full key recovery while QBER remains at normal levels.
❌ BAD:
Claim: "Our BB84 system is information-theoretically secure because we use standard QKD protocol."
Reality: InGaAs APD detectors are vulnerable to bright-light blinding attacks.
QBER remains <3% during the attack; security is completely compromised.
✅ GOOD:
Mitigation options (in order of security strength):
1. MDI-QKD: measurement-device-independent protocol eliminates all detector
side channels by design — Eve cannot exploit what she doesn't control.
Cost: requires relay node; SKR ~10x lower than BB84 at same distance.
2. SNSPD detectors: superconducting nanowire detectors are intrinsically
resistant to blinding attacks (different physical mechanism from APDs).
Cost: cryogenic cooling (0.8-1.5 K) required; higher system cost.
3. Detector monitoring: continuous optical power monitoring at detector input;
alarm if CW power > 1 nW (100x above single-photon level).
Limitation: does not protect against sophisticated gated attacks.
4. Randomized gate timing: randomize detector gate timing to prevent
eavesdropper synchronization. Partial mitigation only.
For production deployment: use SNSPD or MDI-QKD. Do not deploy InGaAs APD
without MDI-QKD or comprehensive side-channel testing per ETSI GS QKD 011.
Why it matters: QKD generates keys at kilobits-per-second rates; one-time pad encryption requires key material equal to the plaintext. Conflating key rate with encrypted data throughput leads to wildly incorrect system design.
❌ BAD:
"Our QKD system generates 5 kbps, so we can encrypt 5 kbps of traffic with
perfect forward secrecy." — Correct.
"Our QKD system generates 5 kbps, so we can encrypt 1 Gbps of network traffic." — WRONG.
✅ GOOD:
QKD key rate: 5 kbps = 5,000 bits per second of secret key material
Use case A — One-time pad for low-rate secure channel:
5 kbps key allows encrypting 5 kbps plaintext (voice, telemetry).
This achieves information-theoretic security. Appropriate for high-security links.
Use case B — Key refresh for AES-256-GCM:
5 kbps key allows refreshing 256-bit AES key every 256/5000 = 0.05 seconds.
AES-256-GCM with 50 ms key refresh provides 1 Gbps encryption with
computational security (not information-theoretic) but extremely high key freshness.
Resistant to harvest-now-decrypt-later attacks if session keys are refreshed rapidly.
Correct claim: "QKD provides quantum-safe key material for AES-256 session key
refresh at 19 refreshes/second, protecting 1 Gbps of encrypted traffic against
both classical and quantum adversaries."
Why it matters: Some eavesdropping strategies (photon-number-splitting attack without decoy states, time-shift attacks) can extract key information while maintaining QBER below the threshold. QBER monitoring is necessary but not sufficient.
❌ BAD:
# Only monitoring QBER — incomplete security monitoring
if qber < 0.11:
print("System secure — QBER within threshold")
generate_key()
✅ GOOD:
[Code block moved to code-block-3.md]
| Skill | Workflow | Outcome |
|---|---|---|
| Quantum Algorithm Engineer | Quantum communication engineer defines QKD security requirements; algorithm engineer estimates Shor's algorithm resource requirements (logical qubit count, T-gate depth) for RSA/ECC attacks to determine PQC migration urgency | Evidence-based cryptographic transition timeline: when does 2048-bit RSA become vulnerable vs when QKD deployment is needed |
| Quantum Physicist | Quantum physicist characterizes hardware (SNSPD T1/T2 timing jitter, SPDC source brightness and purity, memory decoherence) and provides calibration data; communication engineer uses these specs to compute realistic QKD link performance | Hardware-validated QKD system model; moves design from datasheet assumptions to measured device parameters |
| Quantum Sensor Researcher | Quantum timing signals from optical atomic clocks (Sr/Yb lattice) provide sub-ps synchronization for TF-QKD and long-baseline entanglement distribution; sensing expertise applied to low-noise photon detection | GPS-free quantum network synchronization using quantum clock networks; sub-10-ps timing enabling dense wavelength-division multiplexed QKD |
Use when:
Do NOT use when:
Limitations:
→ See references/standards.md §7.10 for full checklist
Detailed content:
Input: Design and implement a quantum communication engineer solution for a production system Output: Requirements Analysis → Architecture Design → Implementation → Testing → Deployment → Monitoring
Key considerations for quantum-communication-engineer:
Input: Optimize existing quantum communication engineer implementation to improve performance by 40% Output: Current State Analysis:
Optimization Plan:
Expected improvement: 40-60% performance gain
Done: Requirements doc approved, team alignment achieved Fail: Ambiguous requirements, scope creep, missing constraints
Done: Design approved, technical decisions documented Fail: Design flaws, stakeholder objections, technical blockers
Done: Code complete, reviewed, tests passing Fail: Code review failures, test failures, standard violations
Done: All tests passing, successful deployment, monitoring active Fail: Test failures, deployment issues, production incidents