Private Delegated Quantum Computing for User-Level and Industry-Level Settings

Dit artikel introduceert een modulaire hiërarchie van particuliere gedelegeerde quantumcomputingprotocollen die zijn toegesneden op gebruikers- en industriële contexten, en die privacygaranties en resourcevereisten systematisch categoriseert op basis van clientcapaciteiten, adversariële modellen en specifieke lekveronderstellingen.

De kern

Stel je voor dat je een geheim recept hebt voor de lekkerste taart ter wereld, maar je hebt geen keuken groot genoeg om hem te bakken. Je moet de ingrediënten naar een professionele bakkerij (de "Server") sturen om het bakken uit te voeren. Je kunt de bakker echter niet je geheim recept laten zien, want dan zouden ze het kunnen stelen, of erger: ze zouden de ingrediënten kunnen veranderen en je een slechte taart kunnen serveren zonder dat je het merkt.

Dit artikel is een blauwdruk voor hoe je je geheim recept naar een bakkerij stuurt die je niet volledig vertrouwt, waarbij verschillende strategieën worden gebruikt afhankelijk van hoeveel "keukengerei" (quantum middelen) je thuis hebt.

Hier is de uiteenzetting van hun oplossing, met behulp van alledaagse analogieën:

Het Kernprobleem: De "Zwarte Doos" Keuken

In de wereld van quantum computing is de "bakkerij" (de Server) krachtig maar duur. De "thuisbakker" (de Client) wil deze gebruiken maar moet hun data (het recept) en hun specifieke instructies (de hoeken van de taartlagen) verborgen houden.

Het artikel stelt een hiërarchie van oplossingen voor. Denk hierbij aan een menu met beveiligingsniveaus, waarbij het beveiligingsniveau afhangt van hoeveel apparatuur je thuis hebt.

De Vier Beveiligingsniveaus (De Protocollen)

1. De Client met "Volledige Keuken" (Protocol 1)

Wie je bent: Je hebt een fatsoenlijke thuiskeuken met een volledige set gereedschappen (een M-qubit quantumcomputer). Je kunt zelf kleine taarten bakken, maar de grote taart heeft de professionele bakkerij nodig.
De Strategie: Je versleutelt je ingrediënten met een "Quantum One-Time Pad" (QOTP). Dit is alsof je je ingrediënten in een doos stopt die elke keer dat je het aanraakt van slot verandert.

• Wat de Bakker ziet: Ze zien een doos met ingrediënten en instructies om ze op een specifieke, publieke manier te mengen (zoals "roer met de klok mee"). Ze kunnen niet zien wat er in de doos zit.
• Wat jij doet: Je houdt de geheime onderdelen van het recept (de niet-standaard kruiden) voor jezelf. Wanneer de bakker klaar is met de publieke menging, neem je de doos terug, open je het slot, voeg je je geheime kruid toe, sluit je het opnieuw af en stuur je het terug.
• De Haken: De bakker weet nog steeds hoeveel ingrediënten je hebt gebruikt en wanneer je ze hebt gestuurd, maar niet wat ze zijn.

2. De Client met "Eén Hulpmiddel" (Protocol 2)

Wie je bent: Je hebt geen volledige keuken. Je hebt slechts een paar losse hulpmiddelen (onafhankelijke single-qubit apparaten). Je kunt thuis geen twee ingrediënten samen mengen.
De Strategie: Je gebruikt nog steeds het geheime slotkistje (QOTP), maar nu moet je heel voorzichtig zijn met hoe je dingen verstuurt.

• De Truc: Om de vorm van je recept te verbergen, gebruik je "Routing Permutaties". Stel je voor dat je 5 potten met ingrediënten hebt. Je schudt uit welke pot naar welk plankje in de bakkerij gaat. De bakker ziet potten verplaatsen, maar omdat je ze hebt geschud, kunnen ze niet zeggen of je een taart of een pasteitje maakt door alleen naar de volgorde van de potten te kijken.
• De Haken: Je moet constant potten heen en weer wisselen, wat tijd kost.

3. De "Minimalistische" Client (Protocol 3)

Wie je bent: Je hebt bijna geen gereedschap. Je kunt alleen dozen vergrendelen en ontgrendelen, maar je kunt de ingrediënten er zelfs niet in draaien.
De Strategie: Dit is het slimste deel. Je kunt de hoek van een rotatie (zoals "draai de knop 45 graden") niet zelf verbergen door het zelf te doen. Dus gebruik je een truc met "Geheime Code Deling".

• De Analogie: Stel je voor dat je de bakker moet vertellen om een knop te draaien, maar je kunt niet zeggen "45 graden". In plaats daarvan zeg je hen om hem "10 graden" en "35 graden" apart te draaien. Maar hier is de draai: je vertelt de bakker ook in het geheim om een van hen terug te draaien (negatief teken).
• De Magie: De bakker ziet twee draaiingen: +10 en +35. Maar vanwege de geheime "terug" instructie die jij vasthoudt, komt de echte wiskunde uit op 45. De bakker weet niet welke draaiing de echte was en welke de "terug" was.
• De Haken: Dit werkt alleen als de bakker niet kan uitzoeken welke twee draaiingen bij dezelfde geheime instructie horen. Je verbergt dit door de volgorde van de draaiingen te schudden en "dummy" draaiingen te gebruiken die er echt uitzien maar niets doen.

4. De "Puur Klassieke" Client (Protocol 4)

Wie je bent: Je hebt helemaal geen quantum hulpmiddelen. Je bent gewoon een persoon met een laptop.
De Strategie: Je kunt de dozen niet zelf vergrendelen. Dus huur je twee concurrerende bakkerijen (Server 1 en Server 2) en een neutrale manager (Common Node) in.

• De Opzet: Je splitst je geheim recept in twee helften. Je geeft de ene helft aan Bakker A en de andere helft aan Bakker B. De Manager houdt de "sleutel" om ze weer samen te voegen.
• De Regel: Bakker A en Bakker B mogen niet met elkaar praten. De Manager wordt vertrouwd om de sleutels te schudden zodat geen enkele Bakker het volledige plaatje kent.
• De Haken: Als Bakker A, Bakker B en de Manager allemaal besluiten samen te werken en hun notities te delen, is je geheim verloren. Het systeem is gebaseerd op het feit dat ze niet samenzweren.

De "Val" Laag (Verificatie)

Hoe weet je of de bakker niet heeft bedrogen? Misschien hebben ze het recept niet gestolen, maar hebben ze gewoon een verbrande taart gebakken.
De auteurs suggereren een "Val" systeem.

• De Analogie: Stel je voor dat je de bakker een paar "dummy" ingrediënten stuurt die er precies hetzelfde uitzien als je echte, maar je weet precies wat ze moeten worden (bijvoorbeeld: "Deze specifieke ei moet veranderen in een perfecte bol").
• De Check: Als de bakker een misvormde bol terugstuurt, weet je dat ze bedrogen hebben of een fout hebben gemaakt. Omdat de dummy ingrediënten willekeurig tussen de echte zijn gemengd, weet de bakker niet welke de vallen zijn. Ze moeten eerlijk zijn met alles om niet gepakt te worden.

De "Leakage" Realiteitscheck

Het artikel is zeer eerlijk over wat het niet doet. Het geeft toe dat terwijl de bakker de ingrediënten (de data) niet kan zien, ze nog steeds bepaalde dingen kunnen raden op basis van:

• Timing: Hoe lang het bakken duurde.
• Grootte: Hoeveel potten er werden gebruikt.
• Structuur: De algemene vorm van het recept (bijvoorbeeld: "Het ziet eruit als een taart, niet als soep").

Het artikel noemt dit "Leakage-Dependent Privacy". Dit betekent: "We verbergen de geheime details, maar we geven toe dat de bakker het algemene type gerecht kan raden tenzij we extra opvulling en ruis toevoegen om dat ook te verbergen."

Samenvatting

Dit artikel belooft geen magisch schild dat je onzichtbaar maakt voor een superkrachtige hacker. In plaats daarvan biedt het een modulaire toolkit:

1. Als je een quantumcomputer hebt: Gebruik de "Slotkist" methode.
2. Als je beperkte hulpmiddelen hebt: Gebruik de "Schudden" en "Geheime Code Deling" methoden.
3. Als je geen hulpmiddelen hebt: Gebruik de "Twee Bakkerijen + Manager" methode.
4. Voor iedereen: Voeg "Vallen" toe om bedriegers te betrappen.

Het is een praktische gids voor het gebruik van krachtige quantumcomputers vandaag de dag zonder je geheimen prijs te geven, met de erkenning dat perfecte geheimhouding moeilijk is, maar "voldoende" geheimhouding haalbaar is met de juiste mix van trucs.

Technische samenvatting

Technische Samenvatting: Private Gedelegeerde Kwantumberekening voor Gebruikers- en Industrieniveaus

1. Probleemstelling

Toegang tot kwantumhardware blijft een knelpunt voor individuele gebruikers en industrieën vanwege de hoge kosten voor het bouwen, bedienen en onderhouden van kwantumapparatuur. Gedelegeerde Kwantumberekening (DQC) biedt een oplossing waarbij een client met beperkte middelen berekeningen delegeren aan een krachtige server. Een kritieke uitdaging is echter het behoud van de privacy van de invoergegevens, uitvoergegevens en de beschrijving van de berekening (structuur en parameters) van de berekening.

Bestaande benaderingen, zoals Measurement-Based Blind Quantum Computation (MBQC) en Circuit-Based Blind Quantum Computation (CBQC), vereisen vaak dat de client aanzienlijke kwantumcapaciteiten bezit (bijvoorbeeld het genereren van graf-toestanden of het opslaan van alle qubits) of vertrouwen op specifieke vertrouwensmodellen. Bovendien verwarren standaard privacydefinities vaak verschillende soorten geheimhouding (toestandsprivacy versus structurele privacy) of veronderstellen ze universele blindheid die mogelijk niet haalbaar is met beperkte client-middelen.

Dit artikel adresseert de behoefte aan een modulaire hiërarchie van protocollen voor private gedelegeerde kwantumberekening die is toegesneden op variërende client-capaciteiten, variërend van volledig capabele multi-qubit-apparaten tot puur klassieke controllers. Het werk onderscheidt expliciet tussen het beschermen van de kwantumtoestand (via encryptie) en het beschermen van de circuitstructuur (via compilatie en routing), terwijl het de specifieke lek-annames verduidelijkt die voor elk nodig zijn.

2. Methodologie en Kader

De auteurs stellen een op middelen gebaseerde hiërarchie voor waarbij de keuze van het protocol afhangt van de kwantumcapaciteiten van de client ($M$ qubits) en de aard van de bewerkingen (Clifford versus non-Clifford). Het kader rust op verschillende kerntechnieken:

2.1 Kernprivacymechanismen

• Quantum One-Time Pad (QOTP): De basis voor toestandsprivacy. De client versleutelt qubits met willekeurige Pauli $X$ en $Z$-sleutels. Onder het gezuiverd semi-eerlijk model, als de sleutels vers, geheim en uniform zijn, is de gereduceerde dichtheidsmatrix van de server maximaal gemengd, waardoor geen informatie over de toestand wordt onthuld.
• Clifford Sleutelupdates: Publieke Clifford-bewerkingen (H, S, CNOT, CZ) kunnen door de server worden uitgevoerd op versleutelde gegevens. De client werkt het Pauli-frame klassiek bij zonder de gegevens te ontsleutelen.
• Afhandeling van Non-Clifford: De basisprotocollen beperken de server tot Clifford-bewerkingen. Non-Clifford-poorten (bijvoorbeeld $T$, generieke rotaties) worden afgehandeld via:
  • Lokale Executie: De client ontsleutelt, past de poort toe, versleutelt opnieuw en geeft de qubit terug (voor clients met lokale capaciteit).
  • Decompositie: Het breken van non-Clifford-poorten in publieke Clifford-lagen en lokale single-qubit-poorten.
  • Hoek-Ambigüiteitsprimitieven: Voor beperkte clients worden private rotatiehoeken verborgen via deling op een eindig rooster en tekenrandomisatie.

2.2 Structurele Privacy en Lekken

Het artikel introduceert een strikte lek-relatieve privacydefinitie. Privacy is niet absoluut, maar relatief aan een gedeclareerde lekfunctie $L(D)$.

• Structurele Privacy: Het verbergen van de circuitindeling, poortposities en routing. Dit wordt bereikt via gerandomiseerde compilers, opvulling met dummy- of annulerende poorten en routing-permutaties.
• Transcript-niveau Ambigüiteit: Voor beperkte clients definieert het artikel "hoek-ambigüiteit" in plaats van universele blindheid. Door finite-grid routing-hidden sign-randomized $r$-share sharing te gebruiken, ziet de server geldige rotatie-aandelen maar kan de logische hoek niet uniek bepalen vanwege verborgen tekens (geïnduceerd door QOTP-sleutels) en verborgen groepering (geïnduceerd door routing-permutaties).

2.3 De Protocolhiërarchie

Het artikel definieert vier verschillende protocoltakken op basis van client-middelen:

1. Protocol 1 (Volledig Capabele $M$-qubit Client):

   • Capaciteiten: Kan $M$ qubits opslaan en lokale multi-qubit-poorten uitvoeren.
   • Mechanisme: De client stuurt batches van $M$ qubits naar de server. De server voert publieke Clifford-bewerkingen uit op versleutelde gegevens. Private/non-Clifford-poorten worden lokaal uitgevoerd door de client (ontsleutelen-toepassen-opnieuw-versleutelen) als de ariteit $\le M$.
   • Privacy: QOTP-toestandsprivacy; structurele privacy hangt af van de compiler.

2. Protocol 2 (Client met $M$ Onafhankelijke Single-Qubit Apparaten):

   • Capaciteiten: $M$ onafhankelijke apparaten; geen lokale verstrengelende poorten.
   • Mechanisme: Vergelijkbaar met Protocol 1, maar beperkt tot lokale single-qubit-poorten. Multi-qubit-bewerkingen worden gedelegeerd als publieke Clifford-lagen. Structurele verberging wordt bereikt via poortrandomisatie (routing-permutaties) tussen apparaten om logische draadtoewijzingen te verbergen.
   • Privacy: QOTP-toestandsprivacy; structurele privacy is gebaseerd op routing-permutaties en opvulling.

3. Protocol 3 (Beperkte Single-Qubit Apparaten):

   • Capaciteiten: Apparaten beperkt tot Pauli $X, Z$ (QOTP-maskers) en routingcontrole; kunnen geen willekeurige rotaties uitvoeren.
   • Mechanisme: Gebruikt een finite-grid routing-hidden sign-randomized $r$-share hoek-ambigüiteitsprimitief. Private rotatiehoeken worden gecompileerd naar een eindig rooster, opgesplitst in $r$ aandelen met verborgen tekens (via QOTP $X$-sleutels) en verborgen groepering (via routing).
   • Privacy: QOTP-toestandsprivacy; transcript-niveau hoek-ambigüiteit (geen universele blindheid) onder aannames van verborgen tekens en verborgen routing.

4. Protocol 4 (Klassieke Client):

   • Capaciteiten: Puur klassiek; geen directe kwantuminteractie.
   • Mechanisme: Gebruikt twee computationele servers ($S_1, S_2$) en een gemeenschappelijke node ($R$). De client onderhoudt een persistent matching-hidden split-QOTP. De gemeenschappelijke node verbergt de matching tussen sleutelaandelen die door $S_1$ en $S_2$ worden gehouden.
   • Privacy: Toestandsprivacy onder persistent split-QOTP plus $\epsilon_{key}$-sleutelverberging (onder de aanname van niet-totale collusie). Hoekprivacy is transcript-niveau onkoppelbaarheid via geschudde $r$-share sharing.
   • Aanname: De volledige coalitie $\{S_1, S_2, R\}$ is uitgesloten; de gemeenschappelijke node is vertrouwd of side-channel gecontroleerd.

2.4 Trap-gebaseerde Detectielaag

Om kwaadaardige afwijkingen aan te pakken (waarbij de server het protocol niet volgt), stelt het artikel een ingebouwde statistische detectielaag voor.

• Methode: De client compileert "verifier-blokken" (met bekende antwoorden of simuleerbare uitkomsten) en mengt deze met datablokken via private herlabeling en routing.
• Garantie: Onder onderscheidbaarheidsaannames kan de server niet alleen datablokken targeten. De detectiekans hangt af van de dichtheid van verifierslots en de soundness van de verifiersmodus (bekend antwoord, simuleerbaar, of echo).
• Beperking: Dit is een statistische detectielaag, geen volledige malicious-securitybewijs of authenticatiemechanisme.

3. Belangrijkste Bijdragen

1. Op Middelen Geïndexeerde Protocolhiërarchie: Een gestructureerde set protocollen (Protocollen 1–4) die specifieke client-capaciteiten (van $M$-qubit tot klassiek) koppelt aan geschikte privacymechanismen, waardoor een "one-size-fits-all"-benadering wordt vermeden.
2. Lek-relatieve Privacydefinities: Een formeel kader dat QOTP-toestandsprivacy (informatietheoretisch) scheidt van structurele privacy (compiler-afhankelijk) en hoek-ambigüiteit (transcript-afhankelijk). Het artikel verduidelijkt dat "blindheid" vaak een functie is van gedeclareerd lekken en compiler-randomisatie, en geen inherent kenmerk van de encryptie alleen.
3. Routing-hidden Sign-randomized Primitief: Een nieuwe techniek voor beperkte clients om private rotatiehoeken te verbergen via deling op een eindig rooster, verborgen tekens (via QOTP) en routing-permutaties, waardoor transcript-niveau ambigüiteit wordt geboden zonder volledige kwantumtoestandsblindheid te vereisen.
4. Split-QOTP voor Klassieke Clients: Een multi-party protocol (Protocol 4) dat klassieke clients in staat stelt toestandsprivacy te bereiken via een split-sleutelmodel over niet-colluderende servers, waarbij client-zijde QOTP wordt vervangen door een persistent matching-hidden invariant.
5. Expliciete Beveiligingsscope: Het artikel schetst expliciet wat elk protocol niet claimt (bijvoorbeeld geen universele blindheid voor Protocol 3, geen malicious security voor de basisprotocollen, geen onvoorwaardelijke structurele verberging zonder compiler-aannames).

4. Resultaten en Voorbeelden

Het artikel demonstreert de toepasbaarheid van deze protocollen via drie algoritmische voorbeelden:

• Grover's Algorithm: Toont hoe de oracle (structurele privacy) en de diffusie-operator kunnen worden gedelegeerd. Private structuur wordt verborgen via opvulling en routing; non-Clifford-componenten (CCZ) worden lokaal afgehandeld of via decompositie.
• QAOA (Quantum Approximate Optimization Algorithm): Illustreert de scheiding tussen private parameters (hoeken in $RZ$ en $RZZ$) en publieke structuur. Het verstrengelende $RZZ$-gedeelte wordt gedelegeerd als publieke Clifford, terwijl private hoeken lokaal worden afgehandeld of via het hoek-ambigüiteitsprimitief. Het artikel benadrukt de noodzaak om optimizer-transcripten op te vullen om lekken van convergentie-eigenschappen te voorkomen.
• Quantum Neural Networks (QNN): Demonstreert het verbergen van invoer-encoderingshoeken en modelgewichten. Private rotaties worden lokaal uitgevoerd of via het sign-randomized primitief, terwijl verstrengelende poorten worden gedelegeerd.

Beveiligingsanalyse:
Het artikel levert formele bewijzen voor:

• Toestandsprivacy: Onder het gezuiverd semi-eerlijk model met verse QOTP-sleutels (Stelling 1).
• Hoek-ambigüiteit: Grenzen aan de grootte van de kandidaatset voor private hoeken gegeven verborgen tekens en groepering (Propositie 5.1, 5.4).
• Detectiekans: Hypergeometrische grenzen voor de kans op het detecteren van kwaadaardige afwijkingen op basis van verifiersdichtheid (Propositie 6.2, 6.3).

5. Betekenis en Claims

De auteurs positioneren dit werk niet als een vervanging voor Universal Blind Quantum Computation (UBQC) of Verifiable Blind Quantum Computation (VBQC) in hun sterkste regimes, maar als een modulair, op middelen geïndexeerd kader voor praktische settings waarin clients gedeeltelijke of geen kwantumcapaciteiten hebben.

• Bescheidenheid van Claims: Het artikel stelt expliciet dat het op zichzelf geen universele blindheid of malicious security biedt.
  • Protocol 3 biedt "transcript-niveau hoek-ambigüiteit", geen universele blindheid.
  • Protocol 4 vertrouwt op de niet-totale-collusie-aanname en side-channel controle; het biedt geen malicious security zonder aanvullende verificatielagen.
  • Structurele Privacy is conditioneel aan de gerandomiseerde compiler en gedeclareerde lekken; het is geen onvoorwaardelijke garantie tegen alle sidekanalen.
• Praktijktoepasbaarheid: De hiërarchie stelt industrieën en gebruikers in staat een protocol te selecteren dat past bij hun specifieke hardwarebeperkingen (bijvoorbeeld een bedrijf met een kleine kwantumprocessor versus een gebruiker met alleen een klassieke computer), terwijl ze de precieze afwegingen in privacy en overhead begrijpen.
• Toekomstige Richtingen: De auteurs merken op dat toekomstig werk zich zou kunnen richten op het verminderen van de overhead voor qubittransmissie en het versterken van non-Clifford- en detectiecomponenten voor fault-tolerante settings.

Kortom, het artikel biedt een rigoureuze, genuanceerde taxonomie van private gedelegeerde kwantumberekening, waarbij de exacte voorwaarden worden verduidelijkt waaronder privacy kan worden bereikt voor clients met variërende niveaus van kwantumresources, terwijl de beperkingen van elke benadering expliciet worden begrensd.