Add BBM92 entanglement-based QKD protocol#334
Draft
nenadilic84 wants to merge 2 commits intoQuantumSavory:masterfrom
Draft
Add BBM92 entanglement-based QKD protocol#334nenadilic84 wants to merge 2 commits intoQuantumSavory:masterfrom
nenadilic84 wants to merge 2 commits intoQuantumSavory:masterfrom
Conversation
Implement the BBM92 (Bennett-Brassard-Mermin 1992) quantum key distribution protocol as a new protocol in the ProtocolZoo. BBM92 is the canonical application-layer protocol for entanglement distribution networks, turning shared Bell pairs into cryptographic key material. The protocol consumes entangled pairs distributed by the existing EntanglerProt/SwapperProt/EntanglementTracker pipeline. For each pair, both parties independently choose a random measurement basis (Z or X), perform projective measurements via project_traceout!, and record results. Post-processing functions extract the sifted key, estimate QBER, and compute key generation rate. Components: - BBM92Prot: coordinator-style protocol (like EntanglementConsumer) - sifted_key(): extract matching-basis key bits for Alice and Bob - qber_estimate(): quantum bit error rate from the measurement log - keyrate(): average sifted key generation rate - HTML show method with protocol statistics - Comprehensive tests over direct links and repeater chains - Interactive GLMakie/WGLMakie example over a 4-node repeater chain Closes QuantumSavory#137
Contributor
Benchmark Results (Julia v1)Time benchmarks
Memory benchmarks
|
Signed-off-by: Nenad Ilic <nenadilic84@gmail.com>
Member
|
Hi, Nenad! Thank you for the contribution, on a quick skim it looks pretty complete. I noticed that you have submitted a lot of PRs to QuantumSavory, JuliaGraphs, and qojulia this morning. Given the very quick pace, this leads me to believe you have used LLM agents to do so. That is not bad on its own -- I myself use such tools quite a bit -- but it fairly widely accepted that politeness requires disclosing this fact. The main problem is knowing whether I can trust your contributions. An LLM makes it very easy for a PR to look polished while having severe difficult to discover flaws. One of the main signals I used to rely on -- polish correlating with correctness, is not valid anymore. Even worse -- given the type of bugs that LLMs create, reviewing a PR is now actually much more difficult. This also leads to a contributor asymmetry -- it used to be the case that a large PR implied to contributor spent significant effort, while these days large seemingly-polished PRs are easy to generate and they are difficult to treat as anything different from spam, given the immense effort that reviewing requires. As I mentioned though, using an LLM is not disqualifying, but it requires some level of building of trust before I spent the very significant effort of reviewing all of this. If you are ok with these constraints, could you please do the following:
I will provide a review on the merits of the contribution after your answer. Thank you for contributing this and other changes in other organizations, they can be very valuable! And apologies for the less than warm welcome -- it is necessary to defend the quality of these open source projects now that the proliferation of LLM agents is ripping apart the social contract and the community goodwill. |
Author
|
Hey Stefan, I did use LLMs to aid me with coding on these. I'll go over each PR and share what I can recover/remember. I used Claude (Anthropic) via the Claude Code CLI. My workflow was: describe what I want, review the output, fix things, iterate. This PR (BBM92) was the heaviest. I read the paper and studied existing protocols in ProtocolZoo, especially EntanglerProt and SwapperProt. Claude helped scaffold the protocol struct and ConcurrentSim process function, but the measurement logic and key sifting needed manual fixes. Claude kept getting the basis reconciliation wrong. I wrote the tests iteratively, running them, finding failures, fixing the protocol logic until things worked. For #332 (tags/entanglement links): I read through QuantumSavoryMakie.jl and prompted Claude with that code. Main fix was the Makie recipe patterns, Claude didn't match the observable/lift conventions in the repo so I had to rework those. For #333 (ring network): Used firstgenrepeater examples as reference. Claude generated initial scripts, I fixed the network topology to work with RegisterNet and ran both visualization versions locally. What Claude got wrong across these: PR descriptions were mostly LLM-generated (you noticed), Makie observable handling needed several rounds of fixes, BBM92 basis logic was wrong on first pass, some ConcurrentSim @yield patterns were off, CHANGELOG entries were too wordy. I've read all the code and can walk through any part of it. Ran all tests locally, ran each example script. This one took the most real time, especially the protocol logic. Happy to address anything specific you find during review. |
This was referenced Feb 13, 2026
Contributor
|
Hi @nenadilic84, thanks for your submission! I have a few initial points that I’d like you to address:
There are a few other things, but I will do a more thorough review once these questions are answered. Please note that LLM should not be used to address these points! |
Member
|
Hi, @nenadilic84 ! I will mark this as a draft to keep my review queue a bit more organized. Do not hesitate to get it back into ready-for-review state if you feel like continuing it. |
Member
|
Closing this due to inactivity -- if you decide to take it back up, please do not hesitate to reopen it. Thanks for looking into it! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements the BBM92 (Bennett-Brassard-Mermin 1992) entanglement-based quantum key distribution protocol as a new protocol in the
ProtocolZoo, addressing issue #137.BBM92 is the canonical application-layer protocol for entanglement distribution networks. It consumes shared Bell pairs from the existing
EntanglerProt→SwapperProt→EntanglementTrackerpipeline, with each party independently choosing a random measurement basis (Z or X) and performing projective measurements. Post-processing extracts the sifted key, estimates the quantum bit error rate (QBER), and computes key generation rate.Components
BBM92Prot: Coordinator-style protocol (likeEntanglementConsumer) that queries forEntanglementCounterparttags between Alice and Bob, measures in random bases viaproject_traceout!, and logs resultssifted_key(log): Extracts matching-basis key bits for both partiesqber_estimate(log): Computes QBER from the measurement logkeyrate(log): Average sifted key generation rate (bits/time)showmethod displaying protocol statistics (total measurements, sifted bits, QBER, key rate)period=nothing), and edge casesTest results (local, Julia 1.12)
Closes #137