The Verifiable Bundle: Reading a Beijing Hybrid-Encryption Patent
A file lands in a cloud bucket. Someone needs to verify it has not been tampered with. Someone else needs to run a computation on it. Neither one is allowed to see the plaintext. That three-way tug of war is the constraint that a freshly granted Chinese patent, CN121000522B, tries to resolve in a single pipeline. It is titled "Privacy protection method and system for hybrid encryption strategy" in the machine-translated English, and the title undersells the document. The filing does not propose a new cryptographic primitive. It composes four well-known ones:
- Lattice-based homomorphic encryption. Encryption that lets a server compute on your data without ever decrypting it.
- Riemann manifold key optimization. Treating the encryption key as a point on a curved geometric surface and "rolling" it toward a calmer region.
- Merkle-style integrity hashing. A tree of hashes whose single root acts as a tamper-evident fingerprint of the data below.
- Non-interactive zero-knowledge proofs. A static cryptographic receipt that says "this was done correctly" without revealing anything else.
The output of the pipeline is not a single ciphertext but a bundle of three things: a ciphertext, a hash root, and a proof. That bundling is the actual invention. Everything else is plumbing.
The patent at a glance
- Publication number: CN121000522B (earlier application publication CN121000522A, released 2025-11-21)
- Application number: CN202511516099.5A
- Assignee (as listed on Google Patents, accuracy not guaranteed by the registry): Beijing Zhongyi Tengfei Technology Co., Ltd. (北京中仪腾飞科技有限公司)
- Inventors: Yang Qunpeng, Zheng Hailiang, Shi Lei, Li Hua, Sun Gang, Xiao Changlin, Gao Junxiang, Chi Zhaojian, Dou Guang
- Filed: 2025-10-23. Granted: 2025-12-23. Anticipated expiration: 2045-10-23.
- Primary technical fields: H04L 9/00, H04L 9/32 (including H04L 9/3218 for non-interactive zero-knowledge proofs), H04L 63/00, H04L 63/04, H04L 2463/062.
- Source: Google Patents, https://patents.google.com/patent/CN121000522B/en
Why "Encrypted" Still Isn't Enough
Standard encryption is not broken. AES, RSA, and the newer lattice-based key encapsulation mechanisms all work as advertised. What they do not do is solve the harder problem of letting a third party verify a ciphertext and run a computation on it without ever seeing the data.
Symmetric encryption keeps data confidential at rest, but a server that stores encrypted blobs cannot do anything useful with them. Asymmetric encryption lets two parties exchange secrets across an untrusted channel, but it still assumes that whoever holds the private key is the only one who needs to look at the data. Homomorphic encryption relaxes that assumption. The cloud can manipulate the contents without ever opening the box, so
holds for a useful class of functions . The catch is cost. Homomorphic operations run several orders of magnitude slower than their plaintext equivalents, and on their own they say nothing about whether the data was tampered with after the encryption step.
Merkle trees handle the integrity side. Each leaf holds the hash of a piece of data, each parent holds the hash of its two children, and the root at the top is a single short fingerprint that changes if any byte anywhere below it changes. Zero-knowledge proofs add a third ingredient: the ability to assert a fact about the data without revealing the data itself.
The problem the filing identifies is coordination, not cryptography. If a verifier needs the ciphertext, the hash tree, and the proof to all agree, and each was produced by a separate subsystem, the verifier has to trust that the three subsystems were configured consistently. The bet here is that producing all three from a single shared key-generation step closes that gap.
A Key Shaped by Geometry
The most distinctive part of the filing is not the cryptography. It is the key. Instead of sampling a key from a uniform random distribution, the inventors define a geometric procedure for shaping one. The intuition: a key built from structured mathematical objects may have richer structure than a key built by flipping coins, even if the resulting bits look equally random to an attacker.
The procedure starts with two random prime numbers, and . From these, two lattice basis matrices are generated. A "lattice" in this context is a regularly spaced grid of points in -dimensional space, like the corner of an infinite sheet of graph paper extended into many dimensions. A "basis" is a small set of vectors whose integer combinations hit every point in the grid, and a "basis matrix" is just the matrix whose columns are those vectors. Lattices matter for cryptography because certain hard problems ("find the closest lattice point to a random target") are believed to resist even quantum computers, which is why the leading post-quantum candidates (ML-KEM, Dilithium, FALCON) are all built on them.
The first basis, called the "primary lattice basis" , is a random invertible integer matrix that survives a primality test: it is kept only when . The second, the "auxiliary lattice basis" , scales the first by a diagonal matrix built from the second prime:
The orthogonal copy
The two bases are then fed into a Gram-Schmidt orthogonalization, a classic linear algebra algorithm that takes a set of vectors and produces a perpendicular copy of them, one at a time, by subtracting from each new vector the components that point in directions already used. The result is an orthogonal matrix (whose columns are the new perpendicular unit vectors) and an upper triangular matrix (which records how much of each original vector projected onto each new direction):
The decomposition is accepted only when the Frobenius norm of the residual (the square root of the sum of squares of every entry in the matrix, a natural "how big is the discrepancy" measure) is small:
This is the standard QR decomposition from any linear algebra textbook, framed here as the first step of key generation, not a preprocessing detail.
The metric tensor
The orthogonal matrix yields a homomorphic encryption key. The specific construction is to take inner products of 's row vectors with a vector of random integer coefficients :
The resulting is mapped onto a Riemann manifold, which is just a smooth curved surface (think of the surface of a sphere, generalized to many dimensions), equipped with a metric tensor that, at every point on the surface, tells you how to measure local distances and angles. In flat Euclidean space the metric is the boring identity matrix, but on a curved surface the metric varies from point to point and reveals exactly how curved you are at that location. The patent builds a deliberately simple diagonal metric whose entries are exponential in the squared components of , smoothed by a parameter :
The diagonal form is a deliberate simplification. It guarantees that the metric is orthogonal, so distances and angles behave as the cryptographic intuition expects.
The key evolution
Here is where the patent gets unusual. It treats the diagonal of the upper triangular matrix as an initial "key state" , and evolves that state forward in discrete time steps using a velocity derived from Ricci curvature (a way of measuring how much the volume of a small ball in the curved space differs from the volume of a ball with the same radius in flat space, an "is this region bulging in or out" meter) minus a second-order term:
The evolution runs until falls below a convergence threshold.
The energy minimization
Across the trajectory, the document computes a "curvature energy"
which integrates the squared magnitude of the curvature across the whole manifold. Minimizing this energy is the geometric equivalent of "find me the calmest spot on the surface", the flattest region where no direction is being pulled in any particular way. The filing selects the "optimal" key state as the one that minimizes this energy.
The blend
Finally, it blends the optimal state with the homomorphic key using a mixing coefficient that is itself a function of the curvature energy and a user-chosen encryption strength :
The result is the "hybrid" encryption key . When the curvature energy is small, is close to 1 and the homomorphic key dominates. When the energy is large, the geometric optimal state is weighted more heavily.
A honest caveat
Nothing in the patent text proves that is cryptographically stronger than either of its ingredients. The language is operational, not theorem-bound. The Ricci-flow analogy is suggestive rather than formally grounded; the borrowing of vocabulary from Perelman's proof of the Poincaré conjecture is metaphorical, not mathematical. A skeptical reader should treat this step as an engineering pattern the inventors believe helps, not as a cryptographic primitive with known properties. We will come back to this in the limits section.
From Plaintext to Verifiable Bundle
The main claim is best read as a recipe with eight steps. The diagram below captures the architecture at a high level.

The pipeline runs left to right. A single plaintext blob enters a hybrid encryption engine. A few internal techniques (the lattice basis, the Riemann evolution, the vector inner-product cipher) collaborate to produce a single output bundle. That bundle fans out into a small set of named components: the ciphertext blocks themselves, a Merkle root that summarizes them, and a zero-knowledge proof that attests to the bundle's integrity.
Step by step:
- Receive and partition. The user terminal sends plaintext. The server splits it into a fixed number of data blocks.
- Build the lattices. Two primes are chosen. The primary basis and auxiliary basis are generated and decomposed into and as described above.
- Derive the hybrid key. The orthogonal matrix yields a homomorphic key . The Riemann evolution produces an optimal state . The two are mixed into the final hybrid key .
- Encrypt. Each data block is reconstructed as a vector and transformed into a ciphertext block by a vector inner product with :
This single multiplication per block is the workhorse. In a homomorphic scheme it is the operation that preserves the ability to run arithmetic on the ciphertext later, because the dot product commutes with linear combinations of the .
- Fragment and entropize. The ciphertext block is partitioned into fragments whose count is the product of its Shannon entropy (the average amount of "surprise" per byte, which is high when the data looks random and low when it has lots of repetition) and a base fragment length. For a ciphertext block with entropy and base length :
The intuition is simple: high-entropy data carries more information per byte, so it gets sliced into more pieces.
- Build a topology-weighted Merkle tree. Each fragment is concatenated with a small feature vector (connected-component count, hole count, mean, standard deviation) before being hashed. Adjacent leaf hashes are then mixed with a weight derived from the negative exponential of the Euclidean distance between their feature vectors:
This is a non-standard twist. A classical Merkle tree combines adjacent leaves with equal weight, so the root is just regardless of the contents of the leaves. This document adjusts the combination weight by how similar the adjacent leaves' fingerprints are. The argument is that a tampered fragment will have an outlier feature vector, a small weight, and therefore a measurable effect on the root. Think of it as a Merkle tree that "listens" to how its leaves compare with their neighbors before deciding how strongly to mix them.
- Generate a zero-knowledge proof. Starting from the Merkle root, the system traces paths down to several randomly chosen target leaves. For each path, it computes a "local proof value" by summing depth-weighted cascaded hashes. If every local proof value exceeds a confidence threshold, the system emits a ZKP consisting of a commitment, a random string, the path hashes, and the local proof values. The non-interactive part is what makes this useful: a non-interactive ZKP is a single static blob (think of a signed PDF, not a back-and-forth conversation) that anyone can verify at any later time without talking to the prover. Zero knowledge means the verifier learns nothing beyond the truth of the statement "this tree was built correctly from this ciphertext".
- Return the bundle. The user receives the ciphertext blocks, the hybrid key, the Merkle root, and the ZKP.
A reader who is not already a cryptographer can take a few things from this. The encryption step is a one-line operation, the vector inner product, repeated per data block. The integrity step is a hash tree with a non-standard weighting rule. The verification step is a non-interactive zero-knowledge proof, generated once and checked by anyone holding the root.
Reading the Independent Claim Like a Recipe
The independent claim, claim 1, is roughly 250 words in the machine-translated English and reads like a recipe rather than a theorem. It defines the eight-step pipeline above without committing to specific numbers. The dependent claims add the operational details:
- Claim 2 locks down the lattice construction: the first prime is chosen, the initial matrix is rejected if its determinant vanishes modulo , and the second prime defines the diagonal scaling that produces the auxiliary basis.
- Claim 3 locks down the Merkle construction: entropy-driven fragment sizing, the four-component topology vector per fragment, and the negative-exponential weighting rule.
- Claim 4 locks down the ZKP construction: depth weights, threshold gating, and the commitment-plus-randomness-plus-path-plus-proof-value output structure.
- Claim 5 restates the method as a system with five named units. Claims 6 and 7 claim an electronic device and a non-transitory computer-readable storage medium, the standard Chinese patent pattern for covering software deployments.
This claim structure is typical of Chinese software patents. The method claim is the substantive protection. The system, device, and storage-medium claims are mostly defensive, ensuring that an infringer cannot avoid the patent by reimplementing the method on a different software stack.
What This Buys You, and What It Doesn't
If the claims hold up in practice, the architecture has a few properties that are individually common but rarely appear together in a single pipeline.
The key-generation step is post-quantum-friendly by construction. Lattice-based primitives are the leading candidates for post-quantum cryptography, and the hybrid key is rooted in a lattice decomposition rather than in integer factorization or discrete logarithms. The document does not claim a specific lattice security reduction, so the post-quantum property is structural, not proven.
The integrity verification does not require a third party to see the plaintext. The Merkle root and the ZKP together let a verifier check that the bundle has not been tampered with, without learning the underlying data. The standard ZKP guarantee applies, and the document is unusual only in that the ZKP is generated as a byproduct of the encryption step rather than as a separate protocol.
The architecture is modular. The four pieces (lattice, Riemann evolution, hash tree, ZKP) are independent. A future revision could swap the Riemann heuristic for a learning-with-errors (LWE) sampling routine without disturbing the rest of the pipeline.
What the filing does not buy is harder to talk about, but more important. The document is silent on a few things a buyer would want to know. There are no benchmark numbers. There is no threat model. There is no comparative analysis against, say, a homomorphic-encryption scheme plus a standalone ZKP. It does not say how much slower the hybrid key generation is than a uniform random key. It does not say how the topology-weighted Merkle tree compares to a classical tree under specific adversarial assumptions. The worked examples (a 3x3 lattice, an 8x8 evolution, ) are illustrative, not normative, and they appear only in the description, not in the claims.
In other words, the document claims a composition, not a result. The composition is interesting. The result is not yet measured.
Unresolved Standards, Unmeasured Latency, and a Curious Heuristic
A few limits deserve a closer look before any reader walks away thinking this is a finished product.
Unresolved standards. The filing does not name or conform to any specific post-quantum standard (ML-KEM, ML-DSA, FALCON, Dilithium) or any specific ZKP framework (zk-SNARKs, zk-STARKs, Bulletproofs). The CPC classifications place it in the general H04L 9/00 family, not in any of the more specific lattice or ZKP sub-categories. A practitioner who wanted to implement it today would have to make their own choices about parameter sets, hash functions, and proof systems, and those choices are not specified in the claims.
Unmeasured latency. The Riemann evolution runs for some number of iterations until the velocity falls below a threshold. In the worked example, that took 50 iterations. The document does not bound the worst-case iteration count or the cost per iteration. For small inputs the cost is negligible. For large inputs (think: encrypting a 1 GB file as a single block) the cost could become a real bottleneck, and the document is silent on it.
A curious heuristic. The "Riemann manifold mapping" is the most novel and the least justified part of the filing. The Ricci-flow analogy borrows vocabulary from Perelman's proof of the Poincaré conjecture without the underlying mathematics. The mixing coefficient
is a softmax-style blend. It is well defined and easy to compute, but there is no argument in the document that selecting the curvature-energy minimum actually improves the resulting key's security. A skeptical reader should treat this step as an engineering pattern the inventors believe helps, not as a cryptographic primitive with known properties.
The translation itself. All of the technical language in this briefing comes from the machine-translated English on Google Patents. The original Chinese may phrase the steps slightly differently, and any practitioner reading the patent for due diligence should pull the Chinese text and have a native speaker review the claim boundaries before relying on the English version.
Assignee transparency. Google Patents notes that the listed assignees "may be inaccurate". Beijing Zhongyi Tengfei Technology Co., Ltd. is the best public attribution, not a guaranteed legal owner. Whether the filing will be enforced, licensed, or assigned to a larger entity is an open question.
In short: this document is an interesting composition of four well-known primitives, packaged as a single Chinese invention filing, and granted within two months of filing (a fast turnaround for CNIPA). The novelty is real but modest. The post-quantum framing is structural. The ZKP is conventional. The Riemann flow is a heuristic. The architecture is a recipe, not a theorem, and a careful reader should treat the claims as a design pattern rather than as a security proof.
Sources
- Google Patents, CN121000522B: https://patents.google.com/patent/CN121000522B/en
- Espacenet bibliographic record: https://worldwide.espacenet.com/publicationDetails/biblio?CC=CN&NR=121000522B&KC=B&FT=D
- CNIPA Patent Search (primary jurisdiction): https://pss-system.cponline.cnipa.gov.cn/conventionalSearchEn
- Global Dossier (USPTO mirror of the CN application): https://globaldossier.uspto.gov/result/application/CN/202511516099/1
- Diagrammatic visualization of the patent's pipeline: see embedded diagram above