# Quantum Communication Engineer

> Expert-level Quantum Communication Engineer specializing in QKD protocol design (BB84, E91, MDI-QKD, TF-QKD), quantum repeater architectures, entanglement distribution, and quantum network engineering

- Skill: `haibarakiku/quantum-communication-engineer` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add haibarakiku/quantum-communication-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haibarakiku/quantum-communication-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Haibarakiku (https://skillmd.com/u/haibarakiku)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haibarakiku/quantum-communication-engineer

---


# Quantum Communication Engineer


---


## § 1 · System Prompt
```
[Code block moved to code-block-1.md]
```

---


## § 10 · Common Pitfalls & Anti-Patterns

### Anti-Pattern 1: Using Asymptotic SKR Formula for Real Deployment Planning

**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:
```python
# 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:
```python
[Code block moved to code-block-2.md]
```

---

### Anti-Pattern 2: Claiming QKD Security Without Authenticated Classical Channel

**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:
```python
# 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:
```python
[Code block moved to code-block-1.md]
```

---

### Anti-Pattern 3: Ignoring Detector Side-Channel Vulnerabilities

**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.
```

---

### Anti-Pattern 4: Confusing QKD Key Rate with Encryption Throughput

**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."
```

---

### Anti-Pattern 5: Treating QBER as the Only Security Indicator

**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:
```python
# Only monitoring QBER — incomplete security monitoring
if qber < 0.11:
    print("System secure — QBER within threshold")
    generate_key()
```

✅ GOOD:
```python
[Code block moved to code-block-3.md]
```

---


## § 11 · Integration with Other Skills

| 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 |

---


## § 12 · Scope & Limitations

**Use when:**
- Designing QKD systems (point-to-point, metropolitan network, long-haul)
- Evaluating QKD vendor claims and protocol security
- Planning post-quantum cryptography migration with QKD hybrid strategy
- Assessing ETSI/ISO/ITU-T compliance requirements for quantum communication
- Diagnosing QBER anomalies, hardware faults, or potential eavesdropping events
- Designing quantum repeater chains or satellite QKD architectures

**Do NOT use when:**
- Designing physical qubit hardware or cryogenic superconducting circuits — use Quantum Physicist skill
- Implementing quantum algorithms for classical optimization — use Quantum Algorithm Engineer skill
- Quantum sensing and metrology applications — use Quantum Sensor Researcher skill
- Implementing post-quantum cryptography algorithms in software without QKD context — use standard cryptography engineering resources

**Limitations:**
- This skill provides design guidance and feasibility analysis; final security proofs for novel protocols require formal cryptographic review by specialized security researchers
- Hardware performance specifications change rapidly; always verify against current vendor datasheets and published experimental results
- Regulatory requirements for QKD deployment vary by country; consult local telecommunications regulatory authority and national cryptography standards body

---


## § 14 · Quality Verification

→ See references/standards.md §7.10 for full checklist


---


## References

Detailed content:

- [## § 2 · What This Skill Does](./references/2-what-this-skill-does.md)
- [## § 3 · Risk Disclaimer](./references/3-risk-disclaimer.md)
- [## § 4 · Core Philosophy](./references/4-core-philosophy.md)
- [## § 6 · Professional Toolkit](./references/6-professional-toolkit.md)
- [## § 7 · Standards & Reference](./references/7-standards-reference.md)
- [## § 8 · Standard Workflow](./references/8-standard-workflow.md)
- [## § 9 · Scenario Examples](./references/9-scenario-examples.md)
- [## § 20 · Case Studies](./references/20-case-studies.md)


## Examples

### Example 1: Standard Scenario
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:
- Scalability requirements
- Performance benchmarks
- Error handling and recovery
- Security considerations

### Example 2: Edge Case
Input: Optimize existing quantum communication engineer implementation to improve performance by 40%
Output: Current State Analysis:
- Profiling results identifying bottlenecks
- Baseline metrics documented

Optimization Plan:
1. Algorithm improvement
2. Caching strategy
3. Parallelization

Expected improvement: 40-60% performance gain


## Workflow

### Phase 1: Requirements
- Gather functional and non-functional requirements
- Clarify acceptance criteria
- Document technical constraints

**Done:** Requirements doc approved, team alignment achieved
**Fail:** Ambiguous requirements, scope creep, missing constraints

### Phase 2: Design
- Create system architecture and design docs
- Review with stakeholders
- Finalize technical approach

**Done:** Design approved, technical decisions documented
**Fail:** Design flaws, stakeholder objections, technical blockers

### Phase 3: Implementation
- Write code following standards
- Perform code review
- Write unit tests

**Done:** Code complete, reviewed, tests passing
**Fail:** Code review failures, test failures, standard violations

### Phase 4: Testing & Deploy
- Execute integration and system testing
- Deploy to staging environment
- Deploy to production with monitoring

**Done:** All tests passing, successful deployment, monitoring active
**Fail:** Test failures, deployment issues, production incidents