PaperlayerView exact revision on arXiv

Source-linked AI summary

Quantum Fire with Delegated Cloning

Rohit Chatterjee, Ananta Mukherjee, Vir Pathak, Supartha Podder

arXiv:2610.03593v2quant-phcs.CR

TL;DR

This paper addresses how to restrict flame cloning to designated users rather than every flame holder. It gives two classical-oracle constructions, with torch-fire limiting how many noncommunicating parties can clone a fresh challenge using a fixed number of torches.

  • Problem

    Prior quantum-fire constructions let every flame holder clone, leaving issuers without a way to restrict cloning to designated parties.

    Source: §1 · pp. 3–4

  • Method

    The paper gives two classical-oracle constructions: one uses a classical secret cloning key, and torch-fire uses reusable quantum cloning keys called torches.

    Source: §1.1 · p. 4, §1.1.2 · p. 5

  • Results

    With m torches, no efficient adversary can enable more than m noncommunicating parties to each clone a fresh challenge flame, except with negligible probability.

    Source: §1.1.2 · p. 5

  • Takeaways & Limitations

    Torch-fire’s quantum keys address the loss of control caused by classical cloning keys that can be copied and handed out arbitrarily.

    Source: §1 · p. 4, §1.1.2 · p. 5

    Both constructions are in the classical-oracle model, and torch-fire’s untelegraphability guarantee covers parties without shared entanglement who communicate classically, not arbitrary LOCC protocols.

    Source: §1.1.2 · p. 6

Abstract

from arXiv · show

Quantum fire is a recently introduced cryptographic primitive consisting of efficiently preparable quantum states, called \emph{flames}, that admit efficient cloning but resist efficient telegraphing, namely reconstruction via classical communication without preshared entanglement. In all prior constructions of quantum fire, cloning is a public operation that requires no separate key and every holder of a flame state can clone it. For applications to access control, however, an issuer may wish to delegate cloning to designated quantum servers while withholding this capability from other flame holders. To address this, we introduce \emph{delegatable quantum fire}, in which cloning requires a separate key. We give two constructions in the classical-oracle model. Our first construction uses a classical secret key which enables cloning, and any user with the entire key may clone successfully. Our second construction, which we call \emph{torch-fire}, uses quantum cloning keys, called \emph{torches}, which enable cloning while remaining unaffected in the process but cannot otherwise be split or delegated to enable additional cloning. An efficient adversary given $m$ torches cannot, except with negligible probability, enable more than $m$ noncommunicating parties to each clone a fresh, independently issued challenge flame. The adversary may jointly process its resources before separating the parties and distribute arbitrarily entangled registers among them. Both constructions are in the oracle model, relying on public classical oracles that allow queries in quantum superposition.

1 Introduction

Quantum fire separates efficient cloning from efficient telegraphing, but its prior public-cloning model gives every flame holder the same capability. This work introduces key-gated cloning, including reusable quantum torches designed to restrict how many locations can clone.

1 Introduction

  • The paper addresses the public-cloning model by asking whether cloning can require a key and whether reusable quantum keys can limit cloning locations.An adversary may jointly process keys and flames, then distribute entangled registers among separated parties.Source: §1 · pp. 3–4, §1.1 · p. 4

1.2 Related Work

  • Both constructions use classical oracles queried in superposition; instantiating them in the standard model remains an open direction.Other open directions include publicly verifiable classical-key delegation, unbounded cloning generations with a classical key, and stronger LOCC security for torch-fire.Source: §1.1 · p. 4, §1.1.2 · p. 6

1.1.1 Delegation via a Classical Secret Key

  • A classical secret key enables privately verifiable flames to be cloned for up to O(log λ) generations, while keyless efficient quantum adversaries cannot clone them and flames remain untelegraphable.The same secret key is used for verification and cloning, and each flame tracks its remaining generations.Source: §1.1.1 · p. 4

1.1.2 Delegation via an Uncloneable Quantum Key: Torch-Fire

  • Torch-fire separates publicly verifiable flames from reusable quantum torches, which are returned essentially undisturbed after cloning and support polynomially many successive cloning operations.A flame combines a quantum-fire state with an anchor; coherent oracle queries using valid signatures from both the anchor and a torch enable cloning.Source: §1.1.2 · p. 5
  • With m torches, no efficient adversary can enable more than m noncommunicating parties to clone fresh challenge flames, except with negligible probability.The guarantee holds for any polynomial number of parties and alongside untelegraphability, even against parties holding torches.Source: §1.1.2 · p. 5
  • A general extraction lemma relates threshold acceptance across separated oracle computations on entangled inputs to local witness extraction, supporting the global non-proliferation proof.The lemma handles polynomially many locations and threshold events without requiring the parties to communicate.Source: §1.1.2 · p. 6

1.2 Related Work

  • Torch-fire builds on prior public-key quantum fire, while its location-limited capability differs from quantum key-fire, where the flame itself is a functional key anyone may clone.The paper also distinguishes its torches from consumed-on-use quantum tokens and leasing schemes by seeking reusable capability that cannot spread to more locations than there are torches.Source: §1.2 · p. 7

2 Technical Overview

The overview develops delegated cloning constructions based on one-shot signatures, including a classical secret-key approach and torch-fire with an anchor and reusable quantum cloning keys. It also presents a global non-proliferation argument using filtered-acceptance and extraction bounds tied to the underlying signature schemes.

2.1 One-Shot Signatures in the Classical Oracle Model

  • The one-bit one-shot signature scheme of Shmueli and Zhandry [SZ25] generates a signing state as a uniform coset superposition, and signing measures its first qubit, restoring the state with the dual oracle after a wrong bit.The dual oracle is needed for signing but not key generation or signature verification; public testing of the signing-state projector enables strong forgery from two passing registers.Source: §2.1 · p. 8

2.2 Delegation via a Classical Secret Key

  • Withholding the dual oracle D makes cloning a keyed operation: D enables signing, while holders with only P and P−1 can verify signatures but cannot sign arbitrary messages.Flames are signature chains; cloning consumes the parent signing state to authorize two fresh child keys, and verification bounds chain depth by O(log λ).Source: §2.2 · p. 9

2.3 Torch-Fire

  • Torch-fire attaches an independently generated one-shot-signature anchor to each CGS flame, so producing two accepted flames requires passing the anchor’s rank-one verification test.Anchors use independent oracle collections indexed by flame labels, allowing access related to one flame to be disabled without affecting others.Source: §2.3 · p. 11
  • A torch-fire cloning call uses coherent anchor, torch, and CGS signatures to query Γ, returning the torch essentially undisturbed with two flame copies.A hybrid over polynomially many calls shows that one torch can be reused to clone polynomially many times.Source: §2.3 · p. 12
  • Torch-fire untelegraphability reduces to CGS fire because the flame’s accepting effect is bounded by CGS verification’s accepting effect.The reduction simulates Γ using the public CGS interface and discards the anchor from its output flame.Source: §2.3 · p. 12

2.4 Global Non-Proliferation

  • Distinct flame labels bind answered Γ queries to a torch, and extracting valid torch signatures from m + 1 successful locations would forge against the one-shot signature scheme underlying the torches.With distinct labels, the extracted messages differ; among m + 1 signatures, two must use the same issued torch or one must use an unissued torch key.Source: §2.4 · pp. 12–13
  • An efficient extraction lemma compares threshold acceptance with threshold witness extraction across polynomially many separated locations, even when their inputs are entangled.The construction combines witness-sampling, filtering, and an alternating-projector extractor; the threshold comparison avoids guessing which locations succeed.Source: §2.4 · pp. 13–15
  • The lemma’s error depends on post-filter acceptance of modified computations, not on finding probability, and is bounded separately through anchor security.The anchor reduction embeds a one-shot signature challenge in an anchor source and uses acceptance to obtain two distinct signatures.Source: §2.4 · p. 15
  • To embed the anchor challenge, the reduction disables pre-split queries to its uniformly random challenge label; bounds the resulting input change by 2Q_pre 2^-λ/2.The challenge label is unknown to the adversary before the split.Source: §2.4 · pp. 15–16
  • Security of the long-message one-shot signature scheme underlying the torches makes obtaining witnesses for m + 1 distinct labels negligible.The reduction embeds the challenge oracles as the torch source; m + 1 witnesses imply either two signatures on distinct messages under one issued torch or a signature under an unissued torch.Source: §2.4 · p. 16
  • For any constant c, efficient extractor and filter choices make the probability that at least m + 1 parties succeed O(λ^-c), hence negligible.The success probability does not depend on those parameter choices, and c is arbitrary.Source: §2.4 · p. 16

3 Preliminaries

This section establishes the paper’s notation for sets, sampling, security parameters, and quantum states. It also defines the operator, measurement, and oracle-query conventions used in the later analysis.

Basic Notations

  • A function is negligible when it eventually falls below the inverse of every polynomial in the security parameter λ.The section writes an unspecified negligible function as negl(λ).Source: §3 · p. 16

Notations for Quantum Computing

  • Quantum states are represented by unit vectors or density operators, with joint registers modeled by tensor products and reduced states obtained by partial trace.The section permits subnormalized states with trace at most one.Source: §3 · pp. 16–17

Projectors and Measurements

  • Projectors describe measurement outcomes, while quantum effects encode test acceptance probabilities as Tr(Eρ).For an isometry followed by an acceptance projector, the acceptance effect is E = V†ΠV.Source: §3 · p. 17

Classical Oracles Queried in Superposition

  • A classical oracle queried in superposition acts as a unitary that XORs the function value into an answer register, with its action on superpositions fixed by linearity.Oracle-aided QPT algorithms have polynomially bounded size and query count; the oracle functions need not be efficiently evaluable.Source: §3 · pp. 17–18

BBBV hybrid bound

  • The BBBV hybrid bound compares final states of two executions whose oracle queries differ only on specified query-register supports.The passage sets up the query-by-query comparison using projectors onto those supports.Source: §3 · p. 18

4 Cryptographic Building Blocks

This section develops cryptographic building blocks in the classical-oracle model, defining one-shot signatures and quantum fire and describing signature constructions and the public-key quantum-fire interface. It also presents CGS fire through an authority-restricted public oracle interface, with public verification and cloning, and states its correctness and untelegraphability guarantees.

4.1 One-shot signatures (OSS)

  • OSS uses a classical verification key and a quantum signing register, with classical signatures and deterministic classical verification; strong security forbids distinct valid message-signature pairs.The strong one-shot condition allows the messages to match if the signatures differ.Source: §4.1 · p. 19
  • The one-bit OSS construction uses a coset superposition as its signing key and achieves correctness at least 1 - e(λ), where e(λ) = 2^-λ + 2^-(n-r), plus strong security against polynomial-query quantum adversaries.The signing key is |W_y⟩ for a uniformly sampled verification key y.Source: §4.1 · pp. 21–22
  • For polynomial-length messages, the bit-by-bit construction satisfies correctness and strong one-shot security against quantum adversaries making polynomially many total oracle queries.It composes one-bit schemes componentwise, using an independent random function to map messages to bit strings.Source: §4.1 · pp. 22–23
  • Bartusek et al. [BGMS25b] prove that Construction 4.7 satisfies delayed collapsing, as formalized for the oracle distribution of Construction 4.2 and a two-stage QPT adversary.Source: §4.1 · pp. 23–24

4.2 Quantum fire

  • Public-key quantum fire uses classical oracles queryable in superposition, public verification, and a public cloning algorithm that returns two flames associated with the same serial number.The issuer generates a public and secret key and issues independently randomized serial-number/flame pairs.Source: §4.2 · p. 24
  • The untelegraphability definition considers two quantum adversaries with a separable initial joint state independent of the oracles and setup randomness; shared classical randomness is permitted.The adversaries make polynomially many oracle queries in total.Source: §4.2 · p. 25

A Common Oracle Interface:

  • Flames are prepared as verification-key and coset states with the verification-key register Y left unmeasured.The flame register is F = YU, and the preparation circuit returns its remaining workspace to zero.Source: A Common Oracle Interface · pp. 26–27
  • Public queries use tags with valid hash values and one-bit OSS signatures to enable the public oracles to return oracle responses.The authority retains direct access to G; public access is provided through the public oracle collection.Source: A Common Oracle Interface · pp. 26–27
  • Verification measures Y and may destroy the alleged flame, but this is compatible with verification returning only a bit.A party wishing to retain the flame can keep a cloned copy.Source: A Common Oracle Interface · p. 28
  • CGS fire satisfies verification correctness, cloning correctness, and untelegraphability at security parameter µ.The theorem applies to Construction 4.22 with the oracles of Construction 4.18.Source: A Common Oracle Interface · p. 29
  • The section also records stronger cloning correctness, coherent tag correctness, and a verification-effect guarantee.The supplied passages identify these guarantees but omit their defining equations.Source: A Common Oracle Interface · p. 29

5 Quantum Fire with Classical Cloning Key

This section defines privately verifiable quantum fire in which a classical cloning token enables delegated cloning. The construction is untelegraphable and supports logarithmically many cloning generations, while excluding cloning by non-delegated adversaries.

Definition

  • The variant uses a classical token for delegated cloning and is privately verifiable; cloning is impossible without the token.Its syntax slightly deviates from the earlier quantum-fire definition.Source: §5 · p. 29

Construction and security

  • O(log(μ)) generations of cloning are available to key holders, while efficient adversaries without the cloning key are uncloneable and flames remain untelegraphable.The security theorem states the scheme is c log(μ)-clonable and uncloneable for non-delegated cloners.Source: §5 · pp. 30–31

Correctness and security

  • Correctness follows from the correctness of the underlying one-shot signature scheme.The security proof reduces uncloneability for non-delegated cloners to one-shot signature unforgeability.Source: §5 · pp. 31, 36

6 Definition: Torch-Fire

Torch-fire is defined relative to classical oracles queryable in superposition, with an issuing authority that creates quantum torches and independently issued flames. Its syntax specifies public flame verification and cloning with a torch, alongside correctness requirements.

Scheme syntax

  • The authority’s setup produces a public verification key, secret key, and indexed quantum torch registers; the sampled classical oracles remain fixed and are queryable in superposition.Setup also outputs classical torch identifiers.Source: §6 · pp. 36–37
  • Each spark invocation independently generates a classical serial number and quantum flame, and public verification checks a flame against its serial number and public key.The scheme also defines cloning as a public algorithm that takes a torch, torch identifier, serial number, and flame, and returns a torch and two flames.Source: §6 · p. 37

Correctness

  • Correctness is required for flame verification and for cloning across polynomially many repetitions.The definition specifies verification correctness and cloning correctness as separate guarantees.Source: §6 · p. 37

Global non-proliferation

  • The scheme’s global non-proliferation definition distributes a chosen set of m torches before parties separate, then tests them on independently issued challenge flames.The parties’ registers may be arbitrarily entangled before the split, after which communication and further issuance are forbidden except for the challenge inputs.Source: §6 · pp. 37–38

6. The challenger checks

This section sets out security experiments for torch-fire, including a two-party classical-communication test for untelegraphability and a non-proliferation property. In particular, global non-proliferation implies that parties given no torches cannot clone a flame except with negligible probability.

Global non-proliferation

  • With no torch supplied, global non-proliferation implies that cloning a flame succeeds only with negligible probability.The property is stated for adversaries under the global non-proliferation experiment.Source: §6 · p. 38

Untelegraphability

  • The two parties’ initial state must be separable and independent of the challenger’s setup randomness, though shared classical randomness is permitted.This constraint is specified for the two-party experiment.Source: §6 · p. 38
  • The untelegraphability experiment lets one party receive an issued flame, exchange classical messages with another party, and have that party return a serial number and quantum register for verification.The parties make polynomially many oracle queries, and the returned serial number need not have appeared during the spark-query phase.Source: §6 · p. 39

7 Construction of Torch-fire

The section presents the torch-fire construction, combining an OSS anchor and torch-enabled gated affine queries with a CGS flame state and public cloning procedure. It establishes correctness for verification and cloning, and analyzes untelegraphability against polynomial-query-bounded adversaries.

7.1 Construction

  • Each flame contains an independently generated OSS anchor and a CGS flame state, while a torch is an OSS signing state.The flame serial pairs the anchor’s source label and verification key; the flame register combines the anchor and CGS state.Source: §7.1 · pp. 39, 41
  • Cloning handles the two flame components separately: public CGS fire cloning duplicates the CGS state, while torch-gated affine queries prepare a second anchor.The anchor preparation uses the existing anchor, torch, and one cloned CGS state as resources.Source: §7.1 · pp. 39, 45
  • The authority prepares each torch from private OSS generation data and retains private access to the CGS generation oracle used to issue flame states.The torch verification keys are published, but the torch generation data and direct access to the CGS generation oracle are not.Source: §7.1 · pp. 40, 43
  • An affine query is answered only when the anchor and torch provide valid OSS signatures and the query carries a valid CGS tag.The signatures authenticate messages determined by the flame serial and torch key; the tag check uses the encoded query.Source: §7.1 · pp. 42–43
  • The four torch-fire algorithms TF.SetupO, TF.SparkO, TF.VerO, and TF.CloneO are QPT with the specified oracle access and private data for polynomially bounded R.Source: §7.1 · p. 45

7.2 Correctness

  • Construction 7.4 satisfies verification and cloning correctness for polynomially bounded R, with verification error negligible in λ.The construction verifies the anchor and CGS flame separately; cloning uses the torch, anchor, and a CGS flame to prepare a second anchor.Source: §7.2 · pp. 46–47

7.3 Untelegraphability

  • Theorem 7.8 establishes torch-fire untelegraphability for polynomially bounded R and polynomial-query-bounded adversaries.The proof reduces to CGS untelegraphability by discarding the output anchor.Source: §7.3 · pp. 48–49

3. Simulating issuance and output.

The proof simulation prepares assigned torches and answers spark requests with fresh CGS keys. It leaves the parties’ classical messages unchanged and compares the torch-fire and CGS success probabilities.

3. Simulating issuance and output.

  • Each Bi prepares its assigned torches from sampled matrices and shifts, yielding the required joint state by Lemma 7.5.Source: §3 · p. 49
  • For each spark request, B1 obtains a fresh K from the CGS challenger and samples ℓ from {0, 1}^λ, as in Construction 7.4.Source: §3 · p. 49
  • The simulation keeps the classical messages exchanged between AO1 and AO2 unchanged.Source: §3 · p. 49
  • The success-probability comparison uses that the CGS effect B is the same for every serial s.The passage invokes Theorem 4.23 for the comparison.Source: §3 · p. 50

8 Extraction and Global Non-proliferation

This section develops extraction methods for separated oracle computations on possibly entangled inputs and applies them to prove global non-proliferation for Construction 7.4. The reductions combine an anchor argument with a torch-based extraction bound to rule out more than m valid, distinct-label witnesses, even when an adversary jointly processes its resources before separating parties.

8 Extraction and Global Non-proliferation

  • The global proof converts successful cloning at separated locations into valid torch signatures for the locations’ challenge labels.It proves global non-proliferation for Construction 7.4 in the per-instance oracle model.Source: §8 · p. 50

8.1 Extraction from separated computations

  • For every d, the extraction lemma compares the probability that at least d noncommunicating parties accept with the probability that at least d local extractors output witnesses.The computations may start on a possibly entangled input, and the extractors use only modified oracles.Source: §8.1 · pp. 51, 53
  • Each local extractor receives only its location’s input and fresh workspace, uses modified-computation unitaries and witness tests, and does not communicate with other locations.The procedure is QPT when the stated implementation assumptions hold and β and 1/δ are polynomially bounded.Source: §8.1 · p. 53
  • On an input component with witness-sampling probability u, β successful filter cycles occur with probability (1-u)^(2β).The filter suppresses components with large witness-sampling probability.Source: §8.1 · pp. 52, 54
  • After the initial witness-test rejection, the extractor alternates witness tests with measurements of the sampler subspace; each further round conditionally fails with probability 1 − 2u(1 − u).On a witness-test acceptance, it measures and outputs the query input.Source: §8.1 · pp. 56–57
  • The bound established in (78) together with this result proves (72); each local extractor performs one initial witness test and at most t = ⌈2β/δ2⌉ additional rounds, with polynomial complexity under the assumption of Remark 8.1.Source: §8.1 · p. 61

8.2 From cloning to torch signatures

  • The proof reduces cloning to two OSS security steps: accepted anchors imply a strong one-bit forgery, while m torches cannot yield torch signatures for m + 1 distinct challenge labels.Extraction connects these steps even when locations share entanglement; the signatures authenticate messages containing the challenge labels.Source: §8.2 · p. 61
  • Distinct challenge labels produce distinct signed messages of length 1 + λ + 2Lr, even when their witnesses use the same torch key.The relevant information is the challenge label ℓi; the key associated with a witness need not match the challenge key.Source: §8.2 · p. 62
  • The preparation phase must also disable affine access for the challenge label, because pre-split queries under the original oracle could already leak information used after the split.The label is uniform and unknown during preparation, and the stated lemma bounds the effect of replacing those pre-split queries.Source: §8.2 · pp. 63–64
  • The signature-forgery reduction succeeds with probability tied to 1 − 2^{-(n−r)}; with n − r = 24λ and polynomial N and Qpre, its resulting forgery probability is negligible.On joint success, the two independently sampled values differ with probability 1 − 2^{-(n−r)}, yielding distinct signatures for the same key.Source: §8.2 · p. 65
  • The witness-extraction bound rules out an efficient procedure outputting valid witnesses for m + 1 distinct labels, even after jointly processing pre-split and challenge flames.The procedure receives only the m issued torch registers and may make polynomially many public-oracle queries.Source: §8.2 · p. 66

8.3 Global non-proliferation

  • Construction 7.4 satisfies global non-proliferation for polynomially bounded R, m, and N with 0 ≤ m ≤ R, by combining the anchor and torch reductions.The anchor reduction has negligible filtered-acceptance error, while the torch reduction rules out m + 1 extracted witnesses with distinct labels.Source: §8.3 · p. 67

1. Apply extraction to the ideal experiment (Equation (62)). Let

The proof applies a threshold extraction lemma in the ideal experiment, then uses torch-signature security to rule out m + 1 extracted witnesses for distinct labels. It concludes that the ideal and real winning probabilities are negligible.

Extraction in the ideal experiment

  • The extraction lemma bounds the probability that at least d parties accept by the probability that at least d local extractors produce witnesses, without requiring independent outcomes.The extractors use only the modified oracles.Source: §1 · p. 67
  • m + 1 extraction successes yield witnesses for m + 1 distinct labels, which would violate long-message one-shot signature security when only m torches were issued.The ideal experiment enforces distinct challenge labels.Source: §1 · p. 68
  • Returning to the real experiment changes success only through repeated spark labels, whose probability is bounded using (62).The ideal experiment declares failure on repeated labels.Source: §1 · p. 68
  • Both error terms are negligible for polynomially bounded v and N, so the ideal experiment's winning probability is negligible.The conclusion follows by choosing the extraction parameters and applying the extraction bound and torch-signature security.Source: §1 · p. 68

A.1 Coherent Tag Generation

The coherent tag circuit signs using a verification key held in the flame register without measuring that key. It combines signing and oracle-response operations while retaining the auxiliary registers needed to uncompute the tag.

A.1 Coherent Tag Generation

  • For each bit b, the coherent signing circuit acts on the signing workspace and signature registers, with the verification-key register Y controlling the selected circuit.The circuit acts on Y, U, E_b, and Σ_b without measuring Y.Source: §A.1 · p. 72
  • The oracle query unitary uses Y, Σ_b, and Z as inputs and writes its response into R_b while leaving those inputs unchanged.The query register holds the query; the response registers and signing workspaces are initialized to zero.Source: §A.1 · p. 72
  • The resulting tag is held in (Y, R_0, R_1), with auxiliary registers retained so the tag circuit can later be uncomputed on the same registers.The procedure applies the oracle response operation and then reverses the selected signing circuit.Source: §A.1 · pp. 72–73

A.2 Implementation Details of Cloning a flame

Each cloning-oracle call is implemented by computing a tag, querying the public unitary, and then uncomputing the tag while preserving the answer. The query unitary takes the encoded query and tag registers and returns the answer in C.

A.2 Implementation Details of Cloning a flame

  • For each oracle call, the implementation encodes the query in Z and initializes fresh signing-workspace, signature, and response registers for both bits.The answer register is C.Source: §A.2 · p. 73
  • The public query unitary UO2 takes (Z, Y, R_0, R_1) as inputs and writes its answer into C.For a valid tag, O2 returns the value of the encoded forward or inverse call.Source: §A.2 · p. 73
  • After the query, the implementation applies (Fire.TagO)† to the same registers used to form the tag, leaving C untouched.This reverses tag generation while retaining the oracle answer.Source: §A.2 · p. 73

B.1 Coherent execution of an affine query

The procedure prepares a coherent request for an affine value, using the anchor, torch, and CGS flame part. It queries the oracle with the prepared tag and signatures, then reverses the preparation while leaving the answer register untouched.

B.1 Coherent execution of an affine query

  • The circuit coherently encodes the affine input as a request while leaving the input register unchanged.Fresh auxiliary registers are initialized to zero before the request is formed.Source: §B.1 · p. 73
  • The CGS flame part prepares a tag for the request, and coherent long-message signing circuits prepare two signatures with their workspaces retained.The tag uses Fire.TagO; the signing circuits use each source’s digest oracle and component D interfaces.Source: §B.1 · pp. 73–74
  • The oracle checks the signatures and tag before returning the affine value, after which the preparation is inverted without measuring the answer or request data.All workspace is retained until inversion; the signatures and tag remain coherent throughout.Source: §B.1 · p. 74

B.2 Proof of Lemma 7.6

Lemma 7.6 compares the implemented procedure with an ideal affine-query unitary. The proof uses correctly encoded requests that pass the checks and the fact that preparation preserves the input and does not act on the answer register.

B.2 Proof of Lemma 7.6

  • The ideal affine-query unitary writes the affine value into the answer register and leaves every other register unchanged.For fixed a, c, and e, the proof writes the affine function as f(u) = affine_ac,e(u).Source: §B.2 · p. 74
  • The prepared request is correctly encoded, and the norm of the component failing the checks is at most d.The proof invokes the signing and tag bounds for this estimate.Source: §B.2 · p. 74
  • On requests passing the checks, the oracle action equals the ideal affine query, and preparation commutes with that query because it preserves the input and does not act on the answer.The expectation bound is then obtained from bounds (50) and (52).Source: §B.2 · p. 74
Loading 2610.03593v2…