DFB-PPGSQ: Dynamic Forward/Backward-Private Graph Similarity Matching Query over Encrypted Sensor Graph Databases

1. Introduction

Graph is a natural data structure for describing entities and their internal relationships. In sensor networks, vertices can represent deployed sensors and edges can describe communication links. In industrial IoT, vertices can denote controllers, actuators, events, or data streams, and edges can express operational dependency. In cyber-physical security, a graph may capture provenance paths, alert correlations, or lateral-movement traces. Such graph data are valuable. They are also sensitive. Sensors applications are often resource constrained and security sensitive, so privacy mechanisms must be lightweight enough for practical IoT deployments [1].

Cloud computing provides an attractive platform for storing and querying large graph databases. A client can outsource the graph database and obtain scalable computation. However, the cloud and the client usually belong to different trust domains. The cloud can be honest in executing protocols, but curious about graph structures, labels, queries, and query results. Therefore, graph data are often encrypted before outsourcing. A meaningful encrypted graph service should still support useful operations. Graph similarity matching query is one of them.

Graph similarity matching retrieves data graphs whose distance to a query graph is no larger than a user-specified threshold. It is more tolerant than exact graph matching. This tolerance is necessary in practical sensing and monitoring applications, because data collection is noisy, device states are incomplete, labels can change over time, and inter-sensor dependencies may drift in dynamic environments [2]. A strict exact match may miss useful results. A similarity query can recover them.

Recent privacy-preserving graph similarity matching query schemes have made important progress. PGSim and PrigSim protect graph similarity search over encrypted data by combining graph filters and secure query processing [3,4]. The recent PPGSQ scheme improves efficiency by adopting a branch-based lower bound of edit distance and a branch-tree index [5]. The idea is elegant. A branch captures a center vertex, its incident edge labels, and neighboring vertex labels. Since a single graph edit operation affects a limited number of branches, branch-based filtering gives a tighter lower bound than a global label filter. It can prune more mismatched data graphs.

However, current PPGSQ-style systems are primarily static. This is a narrow assumption for real cloud graph services. A sensor-cloud database changes continuously. New devices join. Old devices disappear. Labels are corrected. An abnormal event is reclassified. A communication edge is removed. The database evolves.

This dynamic setting changes the security problem. If encrypted branch tags remain stable, the cloud can link updates to previous queries. If deleted graphs leave stale index traces, future queries may reveal information about removed objects. If label updates are implemented as delete-and-insert operations without privacy control, the cloud may infer which branch features changed. In long-running services, even small leakages accumulate. The problem is not only efficiency. It is temporal privacy.

This paper asks the following question:

Can we support efficient graph similarity matching over encrypted graph databases while allowing insertions, deletions, label updates, and periodic index re-randomization with forward and backward privacy?

We answer this question by proposing DFB-PPGSQ. The scheme keeps the useful branch-based filtering principle, but redesigns the encrypted index as a dynamic structured-encryption object. The index evolves across epochs. Update tokens are one-time and unlinkable across time. Deleted records are represented by bounded tombstone information and are removed or re-randomized during epoch compaction. The branch-tree index is preserved for efficient pruning, but its labels and counters are refreshed by epoch keys.

The main contributions of this paper are summarized as follows.

• We formulate dynamic forward/backward-private PPGSQ. We extend the static graph similarity matching query model to support graph insertion, graph deletion, vertex/edge label update, and periodic re-randomization. We define the syntax, threat model, leakage functions, and privacy goals for dynamic encrypted graph similarity services.
• We design a dynamic branch-based encrypted index. DFB-PPGSQ constructs epoch-local feature tokens, per-record occurrence handles, encrypted branch-count vectors, update buffers, deletion tombstones, and a re-randomizable branch-tree index. The construction supports efficient filtering without forcing the cloud to traverse the whole database after each update.
• We integrate forward and backward privacy with graph filtering. Search tokens generated before an update cannot be used to identify future inserted or updated branch features. Future queries reveal only bounded information about deleted graphs. Periodic re-randomization further reduces long-term linkability of branch identifiers and tree nodes.
• We provide a reproducible prototype evaluation. We implement the protocol-relevant operations of DFB-PPGSQ in Python, including branch extraction, HMAC-based token generation, update buffering, tombstone filtering, epoch refresh, and generated dynamic sensor-topology workloads. The evaluation compares DFB-PPGSQ with static scan, static branch-tree, feature-only dynamic SSE, rebuild-after-update, and no-re-randomization baselines.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 presents the system model, threat model, notation, and security definitions. Section 4 introduces preliminaries. Section 5 gives the detailed construction of DFB-PPGSQ. Section 6 analyzes security. Section 7 presents the prototype implementation and experimental results. Section 8 concludes this paper.

2. Related Work

2.1. Privacy-Preserving Graph Similarity Query

Graph similarity query is a fundamental graph database operation. Given a query graph and an edit-distance threshold, the server retrieves data graphs that approximately match the query. Graph edit distance has a long history in attributed graph matching and pattern recognition [6,7]. Since exact graph edit distance computation is expensive, practical systems usually follow a filtering-and-refinement framework [8,9,10,11]. A lower bound is first computed to prune impossible candidates. The remaining graphs are refined by a more expensive distance computation.

Encrypted graph similarity query brings an additional constraint. The cloud should not see plaintext labels, graph structures, or query graphs. PGSim uses pivot-based filtering to support privacy-preserving graph similarity query over encrypted outsourced data [3]. PrigSim improves the service model and considers graph similarity search in cloud settings [4]. The recent PPGSQ design replaces heavy pivot computations with branch-based lower-bound filtering and a secure branch-tree index, which improves pruning ability and query efficiency [5].

These schemes are important foundations. Yet they mainly assume that the encrypted graph database is static after setup. In practice, sensor and IoT graphs are dynamic. A static index must be rebuilt after each update, or it must accept privacy leakage caused by stable encrypted identifiers. Neither solution is satisfying.

2.2. Dynamic Searchable Symmetric Encryption

Searchable encryption allows a client to outsource encrypted data while retaining search capability [12,13,14,15]. Later systems improved scalability and expressive queries [16]. Dynamic searchable symmetric encryption further supports document insertion and deletion [17,18,19,20]. Forward privacy, introduced to prevent newly added documents from being linked to previous search tokens, has become a standard requirement for dynamic encrypted search [21]. Backward privacy limits what future searches reveal about deleted documents [22]. Stronger backward privacy notions reduce the leakage from deleted records but often require higher update cost, server-side cleanup, or more complex key evolution.

The DFB-PPGSQ problem is related to dynamic searchable symmetric encryption, but it is not a direct keyword-search problem. A graph similarity query touches many branch features, computes a lower bound, and traverses a tree-shaped index. Insertions, deletions, and label updates modify structured objects rather than independent documents. Therefore, dynamic searchable-encryption ideas must be adapted to graph features, branch counts, candidate filtering, and tree pruning.

2.3. Secure Graph Query Processing

Secure graph query processing covers shortest path queries, reachability queries, subgraph matching, and graph analytics over encrypted graphs. Privacy-preserving encrypted graph query processing was explored by Cao et al. [23]. GRECS and later graph encryption schemes show that specialized encrypted graph indexes can support useful graph operations [24]. GraphShield considers dynamic secure graph queries with forward privacy [25]. PathGES recently improves secure shortest path query processing [26]. These systems demonstrate the value of graph-specific encrypted indexes.

Recent Sensors work on privacy-preserving multi-user graph intersection in cloud-assisted IoT further shows that graph operations over outsourced wireless/IoT data are becoming a concrete sensor-cloud requirement [27]. However, shortest path query, graph intersection, and graph similarity matching expose different computation patterns. A similarity query compares a query graph with many candidate graphs under an edit-distance threshold. It needs feature-level counting, lower-bound computation, and pruning. DFB-PPGSQ targets this specific operation.

2.4. Leakage Attacks and Motivation for Re-Randomization

Encrypted search systems often leak access patterns, search patterns, result sizes, update sizes, and sometimes order information. Leakage-abuse and inference attacks show that such information can be exploited with auxiliary knowledge [28,29,30,31]. Order-revealing encryption and deterministic encrypted identifiers may further expose ordering or equality relations [32]. For static encrypted graph indexes, repeated queries may reveal stable branch or node correlations.

Dynamic graph services intensify this risk. The same branch feature may appear across many epochs. A deleted graph may still influence future result sizes. A label update may reveal a before-and-after relationship. DFB-PPGSQ therefore adds periodic re-randomization. It does not eliminate all leakage. It reduces persistent linkability and gives the data owner a tunable mechanism for limiting leakage accumulation.

Table 1. Functional and privacy comparison with related encrypted graph-query schemes.

Scheme	Mechanism coverage						Residual risk
	Sim.	Dyn.	Label	Re-rand.	Fwd.	Bwd.
PGSim [3]	•	×	×	×	×	×	stable index leakage
PrigSim [4]	•	×	×	×	×	×	full-database traversal leakage
PPGSQ [5]	•	×	×	∘	×	×	static branch-token linkage
GraphShield [25]	×	•	∘	∘	•	∘	not designed for similarity filtering
Dynamic SSE index [17,21,22]	∘	•	∘	∘	•	∘	weak graph-structure pruning
DFB-PPGSQ	•	•	•	•	•	∘	same-epoch tombstone leakage

•: directly supported; ∘: bounded, indirect, or assumption-dependent support; ×: outside the current mechanism. Sim.: graph similarity query; Dyn.: insertion/deletion; Label: vertex/edge label updates; Re-rand.: periodic re-randomization or compaction.

Table 1. Functional and privacy comparison with related encrypted graph-query schemes.

Scheme	Mechanism coverage						Residual risk
	Sim.	Dyn.	Label	Re-rand.	Fwd.	Bwd.
PGSim [3]	•	×	×	×	×	×	stable index leakage
PrigSim [4]	•	×	×	×	×	×	full-database traversal leakage
PPGSQ [5]	•	×	×	∘	×	×	static branch-token linkage
GraphShield [25]	×	•	∘	∘	•	∘	not designed for similarity filtering
Dynamic SSE index [17,21,22]	∘	•	∘	∘	•	∘	weak graph-structure pruning
DFB-PPGSQ	•	•	•	•	•	∘	same-epoch tombstone leakage

•: directly supported; ∘: bounded, indirect, or assumption-dependent support; ×: outside the current mechanism. Sim.: graph similarity query; Dyn.: insertion/deletion; Label: vertex/edge label updates; Re-rand.: periodic re-randomization or compaction.

3. Problem Formulation

3.1. System Model

The system model contains two primary entities: the client and the cloud. It can also include authorized users in a multi-user deployment, but this paper focuses on the single-client setting first.

Client.

The client owns a dynamic graph database. It extracts graph features, generates cryptographic keys, encrypts graph records, constructs secure indexes, and issues update/query tokens. The client is trusted. It may be a sensor data owner, an IoT service operator, or a security monitoring platform.

Cloud.

The cloud stores encrypted graphs and secure indexes. It receives update tokens and query tokens from the client. It executes update, filtering, pruning, and candidate retrieval procedures on encrypted data. The cloud returns encrypted candidate graphs to the client.

Figure 1 summarizes the system-level interaction. The trusted client keeps plaintext graphs, master keys, and workload semantics locally. It uploads only encrypted graph records and protected index material. Later, it sends update tokens, query tokens, and epoch re-randomization material to the cloud. The cloud is honest-but-curious. It stores the encrypted graph database, the branch-tree index, the update buffer, the tombstone set, and the re-randomization state. It performs token-authorized filtering and returns encrypted candidates for local decryption and optional refinement.

The dynamic graph database at logical time t is denoted by

$${\mathcal{G}}^t=\{G_1^t,G_2^t,\dots ,G_{N_t}^t\}.$$

Each graph $G=(V,E,L_V,L_E)$ contains a vertex set V, an edge set E, a vertex-label function $L_V$, and an edge-label function $L_E$. A query graph is denoted by Q. The query threshold is denoted by $\tau$. The query result consists of encrypted graphs whose graph edit distance to Q is no larger than $\tau$.

DFB-PPGSQ supports the following operations:

• Insert: add a new graph G to the encrypted database;
• Delete: remove an existing graph $G_i$ from the active database;
• UpdateLabel: modify one or more vertex labels or edge labels in an active graph;
• Search: retrieve encrypted candidate graphs that satisfy the similarity threshold;
• ReRand: re-randomize feature tokens, occurrence handles, tree nodes, counters, and active-record handles at an epoch boundary.

3.2. Threat Model

The cloud is honest-but-curious. It follows the protocol, but it attempts to infer information from encrypted graphs, secure indexes, update tokens, query tokens, search traces, access patterns, result sizes, tree traversal paths, and timing metadata. This is the same broad server model used by many searchable-encryption systems.

The client is trusted. It generates keys correctly and does not leak plaintext graph data. Network channels between the client and authorized users can be protected by standard authenticated encryption. Denial-of-service attacks, malicious result omission, collusion between users, and side-channel leakage from implementation details are outside the main model.

The cloud may possess auxiliary knowledge. It may know public graph distributions, common sensor labels, partial plaintext graphs, or historical workload statistics. This knowledge makes leakage control more important.

3.3. Notation

Table 2 lists the main symbols used in this paper.

3.4. Scheme Definition

A DFB-PPGSQ scheme consists of the following polynomial-time algorithms:

$$\Pi =(\mathsf{KeyGen},\mathsf{Setup},\mathsf{UpdateToken},\mathsf{ApplyUpdate},\mathsf{TrapGen},\mathsf{Query},\mathsf{ReRand}).$$

$\mathsf{KeyGen}\left(1^{\lambda }\right)\to K$.

Given the security parameter, the client generates master keys for encryption, pseudo-random functions, pseudo-random permutations, order or comparison modules, and epoch evolution.

$\mathsf{Setup}(K,{\mathcal{G}}^0)\to ({\mathsf{EDB}}_0,I_0,{\mathsf{st}}_0)$.

The client encrypts the initial graph database, extracts branch multisets, builds the initial secure branch-tree index, and initializes client state.

$\mathsf{UpdateToken}(K,\mathsf{st},\mathsf{op})\to \Delta$.

For an insertion, deletion, or label update, the client generates an update token $\Delta$. The token contains only encrypted feature handles and masked metadata needed by the cloud.

$\mathsf{ApplyUpdate}(\mathsf{EDB},I,U,D,\Delta )\to ({\mathsf{EDB}}^{\prime },I^{\prime },U^{\prime },D^{\prime })$.

The cloud applies the update token. It inserts encrypted records into the update buffer, marks deleted records, or updates encrypted label-derived branch features.

$\mathsf{TrapGen}(K,\mathsf{st},Q,\tau )\to T_Q$.

The client extracts the branch multiset of the query graph and generates a query token for the current epoch and active update buffers.

$\mathsf{Query}(\mathsf{EDB},I,U,D,T_Q)\to R$.

The cloud computes encrypted branch lower bounds, prunes candidate graphs using the branch-tree index, checks active-record states, and returns encrypted candidates.

$\mathsf{ReRand}(K,\mathsf{st},e)\to {\Omega }_e$.

At an epoch boundary, the client generates a shuffled refresh package. The cloud replaces the old branch tree, active-record handles, and update buffers with the new package, but it does not receive an old-handle to new-handle correspondence table.

3.5. Privacy Goals

DFB-PPGSQ aims to achieve content privacy, query privacy, forward privacy, backward privacy, and bounded re-randomization leakage.

Content privacy.

The cloud should not learn plaintext graph structures, vertex labels, edge labels, query graphs, or update contents beyond the defined leakage functions.

Query privacy.

The cloud should not learn the plaintext query graph. It may learn bounded query leakage, such as result size and a protected traversal trace, depending on the selected security-performance configuration.

Forward privacy.

Search tokens issued before an insertion or label update should not enable the cloud to identify whether the newly inserted or newly updated branch features match previous queries. In other words, future updates are protected from past searches.

Backward privacy.

After a graph is deleted, future search tokens should not reveal information about that deleted graph beyond bounded deletion leakage. The strongest form hides the deleted graph from future results and search traces after compaction. A practical form allows temporary tombstone leakage within the current epoch and removes it at re-randomization.

Re-randomization privacy.

Across epochs, refreshed feature tokens, occurrence handles, tree-node handles, and active-record handles should not be linkable by the cloud except through explicitly leaked size buckets, update timing, and migration counts.

4. Preliminaries

4.1. Branch-Based Lower Bound of Edit Distance

A branch is a local graph feature centered at a vertex. It contains the center vertex label, the labels of incident edges, and the labels of neighboring vertices. The branch multiset of graph G is denoted by $B\left(G\right)$.

For a branch b and a vertex label ℓ, the branch and vertex multiplicities of G are written as

$$C_B(G,b)=|\{b^{\prime }\in B\left(G\right):b^{\prime }=b\}|,C_V(G,\ell )=\left|\{v\in V\left(G\right):L_V\left(v\right)=\ell \}\right|.$$

Let ${\mathcal{B}}_{G,Q}=B\left(G\right)\cup B\left(Q\right)$ and ${\mathcal{L}}_{G,Q}=L_V\left(G\right)\cup L_V\left(Q\right)$ be the union domains induced by a data graph and a query graph. The branch and vertex residuals are

$${\Delta }_B(G,Q)=\sum _{b\in {\mathcal{B}}_{G,Q}}|C_B(G,b)-C_B(Q,b)|,$$

$${\Delta }_V(G,Q)=\sum _{\ell \in {\mathcal{L}}_{G,Q}}|C_V(G,\ell )-C_V(Q,\ell )|.$$

Following the branch-based filtering principle, a computable lower-bound score is

$$\mathsf{LBED}(G,Q)=max\left\{⌈{\displaystyle \frac{{\Delta }_B(G,Q)}{2}}⌉,⌈{\displaystyle \frac{{\Delta }_V(G,Q)}{2}}⌉\right\}.$$

If $\mathsf{LBED}(G,Q)>\tau$, G cannot be a valid answer and can be pruned before exact refinement. This score is not used as a final graph edit-distance estimator. It is used as a safe filtering signal.

This filtering principle is central to PPGSQ-style systems. DFB-PPGSQ retains it. The new challenge is to maintain branch features under dynamic encrypted updates without exposing temporal correlations.

4.2. Structured Encryption

Structured encryption allows a client to outsource encrypted data structures while enabling controlled server-side operations [33]. A leakage function specifies what the server may learn during setup, update, and query. Security is defined by simulation: whatever the real server observes should be simulatable from the allowed leakage.

DFB-PPGSQ treats the encrypted branch index as a structured-encryption object. Branch identifiers are produced by pseudo-random functions. Counters are masked or encrypted. Tree nodes are re-randomized across epochs. Update tokens are generated from evolving keys.

The construction separates two token namespaces. In epoch e, the query-matchable feature token of branch b is

$${\theta }_b^e=F_{K_F^e}\left(\mathsf{canon}\left(b\right)\right),$$

where $\mathsf{canon}\left(b\right)$ is a canonical encoding of the branch. This token is deterministic only inside one epoch and is the object that query tokens can match. For storage, the client additionally derives a per-record occurrence handle

$${\eta }_{b,i,c}^e=F_{K_O^e}({\theta }_b^e\Vert h_i^e\Vert c\Vert r_i),h_i^e=F_{K_D^e}({\mathsf{id}}_i\Vert e),$$

where $r_i$ is a graph-local nonce and c is an occurrence counter. The occurrence handle hides repeated occurrences and record membership; it is never used as the query key. This separation keeps feature matching well-defined while preventing the graph-local nonce from breaking query-token equality. The protected count stored at bucket $j=H_{K_H^e}\left(b\right)modm$ is

$${\tilde{C}}_G^e\left[j\right]=C_G^e\left[j\right]+F_{K_C^e}({\mathsf{id}}_G\Vert j)(modp).$$

Only query-authorized masks can be cancelled or compared. Thus, the cloud obtains enough information to run the filtering predicate, but it does not receive plaintext branches or stable cross-epoch identifiers.

4.3. Forward and Backward Privacy

Forward privacy prevents a server from linking future inserted data to previous search tokens. A common method is to use key evolution or one-time update labels. In DFB-PPGSQ, the update key for epoch e is derived through a one-way key chain,

$$K_U^{e,u}=F_{K_U^e}(\mathsf{upd}\Vert u),K_U^{e+1}=F_{K_R}(K_U^e\Vert e),$$

where u is a monotone update counter and $K_R$ is the re-randomization master key. The server cannot derive the label of a future update from a past search token.

Backward privacy controls leakage from deleted data. If a document, graph, or branch feature is deleted, later searches should not reveal it. Strong backward privacy can be expensive. DFB-PPGSQ therefore offers an epochal design: within the current epoch, a deletion may leak a tombstone handle and active-state check; after re-randomization, stale handles are removed from the active searchable structure. Formally, for a deleted graph set ${\mathcal{D}}_e$, query output is filtered by

$$R_e(Q,\tau )=\{G_i:\mathsf{LBED}(G_i,Q)\le \tau \wedge h_i^e\notin D_e\}.$$

At re-randomization, only $G_i\notin {\mathcal{D}}_e$ is migrated to $I_{e+1}$.

4.4. Periodic Re-Randomization

Periodic re-randomization refreshes encrypted identifiers and index nodes at epoch boundaries. It breaks long-term equality links. It also provides a natural moment for compaction: deleted entries can be removed, update buffers can be merged, and counters can be regenerated. In the stronger refresh mode used by DFB-PPGSQ, the client prepares the next-epoch active summaries and uploads them in a fresh random order:

$${\Omega }_e={\pi }_e\left(\left\{\left(h_i^{e+1},{\{{\theta }_b^{e+1},{\eta }_{b,i,c}^{e+1}\}}_{b\in B\left(G_i\right)},{\tilde{C}}_{G_i}^{e+1}\right):h_i^e\in {\mathcal{M}}_e\right\}\right),$$

where ${\pi }_e$ is a random permutation over active records. The cloud learns migration-size buckets, refreshed tree shape, and bucketed record sizes, but it does not receive a pairwise map from $h_i^e$ to $h_i^{e+1}$ or from ${\theta }_b^e$ to ${\theta }_b^{e+1}$ beyond the leakage function.

The epoch length controls a tradeoff. A short epoch reduces temporal leakage but increases maintenance cost. A long epoch reduces maintenance cost but permits more accumulated leakage. Section 7 includes this tradeoff as an experimental variable.

5. The Proposed DFB-PPGSQ Scheme

5.1. Overview

DFB-PPGSQ follows the filtering-and-refinement philosophy. The client extracts branch features from data graphs and query graphs. The cloud uses an encrypted branch-tree index to filter candidates. The client decrypts returned candidates and, when exactness is required, performs final graph edit-distance refinement locally.

At epoch e, the outsourced state is

$${\mathsf{State}}_e=({\mathsf{EDB}}_e,I_e,U_e,D_e,{\mathsf{meta}}_e),$$

where ${\mathsf{EDB}}_e$ stores encrypted graph records, $I_e$ is the compact encrypted branch-tree index, $U_e$ is the recent-update buffer, $D_e$ is the tombstone set, and ${\mathsf{meta}}_e$ contains non-secret size and epoch metadata allowed by the leakage function. The active encrypted graph handles satisfy the invariant

$${\mathsf{Act}}_e=\left(\mathsf{Leaves}\left(I_e\right)\cup \mathsf{Handles}\left(U_e\right)\right)\setminus D_e.$$

The search procedure returns only handles in ${\mathsf{Act}}_e$.

The design is deliberately modular. A deployment can select a lightweight configuration for low-power sensor backends, or a stronger configuration with homomorphic counters and oblivious compaction for sensitive environments. The four dynamic mechanisms are:

• epoch-local feature tokens and per-record occurrence handles for compact active data in $I_e$;
• one-time update labels for recent insertions and label updates in $U_e$;
• epoch-specific deletion handles in $D_e$;
• re-randomization material ${\Omega }_e$ for epoch migration.

Figure 2. Algorithmic workflow of DFB-PPGSQ. Setup derives epoch keys, feature tokens, occurrence handles, and protected counters. Dynamic operations produce one-time update labels and modify $U_e$ or $D_e$. Search evaluates the pruning predicate ${\mathrm{LB}}_N\left(Q\right)\le \tau$. Candidate results are filtered by active handles, returned as $R_e(Q,\tau )$, and periodically refreshed through shuffled epoch-$e+1$ state.

Figure 2. Algorithmic workflow of DFB-PPGSQ. Setup derives epoch keys, feature tokens, occurrence handles, and protected counters. Dynamic operations produce one-time update labels and modify $U_e$ or $D_e$. Search evaluates the pruning predicate ${\mathrm{LB}}_N\left(Q\right)\le \tau$. Candidate results are filtered by active handles, returned as $R_e(Q,\tau )$, and periodically refreshed through shuffled epoch-$e+1$ state.

5.2. Branch Extraction, Token Generation, and Setup

For a graph $G=(V,E,L_V,L_E)$, the branch centered at $v\in V$ is represented as

$$b_v=\left(L_V\left(v\right),\left\{\{(L_E(v,u),L_V\left(u\right)):(v,u)\in E\}\right\}\right),$$

where $\left\{\right\{·\left\}\right\}$ denotes a multiset. The graph branch multiset is

$$B\left(G\right)=\left\{\{b_v:v\in V\}\right\}.$$

For each branch $b\in B\left(G_i\right)$, the client generates an epoch-specific feature token and a per-record occurrence handle:

$${\theta }_b^e=F_{K_F^e}\left(\mathsf{canon}\left(b\right)\right),{\eta }_{b,i,c_b}^e=F_{K_O^e}({\theta }_b^e\Vert h_i^e\Vert c_b\Vert r_i),$$

where F is a secure pseudo-random function, $K_F^e$ is the feature-token key, $K_O^e$ is the occurrence-handle key, $h_i^e$ is the active graph handle, $r_i$ is a graph-local nonce, and $c_b$ is a local occurrence counter. Queries match ${\theta }_b^e$ values. The nonce appears only in ${\eta }_{b,i,c_b}^e$, so it randomizes stored occurrences without preventing query matching.

The client also prepares a protected branch-count vector. A branch position is derived by

$$j_e\left(b\right)=H_{K_H^e}\left(b\right)modm,{\mathbf{x}}_G^e\left[j\right]=\sum _{b\in B\left(G\right)}\mathbf{1}[j_e\left(b\right)=j],$$

and the protected count is

$${\tilde{\mathbf{x}}}_G^e\left[j\right]={\mathbf{x}}_G^e\left[j\right]+M_{K_C^e}({\mathsf{id}}_G,j)(modp).$$

For a tree node $\nu$ containing graph handles $S_{\nu }$, the aggregate plaintext count vector is

$${\mathbf{x}}_{\nu }^e\left[j\right]=\underset{G_i\in S_{\nu }}{max}{\mathbf{x}}_{G_i}^e\left[j\right],$$

and the stored value is masked in the same way. The maximum aggregate makes the node a safe filter: if a query cannot match the aggregate, it cannot match any child graph under the same lower-bound rule.

Algorithm 1 shows that setup is not only an encryption step. It also fixes the epoch keys, graph nonces, masked branch counts, and node aggregates used by later pruning. The server sees protected handles and vector lengths, while the client keeps the semantic map from plaintext branches to epoch-local feature tokens.

Algorithm 1 Setup

Input: master key K, initial graph database ${\mathcal{G}}^0=\{G_1,\dots ,G_N\}$, vector length m, modulus p Output: encrypted database ${\mathsf{EDB}}_0$, branch-tree index $I_0$, client state ${\mathsf{st}}_0$ 1: Derive epoch keys $(K_F^0,K_O^0,K_H^0,K_C^0,K_U^0,K_D^0)\leftarrow F_K(\mathsf{setup}\Vert 0)$ 2: Initialize ${\mathsf{EDB}}_0\leftarrow \varnothing$, ${\mathcal{S}}_0\leftarrow \varnothing$, $U_0\leftarrow \varnothing$, $D_0\leftarrow \varnothing$ 3: for each graph $G_i\in {\mathcal{G}}^0$ do 4:     sample graph nonce $r_i\leftarrow {\{0,1\}}^{\lambda }$ and handle $h_i^0\leftarrow F_{K_D^0}({\mathsf{id}}_i\Vert 0)$ 5:     compute branch multiset $B\left(G_i\right)$ and count vector ${\mathbf{x}}_{G_i}^0$ 6:     for each occurrence $(b,c_b)\in B\left(G_i\right)$ do 7:         generate feature token ${\theta }_b^0\leftarrow F_{K_F^0}\left(\mathsf{canon}\left(b\right)\right)$ 8:         generate occurrence handle ${\eta }_{b,i,c_b}^0\leftarrow F_{K_O^0}({\theta }_b^0\Vert h_i^0\Vert c_b\Vert r_i)$ 9:     end for 10:     mask counts ${\tilde{\mathbf{x}}}_{G_i}^0\left[j\right]\leftarrow {\mathbf{x}}_{G_i}^0\left[j\right]+M_{K_C^0}({\mathsf{id}}_i,j)modp$ 11:     append ${\mathsf{Enc}}_K\left(G_i\right)$ to ${\mathsf{EDB}}_0$ and $(h_i^0,\left\{({\theta }_b^0,{\eta }_{b,i,c_b}^0)\right\},{\tilde{\mathbf{x}}}_{G_i}^0)$ to ${\mathcal{S}}_0$ 12: end for 13: build $I_0\leftarrow \mathsf{BuildTree}\left({\mathcal{S}}_0\right)$ with node aggregates ${\tilde{\mathbf{x}}}_{\nu }^0$ 14: set ${\mathsf{st}}_0\leftarrow (K,0,{\left\{r_i\right\}}_{i=1}^N,\mathsf{ctr}=0)$ 15: return$({\mathsf{EDB}}_0,I_0,{\mathsf{st}}_0)$

5.3. Dynamic Branch-Tree Index

The branch-tree index groups graphs by encrypted branch-summary ranges. Each internal node stores a protected aggregate summary of its children, and each leaf stores encrypted graph handles and compact branch-count summaries. For a query branch-count vector ${\mathbf{x}}_Q^e$ and a node aggregate ${\mathbf{x}}_{\nu }^e$, the node lower bound is modeled as

$${\mathsf{LBED}}_e(Q,\nu )={\displaystyle \frac{1}{2}}{\displaystyle \sum _{j=1}^m}max\{0,{\mathbf{x}}_Q^e\left[j\right]-{\mathbf{x}}_{\nu }^e\left[j\right]\}+\gamma ·max\{0,|V_Q|-V_{\nu }^{max}\},$$

where $V_{\nu }^{max}$ is the maximum vertex count of graphs under node $\nu$, and $\gamma \in [0,1]$ controls the vertex-count penalty. A node is safely pruned when

$${\mathsf{LBED}}_e(Q,\nu )>\tau .$$

For any child graph $G_i$ under $\nu$, the aggregate construction gives ${\mathbf{x}}_{G_i}^e\left[j\right]\le {\mathbf{x}}_{\nu }^e\left[j\right]$, so

$${\mathsf{LBED}}_e(Q,\nu )\le {\mathsf{LBED}}_e(Q,G_i).$$

Thus, the pruning rule cannot discard a graph whose exact branch lower bound is at most $\tau$.

5.4. Forward-Private Insertion

When inserting a graph $G_{\mathrm{new}}$, the client extracts $B\left(G_{\mathrm{new}}\right)$, derives feature tokens ${\theta }_b^e$, generates a fresh graph nonce $r_{\mathrm{new}}$, and creates one-time update labels with a monotonically increasing counter u:

$$U_{b,u}^e=F_{K_U^e}({\theta }_b^e\Vert u).$$

The counter is never reused. The update record is

$${\Delta }_{\mathrm{ins}}=\left(\mathsf{ins},h_{\mathrm{new}}^e,{\mathsf{Enc}}_K\left(G_{\mathrm{new}}\right),{\left\{U_{b,u}^e\right\}}_{b\in B\left(G_{\mathrm{new}}\right)},{\tilde{\mathbf{x}}}_{\mathrm{new}}^e\right).$$

The cloud appends this record to $U_e$. Since $U_{b,u}^e$ is derived from an update key and a future counter, an old query token cannot be used to test whether a future inserted graph contains a branch matching that old query. A later query authorizes only the current update-counter interval needed to test buffered records.

5.5. Backward-Private Deletion

When deleting graph $G_i$, the client issues an epochal deletion handle

$$h_i^e=F_{K_D^e}({\mathsf{id}}_i\Vert e).$$

The deletion token is

$${\Delta }_{\mathrm{del}}=(\mathsf{del},h_i^e),D_e\leftarrow D_e\cup \left\{h_i^e\right\}.$$

During the same epoch, deletion leaks only the tombstone handle and the fact that a candidate may be suppressed by $D_e$. At re-randomization, deleted records are not migrated into $I_{e+1}$; after that point, they no longer participate in future search traces.

5.6. Label Update

A label update modifies vertex labels or edge labels in a graph. It changes only the branches whose center or one-hop neighborhood intersects the edited element. If $\delta$ is an edit operation on $G_i$, define the affected branch set as

$$\mathsf{Aff}(G_i,\delta )=B\left(G_i\right)▵B(G_i\oplus \delta ),$$

where ▵ is multiset symmetric difference. The update decomposes into old-branch removals and new-branch insertions:

$${\mathsf{Aff}}^{-}=\mathsf{Aff}\cap B\left(G_i\right),{\mathsf{Aff}}^{+}=\mathsf{Aff}\cap B(G_i\oplus \delta ).$$

For each $b\in {\mathsf{Aff}}^{+}$, the client creates a fresh one-time update label $U_{b,u}^e$; for each $b\in {\mathsf{Aff}}^{-}$, the client creates a removal tag tied to the active handle. The protected delta vector is

$$\Delta {\tilde{\mathbf{x}}}_i^e\left[j\right]=\left({\mathbf{x}}_{G_i\oplus \delta }^e\left[j\right]-{\mathbf{x}}_{G_i}^e\left[j\right]\right)+M_{K_C^e}({\mathsf{id}}_i,j,u)(modp).$$

Algorithm 2 is the unified dynamic-update interface. Insertions and positive label deltas use fresh update labels; deletions use epochal tombstones; label changes are represented as local branch deltas. This keeps ordinary updates small and postpones tree rebuilding to epoch maintenance.

Algorithm 2 Dynamic Update

Input: operation $\mathsf{op}$, epoch e, client state ${\mathsf{st}}_e$, outsourced state $({\mathsf{EDB}}_e,I_e,U_e,D_e)$ Output: updated outsourced state and client state 1: if$\mathsf{op}=\mathsf{Insert}\left(G\right)$then 2:     sample graph nonce $r_G$ and compute $B\left(G\right)$, ${\tilde{\mathbf{x}}}_G^e$, and active handle $h_G^e$ 3:     generate feature tokens ${\left\{{\theta }_b^e\right\}}_{b\in B\left(G\right)}$ and one-time update labels ${\left\{U_{b,u}^e\right\}}_{b\in B\left(G\right)}$ with fresh counter values 4:     $\Delta \leftarrow (\mathsf{ins},h_G^e,{\mathsf{Enc}}_K\left(G\right),\left\{U_{b,u}^e\right\},{\tilde{\mathbf{x}}}_G^e)$ 5:     append $\Delta$ to $U_e$ and ${\mathsf{Enc}}_K\left(G\right)$ to ${\mathsf{EDB}}_e$ 6: else if$\mathsf{op}=\mathsf{Delete}\left(\mathsf{id}\right)$then 7:     compute $h_{\mathsf{id}}^e\leftarrow F_{K_D^e}(\mathsf{id}\Vert e)$ 8:     append $h_{\mathsf{id}}^e$ to $D_e$ 9: else if$\mathsf{op}=\mathsf{UpdateLabel}(\mathsf{id},\delta )$then 10:     compute ${\mathsf{Aff}}^{-}$ and ${\mathsf{Aff}}^{+}$ for $G_{\mathsf{id}}\oplus \delta$ 11:     generate removal tags for ${\mathsf{Aff}}^{-}$ and one-time update labels for ${\mathsf{Aff}}^{+}$ 12:     compute masked delta vector $\Delta {\tilde{\mathbf{x}}}_{\mathsf{id}}^e$ 13:     append $(\mathsf{upd},h_{\mathsf{id}}^e,{\mathsf{Aff}}^{-},{\mathsf{Aff}}^{+},\Delta {\tilde{\mathbf{x}}}_{\mathsf{id}}^e)$ to $U_e$ 14: end if 15: update local counters in ${\mathsf{st}}_e$ 16: return$({\mathsf{EDB}}_e,I_e,U_e,D_e,{\mathsf{st}}_e)$

5.7. Query Processing

Given query graph Q and threshold $\tau$, the client extracts $B\left(Q\right)$ and generates a query token

$${\mathcal{T}}_Q^e=\left({\left\{{\theta }_q^e\right\}}_{q\in B\left(Q\right)},{\left\{{\omega }_{q,u}^e\right\}}_{q\in B\left(Q\right),u\in {\mathcal{U}}_e},{\tilde{\mathbf{x}}}_Q^e,\tau ,{\mathsf{auth}}_e\right),$$

where ${\omega }_{q,u}^e=F_{K_U^e}({\theta }_q^e\Vert u)$ authorizes comparisons with buffered update labels for the current update-counter interval ${\mathcal{U}}_e$. Thus, ${\theta }_q^e$ searches the compact branch tree $I_e$, while ${\omega }_{q,u}^e$ searches one-time labels in $U_e$. The cloud computes two candidate sets:

$${\mathsf{Cand}}_I=\{h_i^e\in I_e:{\mathsf{LBED}}_e(Q,G_i)\le \tau \},$$

$${\mathsf{Cand}}_U=\{h_i^e\in U_e:{\mathsf{LBED}}_e(Q,G_i)\le \tau \}.$$

The active candidate set is

$${\mathsf{Cand}}_e(Q,\tau )=\left({\mathsf{Cand}}_I\cup {\mathsf{Cand}}_U\right)\setminus D_e.$$

The cloud never sees Q or plaintext graph labels. It observes the declared traversal pattern, update-buffer checks, and result size. If the application requires less traversal leakage, the same query interface can be combined with padded traversal or oblivious access, at additional cost.

Algorithm 4 is the node-level primitive used inside Algorithm 3. Its early termination rule implements

$$\exists k\le m:{\displaystyle \sum _{j=1}^k}{\ell }_j(Q,\nu )>\tau ⟹{\mathsf{LBED}}_e(Q,\nu )>\tau ,$$

where ${\ell }_j(Q,\nu )$ is the accumulated deficit contribution at coordinate j. Once this condition holds, the remaining coordinates cannot reduce the lower bound, so the subtree can be pruned.

Algorithm 3 Search

Input: query graph Q, threshold $\tau$, epoch e, state $(I_e,U_e,D_e)$ Output: encrypted candidate set $R_e(Q,\tau )$ 1: Client computes $B\left(Q\right)$, ${\tilde{\mathbf{x}}}_Q^e$, and query token ${\mathcal{T}}_Q^e$ 2: Server initializes ${\mathsf{Cand}}_I\leftarrow \varnothing$ and queue $\mathcal{Q}\leftarrow \left\{\mathsf{root}\left(I_e\right)\right\}$ 3: while$\mathcal{Q}\ne \varnothing$do 4:     pop node $\nu$ from $\mathcal{Q}$ 5:     compute ${\mathsf{dist}}_{\nu }\leftarrow {\mathsf{LBED}}_e(Q,\nu )$ using authorized protected summaries 6:     if ${\mathsf{dist}}_{\nu }\le \tau$ and $\nu$ is internal then 7:         push all children of $\nu$ into $\mathcal{Q}$ 8:     else if ${\mathsf{dist}}_{\nu }\le \tau$ and $\nu$ is a leaf then 9:         test graph-level summaries in $\nu$ and append passing handles to ${\mathsf{Cand}}_I$ 10:     end if 11: end while 12: compute ${\mathsf{Cand}}_U$ by testing buffered insertions and label-update deltas in $U_e$ 13: filter tombstones: ${\mathsf{Cand}}_e\leftarrow ({\mathsf{Cand}}_I\cup {\mathsf{Cand}}_U)\setminus D_e$ 14: return encrypted graph records $R_e(Q,\tau )\leftarrow \{{\mathsf{EDB}}_e\left[h\right]:h\in {\mathsf{Cand}}_e\}$

Algorithm 4 Query in One Internal Node

Input: query token ${\mathcal{T}}_Q=\{{\theta }_q,T_v,\tau \}$ and encrypted internal node $\mathcal{I}$ Output: lower-bound score $\mathsf{dist}$ for node pruning 1: Initialize $\mathsf{dist}=0$, residual branch counts $R_b=N_{q_i}$, and residual vertex counts $R_v=N_{v_i}$ 2: for each query branch feature token ${\theta }_{q_i}$ do 3:     if $\mathsf{NB}\left[{\theta }_{q_i}\right]\ne 0$ then 4:         $t=min\{\mathsf{NB}\left[{\theta }_{q_i}\right],N_{q_i}\}$ 5:         $R_b\leftarrow R_b-t$ 6:         decrease the corresponding vertex residuals induced by ${\theta }_{q_i}$ 7:     end if 8: end for 9: for each query vertex token $T_{v_i}$ do 10:     if $\mathsf{NV}\left[T_{v_i}\right]\ne 0$ and $N_{v_i}\ne 0$ then 11:         $t=min\{\mathsf{NV}\left[T_{v_i}\right],N_{v_i}\}$ 12:         $N_{v_i}\leftarrow N_{v_i}-t$ and $\mathsf{NV}\left[T_{v_i}\right]\leftarrow \mathsf{NV}\left[T_{v_i}\right]-t$ 13:         $\mathsf{dist}\leftarrow \mathsf{dist}+0.5t$ 14:         if $\mathsf{dist}>\tau$ then 15:            return $\mathsf{dist}$ 16:         end if 17:     else if $\mathsf{NV}\left[T_{v_i}\right]=0$ and $N_{v_i}\ne 0$ then 18:         $\mathsf{dist}\leftarrow \mathsf{dist}+N_{v_i}$ 19:         if $\mathsf{dist}>\tau$ then 20:            return $\mathsf{dist}$ 21:         end if 22:     end if 23: end for 24: return$\mathsf{dist}$

5.8. Periodic Re-Randomization

At the end of epoch e, the client starts $\mathsf{ReRand}$. It derives new epoch keys

$$(K_F^{e+1},K_O^{e+1},K_H^{e+1},K_C^{e+1},K_U^{e+1},K_D^{e+1})=F_K(\mathsf{epoch}\Vert e+1).$$

Let the active migration set be

$${\mathcal{M}}_e=\{h_i^e:h_i^e\in \mathsf{Leaves}\left(I_e\right)\cup \mathsf{Handles}\left(U_e\right),h_i^e\notin D_e\}.$$

For every active graph, the client computes new feature tokens, occurrence handles, active handles, and masked counters under epoch $e+1$ keys. The refresh package is

$${\Omega }_e={\pi }_e\left(\{(h_i^{e+1},{\left\{({\theta }_b^{e+1},{\eta }_{b,i,c_b}^{e+1})\right\}}_{b\in B\left(G_i\right)},{\tilde{\mathbf{x}}}_i^{e+1}):h_i^e\in {\mathcal{M}}_e\}\right),$$

where ${\pi }_e$ is sampled by the client. The cloud installs this package as a replacement state and therefore observes the number of active records and bucketed sizes, but not a pairwise old-to-new handle map.

Re-randomization can be full or incremental. Full re-randomization rebuilds the whole active index from a shuffled client refresh package. Incremental re-randomization uploads a fixed budget of refreshed records per time window, with a fresh permutation inside each batch. In both cases, deleted records are excluded from ${\mathcal{M}}_e$, which is the mechanism that gives the construction its epochal backward-privacy effect. The incremental mode leaks batch sizes and batch timing; the full mode leaks the epoch refresh size but avoids pairwise migration linkage.

Algorithm 5 Re-Randomization

Input: epoch e, index $I_e$, update buffer $U_e$, tombstones $D_e$, client state ${\mathsf{st}}_e$ Output: refreshed index $I_{e+1}$ and cleared buffers 1: Client derives $(K_F^{e+1},K_O^{e+1},K_H^{e+1},K_C^{e+1},K_U^{e+1},K_D^{e+1})$ 2: Client determines active logical ids represented by ${\mathcal{M}}_e$ and excludes $D_e$ 3: Initialize local refresh list ${\mathcal{S}}_{e+1}\leftarrow \varnothing$ 4: for each active graph id ${\mathsf{id}}_i$ in random order ${\pi }_e$ do 5:     compute $h_i^{e+1}\leftarrow F_{K_D^{e+1}}({\mathsf{id}}_i\Vert e+1)$ 6:     refresh feature tokens ${\theta }_b^{e+1}\leftarrow F_{K_F^{e+1}}\left(\mathsf{canon}\left(b\right)\right)$ 7:     refresh occurrence handles ${\eta }_{b,i,c_b}^{e+1}\leftarrow F_{K_O^{e+1}}({\theta }_b^{e+1}\Vert h_i^{e+1}\Vert c_b\Vert r_i)$ 8:     recompute or remask ${\tilde{\mathbf{x}}}_i^{e+1}$ 9:     append $(h_i^{e+1},\left\{({\theta }_b^{e+1},{\eta }_{b,i,c_b}^{e+1})\right\},{\tilde{\mathbf{x}}}_i^{e+1})$ to ${\mathcal{S}}_{e+1}$ 10: end for 11: Server receives ${\Omega }_e={\mathcal{S}}_{e+1}$ and builds or installs $I_{e+1}\leftarrow \mathsf{BuildTree}\left({\mathcal{S}}_{e+1}\right)$ 12: set $U_{e+1}\leftarrow \varnothing$, $D_{e+1}\leftarrow \varnothing$, and securely discard stale epoch material 13: update client state ${\mathsf{st}}_{e+1}$ 14: return$(I_{e+1},U_{e+1},D_{e+1},{\mathsf{st}}_{e+1})$

6. Security Analysis

6.1. Threat Model and Leakage Profile

We model the cloud as an honest-but-curious probabilistic polynomial-time adversary. It follows $\mathsf{Setup}$, $\mathsf{ApplyUpdate}$, $\mathsf{Query}$, and $\mathsf{ReRand}$, but tries to infer graph contents, query branches, update contents, and temporal relations among operations. The client is trusted and keeps the master key K, epoch keys, graph nonces, logical-id map, and local counters secret. The encrypted graph database is protected by an IND-CPA secure symmetric encryption scheme, and all token-generation functions are modeled as pseudo-random functions.

The security goal is leakage-based structured-encryption security. Let

$$\mathcal{O}=(\mathsf{setup},{\mathsf{op}}_1,\dots ,{\mathsf{op}}_T)$$

be an adaptive operation sequence selected by the adversary, where each ${\mathsf{op}}_t$ is an insertion, deletion, label update, query, or epoch refresh. The real server view is

$${\mathsf{View}}_{\mathcal{A}}^{\Pi }(\lambda ,\mathcal{O})=\left({\mathsf{EDB}}_e,I_e,U_e,D_e,{\left\{{\Delta }_t\right\}}_{t\le T},{\left\{{\mathcal{T}}_{Q_t}^{e_t}\right\}}_{t\le T},{\{{\mathsf{path}}_{e_t}\left(Q_t\right),R_{e_t}(Q_t,{\tau }_t)\}}_{t\le T}\right).$$

The simulator is allowed to see only a leakage function

$$\mathcal{L}=\left({\mathcal{L}}_{\mathsf{setup}},{\mathcal{L}}_{\mathsf{upd}},{\mathcal{L}}_{\mathsf{qry}},{\mathcal{L}}_{\mathsf{rr}}\right).$$

Definition 1 

(Leakage functions). For an initial database ${\mathcal{G}}^0$, update ${\mathsf{op}}_t$, query $(Q_t,{\tau }_t)$, and epoch refresh from e to $e+1$, DFB-PPGSQ exposes the following leakage:

$${\mathcal{L}}_{\mathsf{setup}}\left({\mathcal{G}}^0\right)=\left(N,\left\{\right|G_i{\left|\right\}}_{i=1}^N,\left\{\right|B\left(G_i\right){\left|\right\}}_{i=1}^N,m,p,\mathsf{shape}\left(I_0\right),\left\{\right|S_{\nu }{\left|\right\}}_{\nu \in I_0}\right),$$

$${\mathcal{L}}_{\mathsf{upd}}({\mathsf{op}}_t,e)=\left(t,e,\mathsf{type}\left({\mathsf{op}}_t\right),\mathsf{bucket}\left(\right|{\Delta }_t\left|\right),\mathsf{bucket}\left(\right|\mathsf{Aff}\left({\mathsf{op}}_t\right)\left|\right),\mathbf{1}[{\mathsf{op}}_t=\mathsf{del}]\right),$$

$${\mathcal{L}}_{\mathsf{qry}}(Q_t,{\tau }_t,e)=\left(t,e,{\tau }_t,{\mathsf{path}}_e\left(Q_t\right),{\mathsf{updscan}}_e\left(Q_t\right),|{\mathsf{Cand}}_e(Q_t,{\tau }_t)|,|R_e(Q_t,{\tau }_t)|\right),$$

and

$${\mathcal{L}}_{\mathsf{rr}}\left(e\right)=\left(e,|{\mathcal{M}}_e|,|D_e|,|U_e|,\mathsf{shape}\left(I_{e+1}\right),\mathsf{bucketmultiset}\left(\right\{|\mathsf{EDB}\left[h\right]|:h\in {\mathcal{M}}_e\left\}\right),\mathsf{bucket}\left(T_{\mathsf{rr}}\right)\right).$$

Here N is the number of outsourced graphs, m and p are public counter parameters, $S_{\nu }$ is the handle set under node ν, $\mathsf{Aff}$ is the affected branch-delta set for a label update, ${\mathsf{path}}_e\left(Q_t\right)$ is the tree traversal trace, and ${\mathsf{updscan}}_e\left(Q_t\right)$ is the set of update-buffer records tested by the query token.

The leakage definition is intentionally explicit. DFB-PPGSQ does not claim oblivious access, result-size hiding, or fully hidden update timing. Instead, it prevents the cloud from learning plaintext graph labels, plaintext branch equality across protected epochs, and token-level relations beyond the declared size, timing, traversal, and migration metadata.

6.2. Real-Ideal Security Definition

Definition 2 

(Adaptive leakage security). Let ${\mathsf{Real}}_{\mathcal{A}}^{\Pi }\left(\lambda \right)$ be the experiment in which adversary $\mathcal{A}$ adaptively interacts with the real DFB-PPGSQ protocol and receives the real server view. Let ${\mathsf{Ideal}}_{\mathcal{A},\mathcal{S}}^{\mathcal{L}}\left(\lambda \right)$ be the experiment in which $\mathcal{A}$ interacts with a simulator $\mathcal{S}$ that receives only $\mathcal{L}\left(\mathcal{O}\right)$ for the same operation sequence. DFB-PPGSQ is adaptively secure with respect to $\mathcal{L}$ if, for every PPT adversary $\mathcal{A}$, there exists a PPT simulator $\mathcal{S}$ such that

$${\mathsf{Adv}}_{\Pi ,\mathcal{L}}^{\mathsf{se}}(\mathcal{A},\mathcal{S},\lambda )=\left|Pr[\mathcal{A}\left({\mathsf{View}}_{\mathsf{real}}\right)=1]-Pr[\mathcal{A}\left({\mathsf{View}}_{\mathsf{ideal}}\right)=1]\right|\le \mathsf{negl}\left(\lambda \right).$$

The simulator uses ${\mathcal{L}}_{\mathsf{setup}}$ to sample ciphertext strings, protected handles, vector lengths, and a tree with the leaked shape. It uses ${\mathcal{L}}_{\mathsf{upd}}$ to sample update records with the correct operation class and size bucket. It uses ${\mathcal{L}}_{\mathsf{qry}}$ to reproduce the same visited-node pattern, update-buffer scan size, candidate size, and returned ciphertext count. It uses ${\mathcal{L}}_{\mathsf{rr}}$ to sample shuffled epoch-refresh messages and the new tree shape without using a pairwise old-to-new handle or branch map.

6.3. Token and Ciphertext Indistinguishability

Lemma 1 

(Pseudo-random token simulation). Let F be a secure pseudo-random function. For any polynomial number of inputs

$$x_r\in \{\mathsf{canon}\left(b\right),{\theta }_b^e\Vert h_i^e\Vert c_b\Vert r_i,{\theta }_b^e\Vert u,{\mathsf{id}}_i\Vert e,\mathsf{epoch}\Vert e\},$$

the token family ${\left\{F_K\left(x_r\right)\right\}}_r$ is computationally indistinguishable from random strings of the same length, preserving only equality that is intentionally leaked by same-epoch feature tokens or authorized update probes. More precisely, for every PPT distinguisher $\mathcal{D}$,

$$\left|Pr[\mathcal{D}\left({\left\{F_K\left(x_r\right)\right\}}_r\right)=1]-Pr[\mathcal{D}\left({\left\{U_r\right\}}_r\right)=1]\right|\le {\mathsf{Adv}}_F^{\mathsf{prf}}(\mathcal{B},\lambda ),$$

where ${\left\{U_r\right\}}_r$ are independent uniform strings and $\mathcal{B}$ is a standard PRF adversary constructed from $\mathcal{D}$.

Proof. 

The proof is the standard PRF hybrid. Replace the oracle used to answer each token request with a truly random function. Feature-token equality for the same branch inside one epoch is intentionally retained because it is needed for matching; occurrence handles, update labels, deletion handles, and epoch identifiers use non-reused namespaces. If $\mathcal{D}$ distinguishes real tokens from random labels under these retained equality constraints, then $\mathcal{D}$ directly yields a PRF distinguisher $\mathcal{B}$ with the same distinguishing gap. Thus, the difference is bounded by ${\mathsf{Adv}}_F^{\mathsf{prf}}(\mathcal{B},\lambda )$.    □

Lemma 2 

(Encrypted-record simulation). If the graph encryption scheme is IND-CPA secure, then encrypted graph records in ${\mathsf{EDB}}_e$ can be simulated from record-size leakage. For any PPT adversary $\mathcal{A}$,

$$\left|Pr[\mathcal{A}\left({\left\{{\mathsf{Enc}}_K\left(G_i\right)\right\}}_i\right)=1]-Pr[\mathcal{A}\left({\left\{{\mathsf{Enc}}_K\left(0^{|G_i|}\right)\right\}}_i\right)=1]\right|\le {\mathsf{Adv}}_{\mathsf{Enc}}^{\mathsf{ind}-\mathsf{cpa}}(\mathcal{B},\lambda ).$$

Proof. 

The simulator encrypts zero strings of the same size buckets as the real graph encodings. Any adversary that distinguishes these simulated ciphertexts from real graph ciphertexts breaks IND-CPA security through the usual many-message hybrid.    □

6.4. Main Security Theorem

Theorem 1 

(Structured-encryption security of DFB-PPGSQ). Assume that F is a secure pseudo-random function, $M_{K_C^e}$ is a pseudo-random mask family over ${\mathbb{Z}}_p$, graph encryption is IND-CPA secure, and nonces/counters are non-reused within their namespaces. Then DFB-PPGSQ is adaptively secure with respect to the leakage function $\mathcal{L}$ in Definition 1:

$${\mathsf{Adv}}_{\Pi ,\mathcal{L}}^{\mathsf{se}}(\mathcal{A},\mathcal{S},\lambda )\le {\mathsf{Adv}}_{\mathsf{Enc}}^{\mathsf{ind}-\mathsf{cpa}}+q_F{\mathsf{Adv}}_F^{\mathsf{prf}}+q_M{\mathsf{Adv}}_M^{\mathsf{prf}}+\mathsf{negl}\left(\lambda \right),$$

where $q_F$ and $q_M$ are polynomially bounded numbers of token and mask queries.

Proof. 

We use a sequence of hybrids. In $H_0$, the adversary receives the real server view. In $H_1$, every encrypted graph record ${\mathsf{Enc}}_K\left(G_i\right)$ is replaced by an encryption of a zero string with the same leaked size. By Lemma 2, $H_0$ and $H_1$ are indistinguishable under IND-CPA security.

In $H_2$, all feature tokens, occurrence handles, update labels, deletion handles, query labels, and epoch keys are replaced by random strings that preserve equality only when equality is allowed by $\mathcal{L}$ in the same epoch or by a query-authorized update probe. Lemma 1 bounds the distinguishing advantage between $H_1$ and $H_2$ by the PRF advantage.

In $H_3$, protected count values

$${\tilde{\mathbf{x}}}_G^e\left[j\right]={\mathbf{x}}_G^e\left[j\right]+M_{K_C^e}({\mathsf{id}}_G,j)(modp)$$

and node aggregates are replaced by random elements of ${\mathbb{Z}}_p$ that are consistent with the leaked vector length, modulus, and comparison outcomes. Since $M_{K_C^e}$ is pseudo-random, the adversary sees only masked values and the declared pruning outcomes. Thus, $H_2$ and $H_3$ are indistinguishable up to ${\mathsf{Adv}}_M^{\mathsf{prf}}$.

In $H_4$, the simulator generates the entire server view using $\mathcal{L}$. It samples ciphertexts with leaked sizes, random handles and tokens with leaked equality patterns, a tree with shape $\mathsf{shape}\left(I_e\right)$, query traversal paths ${\mathsf{path}}_e\left(Q\right)$, update scans ${\mathsf{updscan}}_e\left(Q\right)$, result counts, and shuffled epoch-refresh sizes. By construction, $H_3$ and $H_4$ have the same distribution. Therefore, the real and ideal experiments are computationally indistinguishable except for the stated cryptographic advantages.    □

6.5. Forward Privacy

Theorem 2 

(Forward privacy). Let t be a time before an insertion or positive label-update delta at time $t^{\prime }>t$. Under the PRF assumption and non-reused update counters, any token view observed before $t^{\prime }$ is independent of the plaintext branch set inserted at $t^{\prime }$ except for ${\mathcal{L}}_{\mathsf{upd}}$. Formally, for every branch predicate P and PPT adversary $\mathcal{A}$,

$$\left|Pr[\mathcal{A}({\mathsf{View}}_{<t^{\prime }},{\Delta }_{t^{\prime }})=P\left(B_{\mathsf{new}}\right)]-Pr[\mathcal{A}({\mathsf{View}}_{<t^{\prime }},{\widehat{\Delta }}_{t^{\prime }})=P\left(B_{\mathsf{new}}\right)]\right|\le {\mathsf{Adv}}_F^{\mathsf{prf}}+\mathsf{negl}\left(\lambda \right),$$

where ${\widehat{\Delta }}_{t^{\prime }}$ is a simulated update record with the same leakage but random update labels.

Proof. 

For each inserted branch $b\in B_{\mathsf{new}}$, the server receives

$$U_{b,u}^e=F_{K_U^e}({\theta }_b^e\Vert u),$$

where u has not appeared before. Tokens issued before $t^{\prime }$ did not contain the future counter probe ${\omega }_{b,u}^e=F_{K_U^e}({\theta }_b^e\Vert u)$. Hence, there is no efficiently testable relation between an old search token and $U_{b,u}^e$ unless a future query intentionally authorizes that update-counter interval. Replacing $U_{b,u}^e$ with a random string changes the adversary’s view only by the PRF advantage. The remaining visible information is update time, type, epoch, and size bucket, which is exactly ${\mathcal{L}}_{\mathsf{upd}}$.    □

6.6. Backward Privacy

Theorem 3 

(Epochal backward privacy). Let graph handle $h_i^e$ be deleted during epoch e, and let the next refresh produce epoch $e+1$. If deleted handles are excluded from ${\mathcal{M}}_e$, then future search views in epochs $e^{\prime }>e$ are independent of $G_i$ beyond deletion and migration leakage:

$$h_i^e\in D_e⟹h_i^{e+1}\notin \mathsf{Leaves}\left(I_{e+1}\right)\cup \mathsf{Handles}\left(U_{e+1}\right),$$

and for every future query $(Q,\tau )$,

$$Pr[h_i^{e+1}\in {\mathsf{Cand}}_{e+1}(Q,\tau )]=0.$$

Proof. 

During epoch e, the deletion operation adds

$${\Delta }_{\mathsf{del}}=(\mathsf{del},h_i^e),D_e\leftarrow D_e\cup \left\{h_i^e\right\}.$$

Same-epoch queries may reveal that a candidate is suppressed by a tombstone; this is included in the deletion leakage. At $\mathsf{ReRand}$, the migration set is

$${\mathcal{M}}_e=\left(\mathsf{Leaves}\left(I_e\right)\cup \mathsf{Handles}\left(U_e\right)\right)\setminus D_e.$$

Thus $h_i^e\notin {\mathcal{M}}_e$, and no new active handle $h_i^{e+1}$, occurrence handle ${\eta }_{b,i,c_b}^{e+1}$, or protected count vector ${\tilde{\mathbf{x}}}_i^{e+1}$ is generated for the deleted graph. Future queries operate only on $I_{e+1}$ and $U_{e+1}$. Therefore, the deleted graph cannot be returned or tested as an active record after refresh. Any attempt to link future query tokens to stale deleted-graph tokens reduces to distinguishing independently generated epoch-$e+1$ PRF outputs from random strings, plus the explicitly leaked refresh-size metadata.    □

6.7. Query and Result Privacy

Proposition 1 

(Query-view simulation). For a query $(Q,\tau )$ in epoch e, the server view

$${\mathsf{View}}_{\mathsf{qry}}(Q,\tau ,e)=\left({\mathcal{T}}_Q^e,{\mathsf{path}}_e\left(Q\right),{\mathsf{updscan}}_e\left(Q\right),{\mathsf{Cand}}_e(Q,\tau ),R_e(Q,\tau )\right)$$

is simulatable from ${\mathcal{L}}_{\mathsf{qry}}(Q,\tau ,e)$ and cryptographic sizes.

Proof. 

The simulator samples pseudo-random query labels for ${\mathcal{T}}_Q^e$, creates a traversal trace with the leaked path length and node identifiers, samples update-buffer checks according to ${\mathsf{updscan}}_e\left(Q\right)$, and returns the leaked number of ciphertext records. The plaintext branch labels in Q are used only inside PRF inputs and masked count vectors. By Lemmas 1 and 2, replacing these objects with simulated labels and ciphertexts is computationally indistinguishable. The non-hidden parts are exactly traversal pattern, update-buffer checks, candidate count, and result size.    □

6.8. Re-Randomization Security

Proposition 2 

(Cross-epoch unlinkability). For any active branch occurrence $(b,i,c)$ refreshed from epoch e to $e+1$, the occurrence-handle pair

$$\left({\eta }_{b,i,c}^e,{\eta }_{b,i,c}^{e+1}\right)=\left(F_{K_O^e}({\theta }_b^e\Vert h_i^e\Vert c\Vert r_i),F_{K_O^{e+1}}({\theta }_b^{e+1}\Vert h_i^{e+1}\Vert c\Vert r_i)\right)$$

is computationally unlinkable across epochs, except through ${\mathcal{L}}_{\mathsf{rr}}$ and workload metadata. The cloud does not receive the pair $(h_i^e,h_i^{e+1})$ during full shuffle refresh. For any PPT linking adversary $\mathcal{A}$,

$${\mathsf{Adv}}_{\mathsf{link}}\left(\mathcal{A}\right)\le 2{\mathsf{Adv}}_F^{\mathsf{prf}}+Pr\left[\mathsf{MetaColl}\right]+\mathsf{negl}\left(\lambda \right),$$

where $\mathsf{MetaColl}$ denotes a uniqueness event in leaked metadata such as record-size buckets, refresh batch timing, or repeated result-size patterns.

Proof. 

Epoch keys are derived as independent PRF outputs:

$$K_O^e=F_K(\mathsf{epoch}\Vert e\Vert O),K_O^{e+1}=F_K(\mathsf{epoch}\Vert e+1\Vert O).$$

Replacing epoch-e occurrence handles with random labels and then replacing epoch-$(e+1)$ occurrence handles with independent random labels changes the adversary’s view only by the PRF advantage. Independent random labels do not encode branch or record equality across epochs. Because the refresh package is shuffled, a successful link must use non-token information such as bucketed record size, batch timing, or repeated query-result metadata. These correlations are captured by $Pr\left[\mathsf{MetaColl}\right]$ and the declared re-randomization leakage.    □

6.9. Comparison with Static PPGSQ-Style Indexing

In a static PPGSQ-style index, a branch occurrence keeps a stable encrypted identifier. Abstractly, if the same branch occurrence appears in two time windows, the server may observe

$${\eta }_{b,i,c}^e={\eta }_{b,i,c}^{e+1}\mathrm{or}{\mathsf{path}}_e\left(Q\right)\approx {\mathsf{path}}_{e+1}\left(Q\right),$$

which enables longitudinal profiling. Inserted branches can be tested against old query identifiers if update labels reuse the same branch namespace, and deleted branches may remain observable through stale index nodes until a full rebuild is performed.

DFB-PPGSQ changes these equalities into epoch-local relations:

$$Pr[{\eta }_{b,i,c}^e={\eta }_{b,i,c}^{e+1}]\le 2^{-\lambda },{\mathsf{Act}}_{e+1}=\left({\mathsf{Act}}_e\cup {\mathsf{Ins}}_e\cup {\mathsf{Upd}}_e\right)\setminus D_e.$$

Thus, active records are re-tokenized, update records use one-time labels, deleted records are removed from the next searchable state, and the cloud does not receive a pairwise old-to-new refresh map. The price is visible update timing, buffer scans, bucketed refresh sizes, and epoch-maintenance leakage; the gain is that temporal branch and handle equality are no longer stable server-side identifiers.

7. Experimental Evaluation

This section reports a reproducible prototype evaluation of DFB-PPGSQ. The goal is to test whether the proposed dynamic mechanisms preserve the main branch-filtering advantage of PPGSQ-style search while avoiding full index rebuild after ordinary updates. It implements protocol-relevant operations in Python: branch extraction, HMAC-SHA256 token generation, feature-token matching, one-time update labels, branch-count lower-bound filtering, feature-only dynamic SSE lookup, update buffering, tombstone filtering, and shuffle-based epoch re-randomization.

7.1. Prototype Implementation and Workloads

The evaluation was executed on Windows 11 with Python 3.14.2 on an Intel64 Family 6 Model 189 processor. Every plotted point reports the mean over five independent random seeds, and the error bars show the standard deviation across these seeds. The generated workload models a dynamic sensor-topology graph database. Each default mesh graph contains 8–22 vertices. Vertices are assigned sensor or device labels such as temperature, pressure, gateway, camera, and alarm. Edges encode communication, control, backup, or event relations. A ring backbone keeps each graph connected, and additional sparse edges emulate redundant sensor links or event dependencies. To strengthen the Sensors-oriented evaluation, we also add industrial CPS and campus IoT stress profiles with larger graphs and richer device vocabularies, motivated by the dynamic dependency and security requirements observed in sensor-network studies [1,2].

Table 3. Prototype workload and reproducibility settings.

Component	Setting	Range / Value	Purpose
Graph database size	generated sensor-topology graphs	250, 500, 1000, 2000, 4000 graphs	query scalability
Graph structure	connected sparse graph	8–22 vertices; ring backbone plus random extra edges	sensor-network topology model
Stress profiles	mesh, industrial CPS, campus IoT	1500–4000 graphs; mean 15–56 vertices	robustness to heterogeneous sensor networks
Dynamic operations	insert, delete, label update, epoch refresh	five random seeds: 1701–1705	update and maintenance cost
Query threshold	graph edit-distance threshold proxy	$\tau \in \{1,2,3,4,5,6\}$	pruning sensitivity
Epoch length	refresh interval	50, 100, 250, 500, 1000 updates	privacy-efficiency tradeoff

Table 3. Prototype workload and reproducibility settings.

Component	Setting	Range / Value	Purpose
Graph database size	generated sensor-topology graphs	250, 500, 1000, 2000, 4000 graphs	query scalability
Graph structure	connected sparse graph	8–22 vertices; ring backbone plus random extra edges	sensor-network topology model
Stress profiles	mesh, industrial CPS, campus IoT	1500–4000 graphs; mean 15–56 vertices	robustness to heterogeneous sensor networks
Dynamic operations	insert, delete, label update, epoch refresh	five random seeds: 1701–1705	update and maintenance cost
Query threshold	graph edit-distance threshold proxy	$\tau \in \{1,2,3,4,5,6\}$	pruning sensitivity
Epoch length	refresh interval	50, 100, 250, 500, 1000 updates	privacy-efficiency tradeoff

The dynamic workload is denoted by

$$\mathcal{W}=\{{\mathsf{op}}_1,{\mathsf{op}}_2,\dots ,{\mathsf{op}}_T\},$$

where ${\mathsf{op}}_t\in \{\mathsf{Insert},\mathsf{Delete},\mathsf{UpdateLabel},\mathsf{Search},\mathsf{ReRand}\}$. A workload profile is represented as

$$\pi =(p_{\mathrm{ins}},p_{\mathrm{del}},p_{\mathrm{lab}},p_{\mathrm{qry}},E),$$

where E is the epoch length. Insertions generate new sensor-topology graphs, deletions insert epoch-specific tombstone handles, and label updates perturb local vertex or edge labels and therefore regenerate only the affected branches. Queries are generated by perturbing existing graphs by one to three local label changes.

7.2. Baselines

The comparison includes both graph-similarity baselines and dynamic encrypted-search baselines. Table 4 summarizes their roles. Static PPGSQ1 performs full branch lower-bound scanning. Static PPGSQ2 uses the same size and branch-count filtering principle as a branch-tree baseline but does not include dynamic privacy. DSSE-branch represents a feature-only dynamic searchable-encryption service that retrieves graphs sharing authorized sensor labels but does not maintain a graph-similarity branch tree. Dynamic rebuild rebuilds the whole protected index after each update. The no-re-randomization baseline keeps stable branch identifiers and is used only for linkability testing.

7.3. Metrics

For a query set $\mathcal{Q}$, average query latency is

$${\overline{T}}_q={\displaystyle \frac{1}{\left|\mathcal{Q}\right|}}\sum _{Q\in \mathcal{Q}}{T}_q\left(Q\right).$$

For an update stream $\mathcal{U}$, average update latency is

$${\overline{T}}_u={\displaystyle \frac{1}{\left|\mathcal{U}\right|}}\sum _{\mathsf{op}\in \mathcal{U}}{T}_u\left(\mathsf{op}\right).$$

The pruning ratio for query Q is

$$\mathsf{PR}\left(Q\right)=1-{\displaystyle \frac{\left|\mathsf{Cand}\right(Q\left)\right|}{\left|\mathcal{G}\right|}}.$$

The false-positive candidate ratio after local refinement is

$$\mathsf{FPR}\left(Q\right)={\displaystyle \frac{|\mathsf{Cand}\left(Q\right)\setminus R^{★}\left(Q\right)|}{\left|\mathsf{Cand}\right(Q\left)\right|}},$$

where $R^{★}\left(Q\right)$ is the exact result set under the graph edit-distance threshold. Linkability attack success is measured as

$$\mathsf{ASR}={\displaystyle \frac{\#\mathrm{correctly}\mathrm{linked}\mathrm{epoch}-\mathrm{crossing}\mathrm{tokens}}{\#\mathrm{tested}\mathrm{token}\mathrm{pairs}}}.$$

Storage and communication overhead are not optimized in this Python prototype and are therefore not used for the main comparison. The reported metrics are query latency, update latency, epoch-refresh maintenance cost, candidate pruning ratio, and linkability attack success. The stress-profile experiment additionally reports a metadata-assisted linkability attack that combines branch-label length, local degree, and coarse branch-string length buckets. Latencies are wall-clock measurements in milliseconds.

7.4. Query Scalability

The first experiment measures query latency as the graph database grows from 250 to 4000 graphs. Figure 3 shows that DFB-PPGSQ remains close to the static branch-tree baseline while outperforming full scanning and feature-only DSSE at larger scales. At 4000 graphs, DFB-PPGSQ required 46.60 ms on average, compared with 44.72 ms for Static PPGSQ2, 62.22 ms for Static PPGSQ1, and 64.95 ms for DSSE-branch. Thus, the dynamic mechanisms add about 4.2% query overhead relative to the static branch-tree baseline at the largest tested scale, while avoiding a return to linear full-database scanning.

7.5. Dynamic Update Cost

The second experiment separates ordinary updates from epoch maintenance. Figure 4 shows that immediate rebuild is expensive for insertions, deletions, and label updates because the whole protected index is reconstructed after every operation. In contrast, DFB-PPGSQ appends insertions and label updates to the update buffer and stores deletions as tombstones. In the measured prototype, insertion and label update cost 0.091 ms and 0.092 ms on average, respectively, while delete cost 0.007 ms. Epoch refresh remains expensive because it rebuilds and re-randomizes the active index; its mean cost was 192.73 ms. This is expected: DFB-PPGSQ moves rebuild cost from every update to scheduled epoch boundaries.

7.6. Re-Randomization Tradeoff

The third experiment varies epoch length. A shorter epoch reduces the time window in which tombstone and update-buffer traces remain linkable, but it increases amortized maintenance cost. Figure 5 shows this tradeoff. The measured maintenance cost falls from 4.03 ms per update at an epoch length of 50 updates to 0.177 ms per update at 1000 updates. The normalized linkability window grows in the opposite direction, because a longer epoch leaves stable within-epoch metadata visible for a longer period.

7.7. Pruning Ability

The fourth experiment evaluates whether dynamic privacy weakens branch-based pruning. Figure 6 reports the fraction of graphs removed before refinement. DFB-PPGSQ closely tracks the static branch-tree baseline because it preserves the same lower-bound filtering structure and adds only update-buffer and tombstone checks. At $\tau =1$, Static PPGSQ2 pruned 68.9% of candidates, and DFB-PPGSQ pruned 68.2%. At $\tau =6$, the pruning ratios were 2.0% and 2.0%, respectively. The feature-only DSSE baseline pruned almost no graphs in this generated sensor workload because most graphs share at least one coarse sensor label; this illustrates why dynamic keyword-style search is not a substitute for graph-similarity filtering.

7.8. Sensor-Network Stress Workloads

The fifth experiment tests whether the same implementation remains stable under more heterogeneous sensor-network profiles. Figure 7 reports three workloads. The default sensor-mesh profile uses 4000 graphs with 14.98 vertices per graph on average. The industrial CPS and campus IoT profiles use 1500 larger graphs with 40.05 and 56.16 vertices per graph on average, respectively, and include richer device and communication labels. DFB-PPGSQ required 52.92 ms on the 4000-graph mesh profile, 23.86 ms on the industrial CPS profile, and 23.80 ms on the campus IoT profile. The two larger-graph profiles also produced stronger pruning because their richer labels and higher local degree make branch summaries more selective: the pruning ratios were 63.2% and 73.2%, respectively. Under a stronger metadata-assisted cross-epoch attacker using label-length, degree, and coarse branch-string buckets, the measured attack success rates were 3.3%, 5.6%, and 4.8% for the three profiles. These results do not replace evaluation on public IoT traces, but they give a stronger stress test than a single small synthetic topology.

7.9. Leakage-Resilience

The sixth experiment evaluates temporal linkability under a simple attacker. For the no-re-randomization baseline, the attacker links occurrence handles across epochs by deterministic equality. For DFB-PPGSQ, equality no longer works after epoch refresh; the attacker therefore falls back to coarse bucket matching based on branch label length and local degree. Figure 8 shows that stable identifiers make occurrence-handle linkage trivial in the baseline, whereas DFB-PPGSQ reduces the measured bucket-matching success rate to approximately 1.4–1.5%. This experiment does not prove resistance to all leakage-abuse attacks. It demonstrates that epoch key refresh removes the strongest equality signal and leaves only coarse metadata leakage under the declared leakage model.

8. Conclusions

This paper proposed DFB-PPGSQ, a dynamic forward/backward-private graph similarity matching query scheme over encrypted graph databases. The scheme targets a realistic sensor-cloud setting where graphs are not static. They are inserted, deleted, relabeled, and periodically maintained.

DFB-PPGSQ combines branch-based lower-bound filtering with dynamic structured encryption. It introduces epoch-local feature tokens, per-record occurrence handles, update buffers, deletion tombstones, and shuffle-based periodic re-randomization. These mechanisms preserve efficient graph similarity filtering while reducing temporal leakage from dynamic updates. The security analysis shows how the scheme achieves forward privacy for future insertions and label updates, and epochal backward privacy for deleted graphs after compaction under an explicit leakage model. The prototype evaluation supports the design goal: ordinary updates avoid immediate full rebuild, query latency remains close to the static branch-tree baseline, stress workloads remain practical on heterogeneous sensor topologies, and epoch refresh removes stable cross-epoch token equality.

Future work will extend the prototype to public IoT and cyber-physical graph traces, optimize the cryptographic implementation, and investigate verifiable and multi-user encrypted graph services.