Understanding the GL Scheme: Homomorphic Encryption Redesigned from Scratch for Matrices

Tech & Insight — The Homomorphic Encryption & Private AI Series (4 parts)

• ① Understanding Fully Homomorphic Encryption (FHE): Computing on Data Without Ever Opening It
• ② Understanding THOR: Running LLM Inference on Ciphertext
• ③ Understanding the GL Scheme: Homomorphic Encryption Redesigned from Scratch for Matrices — current post
• ④ Understanding Private AI: Using AI Without Handing Over Your Data — coming soon

At a glance (TL;DR)

• The GL (Gentry-Lee) Scheme is a new fully homomorphic encryption scheme that supports matrix operations from the design stage of the scheme itself. It was co-invented by FHE's founder Craig Gentry and DESILO Chief Scientist Yongwoo Lee (currently a professor in the Department of Electrical and Electronic Engineering at Inha University), and the paper was accepted at CRYPTO 2026, one of the most prestigious venues in cryptography.
• Because conventional homomorphic encryption treats ciphertext only as a "long vector," matrix multiplication had to be worked around with tens to hundreds of rotation operations. GL redesigns the encoding so that the ciphertext holds a matrix from the start, reducing an encrypted matrix multiplication to four plaintext matrix multiplications.
• The key-switching cost of matrix multiplication is proven to stay within at most 4× (about 2.8× measured) that of element-wise multiplication. It processed a ciphertext-to-ciphertext product of sixteen 256×256 complex matrices in about 7 seconds on a single CPU thread, and most of that time was not homomorphic-encryption overhead but the plaintext matrix multiplication itself.
• Given that most AI computation is matrix multiplication, GL is a fifth-generation homomorphic encryption that will take the "encrypted AI inference" THOR demonstrated to the next stage. DESILO built the world's first commercial software implementation.

Table of contents

1. Why "homomorphic encryption for matrices"
2. What was the problem: 15 years of building matrices out of vectors
3. Core idea #1: the ciphertext holds a matrix
4. Core idea #2: matrix multiplication in four plaintext matrix multiplications
5. A toolbox for matrices: transpose, rotation, bootstrapping
6. Results: GL by the numbers
7. Security: why a new scheme is safe
8. What GL opens up: fifth-generation homomorphic encryption and Private AI
9. Frequently asked questions (FAQ)
10. References

---

1. Why "homomorphic encryption for matrices"

Try to apply homomorphic encryption to a real service and you end up hitting the same wall: matrix multiplication. Most of the compute in AI inference is matrix multiplication, and as data grows — through statistical analysis and recommendation systems too — matrices sit at the center of the computation. As we saw in 「Understanding THOR」, the success of encrypted transformer inference also came down to how fast matrix multiplication could be handled.

Yet homomorphic-encryption schemes had no data type called a "matrix." From the second-generation BGV/BFV to the fourth-generation CKKS, the standard schemes of the past 15 years treat a ciphertext as a long vector (slots) holding thousands to tens of thousands of numbers. That is natural for vector-wise addition and element-wise multiplication, but inherently awkward for matrix multiplication, where rows and columns intertwine.

The GL (Gentry-Lee) Scheme solves this problem by turning it around. Instead of cramming a matrix into a vector, it redesigns the ciphertext itself to hold a matrix from the start. It was co-invented by Craig Gentry (currently Chief Scientist at Cornami), who first realized fully homomorphic encryption in 2009, and DESILO Chief Scientist Yongwoo Lee (currently a professor in the Department of Electrical and Electronic Engineering at Inha University), and the paper was accepted at CRYPTO 2026, hosted by the International Association for Cryptologic Research (IACR), one of the most prestigious venues in cryptography (IACR ePrint Paper 2025/1935).

For homomorphic encryption as a whole and its generational breakdown, see 「Understanding Fully Homomorphic Encryption (FHE)」.

---

2. What was the problem: 15 years of building matrices out of vectors

If a ciphertext is only a vector, matrix multiplication has to be assembled somehow out of vector operations. Prior work wrestled with this problem along two broad lines.

Assembling with rotations. This approach spreads the matrix into a vector in row, column, or diagonal form, then reconstructs the matrix multiplication by repeating rotation and element-wise multiplication. From Halevi-Shoup's Baby-Step Giant-Step technique to THOR's diagonal encoding, the algorithms kept getting more refined, but the cost structure of rotation and the key-switching it entails never went away.

Reducing to plaintext matrix multiplication. More recently, an approach emerged that manipulates the ciphertext's coefficients directly, converting an encrypted matrix multiplication into a few plaintext matrix multiplications (Bae et al., CRYPTO 2024; Park, EUROCRYPT 2025). It is fast because it can use highly optimized matrix-multiplication libraries as-is, but there is a price. The matrix size is fixed to the ring dimension (typically 4,096–131,072), making practical matrix sizes hard to handle; because it uses coefficient encoding, mixing it with ordinary SIMD operations requires repeated slot↔coefficient transforms — a heavy homomorphic linear transform that is also cited as a major bottleneck in bootstrapping — and multiplication is only possible at low levels, constraining circuit design.

GL's goal is to take only the strengths of both lines: on top of slot encoding, directly, multiply matrices of freely chosen size at the speed of plaintext matrix multiplication.

---

3. Core idea #1: the ciphertext holds a matrix

GL's first ingredient is a multivariate ring. If a conventional scheme's ciphertext is a single-variable polynomial — a one-row vector — GL's ciphertext is a polynomial with three axes. The X-axis holds the matrix's rows, the Y-axis its columns, and the W-axis multiple matrices. It is not a one-row table but a tensor with width × height × depth from the start, and each evaluation value of the polynomial corresponds exactly to "the (j, k) element of the ℓ-th matrix."

This structure has two practical advantages. First, the matrix size becomes a free parameter not tied to the ring dimension. The experiments used 256×256 matrices, but they can be made smaller or larger as needed. Second, because multiple matrices are batched into one ciphertext, a single multiplication processes several pairs of matrix products at once. At the experimental parameters, 16 matrices fit in one ciphertext.

The second ingredient is the Gaussian-integer perspective. Viewing the standard ring homomorphic encryption uses as a ring with complex-integer coefficients reveals a symmetric structure that fits matrix encoding perfectly, making the extension of axes natural. According to the paper, this is the first use of a Gaussian-integer structure for matrix encoding in FHE.

---

4. Core idea #2: matrix multiplication in four plaintext matrix multiplications

With the encoding changed, the remaining problem is multiplication. GL's answer is a classical tool of algebra: the trace. The paper proves that multiplying two ciphertext polynomials and then picking out only the degree-0 component of an auxiliary variable yields exactly "the product of the encoded matrices." Because the scheme is designed so that the secret key does not depend on the auxiliary variable, this trace operation can be performed directly on ciphertext.

What is decisive is how this trace is computed. An operation that looks complex actually converts exactly into a plaintext matrix multiplication of the ciphertext coefficients. One encrypted product of complex matrices is done with four Gaussian-integer matrix multiplications (eight for ordinary integer matrices). No slot↔coefficient transform, no ring switching, no hundreds of rotations. The only remaining side cost is key-switching, and even that is proven to stay within at most 4× the cost of element-wise (Hadamard) multiplication.

This structure changes the nature of the game. Until now, homomorphic matrix multiplication was a fight over "how few rotations you can get away with." In GL it becomes a fight over "how fast you can do plaintext matrix multiplication." And plaintext matrix multiplication is exactly what decades-optimized libraries like BLAS and FLINT, and GPUs, do best in the world.

---

5. A toolbox for matrices: transpose, rotation, bootstrapping

Matrix algebra is not made of multiplication alone. GL supports a full set of matrix operations at the scheme level.

• Transpose: done with a single automorphism (X, Y)→(Y, X) that swaps the two variables. In conventional schemes, transpose was itself a heavy homomorphic linear transform.
• Conjugate and conjugate transpose: the basic transforms of complex matrices are supported the same way.
• Row rotation and inter-matrix rotation: handled with one ring automorphism and one key-switching.
• Column rotation: needs no key-switching at all. Because the secret key is designed to have no column-direction component, it is done with a mere rearrangement of coefficients. Measured at 0.005 s.
• Addition and Hadamard product: supported just as in conventional schemes, and the key-switching cost of the Hadamard product is essentially the same level as in conventional schemes.

Generalization to integer matrices is natural too. Using BGV-style encoding, you can hold twice as many integer matrices in a ciphertext of the same size. And one practically important point: GL's follow-up work resolves the bottleneck of conventional CKKS bootstrapping to enable faster, more efficient bootstrapping (that follow-up paper was accepted at CRYPTO 2026 alongside the GL Scheme paper), so even deep circuits like a full neural network can be computed continuously without interruption.

---

6. Results: GL by the numbers

These are the paper's implementation results. All figures were measured on a single CPU thread, without a GPU.

How to read this matters. The ciphertext-to-ciphertext matrix multiplication of 7.24 s processes 16 matrices at once, so it works out to about 0.45 s per matrix, of which pure integer matrix multiplication takes 3.04 s. In other words, much of the total time is not a premium added because it is homomorphic encryption but the plaintext matrix multiplication you have to do anyway. Converting key-switching to a per-slot cost, the Hadamard product is about 1.1 µs — the same order as OpenFHE's CKKS slot rotation measured at 0.8 µs under the same modulus conditions — and the matrix multiplication overall is about 3.2 µs. The larger the matrix, the smaller the share of key-switching relative to matrix multiplication, so GL's structural advantage grows with larger matrices.

---

7. Security: why a new scheme is safe

A new scheme does not mean a new security assumption. GL's ciphertext is mathematically equivalent to several RLWE ciphertexts over a standard ring, so its security stands on the same footing as conventional BGV/BFV/CKKS — the hardness of the lattice problem (Ring-LWE). The experimental parameters were set to a 128-bit security level following the community's standard security guidelines. Being lattice-based, resistance against quantum computers is also expected to be at the same level as conventional FHE.

---

8. What GL opens up: fifth-generation homomorphic encryption and Private AI

The history of homomorphic encryption has been a history of expanding the data it can handle. Gentry's first construction (1st generation) opened up the possibility, BGV/BFV (2nd) handled integer vectors, TFHE (3rd) fast logic operations, and CKKS (4th), which came out of Korea, real numbers. GL (5th generation) adds to this the data type of the "matrix" and the operation of "matrix multiplication" as fundamentals of the scheme. Given that computation in the AI era converges on matrices, this is less a mere feature addition than a declaration that homomorphic encryption now takes direct aim at AI computation.

The relationship with THOR becomes clear at this point. THOR innovated in encoding and algorithms on top of the existing fourth-generation scheme (CKKS), bringing encrypted BERT inference down to 10 minutes by the paper's baseline and, through subsequent optimization, to around 2 minutes. This paper, too, reviews existing approaches including THOR and points to the structural limits of optimization on top of vector-based schemes. GL removes those limits by replacing the scheme. From the layer of algorithms to the layer of the scheme, the stage of optimization has moved down a level.

The response has been quick, too. Right after its release, Google's homomorphic-encryption compiler project (HEIR) began examining the GL Scheme, and a follow-up paper on GL-specific bootstrapping optimization appeared as well — the name "GL" is taking hold in the community. DESILO unveiled the GL Scheme at the international homomorphic-encryption conference FHE.org 2026 (Taiwan) and built the world's first commercial software implementation, and DESILO's DESILO FHE library is listed on the official introduction page of the international standardization consortium HomomorphicEncryption.org as a library supporting the CKKS and GL schemes. The next steps the paper proposes — advanced matrix algebra such as matrix inversion and matrix decomposition, and GPU/dedicated-processor acceleration — are all the more promising thanks to the structure in which GL gets faster as plaintext matrix multiplication does.

---

9. Frequently asked questions (FAQ)

Q1. Does it replace existing CKKS or BFV?

They operate at different layers. If conventional schemes are general-purpose tools for "vectors of numbers," GL is a scheme for workloads centered on matrix operations. It has all the fundamentals — addition, Hadamard product, bootstrapping — so it can be used on its own, and because it is compatible with conventional bootstrapping, it is closer to an extension than a replacement.

Q2. Why is it called fifth-generation?

Generational divisions in homomorphic encryption are based on the expansion of "the data and operations it can handle." If the 2nd generation opened up integer vectors, the 3rd fast logic operations, and the 4th real numbers, GL is the next step that supports the matrix data type and the matrix-multiplication operation at the scheme level. The generational flow is covered in Chapter 3 of 「Understanding Fully Homomorphic Encryption (FHE)」.

Q3. How fast is it in practice?

On a single CPU thread, a ciphertext-to-ciphertext product of sixteen 256×256 complex matrices is 7.24 s, about 0.45 s per matrix. More important than the absolute figure is the cost structure. Because most of the time is plaintext matrix multiplication, it structurally absorbs the gains of GPU and dedicated-hardware acceleration as-is.

Q4. What is its relationship to THOR?

The problem is the same; the layer of the solution differs. THOR innovated in algorithms on top of existing CKKS, while GL redesigned the scheme itself. GL is the next card that can wholesale replace the base operations of the encrypted AI inference THOR demonstrated.

Q5. It's a new scheme — can its security be trusted?

There is no new security assumption. GL ciphertext is equivalent to several standard RLWE ciphertexts, so it rests on the same lattice hardness as existing schemes, and the experimental parameters were likewise set to a 128-bit security level per standard guidelines.

---

10. References

1. Craig Gentry, Yongwoo Lee, "Fully Homomorphic Encryption for Matrix Arithmetic," CRYPTO 2026 (IACR Cryptology ePrint Archive, Paper 2025/1935): https://eprint.iacr.org/2025/1935
2. Eric Crockett, Craig Gentry, Hyojun Kim, Yeongmin Lee, Yongwoo Lee, "Efficient Bootstrapping in Fully Homomorphic Encryption for Matrix Arithmetic," CRYPTO 2026 (IACR Cryptology ePrint Archive, Paper 2026/956): https://eprint.iacr.org/2026/956
3. Google HEIR project's GL Scheme investigation issue (google/heir #2408): https://github.com/google/heir/issues/2408
4. Jai Hyun Park, "Ciphertext-ciphertext Matrix Multiplication: Fast for Large Matrices," EUROCRYPT 2025
5. Youngjin Bae et al., "Plaintext-ciphertext Matrix Multiplication and FHE Bootstrapping: Fast and Fused," CRYPTO 2024
6. Jungho Moon et al., "THOR: Secure Transformer Inference with Homomorphic Encryption," ACM CCS 2025
7. DESILO FHE library: https://fhe.desilo.dev/latest/

---

Tech & Insight — The Homomorphic Encryption & Private AI Series (4 parts)

• ① Understanding Fully Homomorphic Encryption (FHE): Computing on Data Without Ever Opening It
• ② Understanding THOR: Running LLM Inference on Ciphertext
• ③ Understanding the GL Scheme: Homomorphic Encryption Redesigned from Scratch for Matrices — current post
• ④ Understanding Private AI: Using AI Without Handing Over Your Data — coming soon

---

Coming up next

The final installment turns to Private AI itself. What does it actually mean to use AI without handing over your data, how do homomorphic encryption, trusted execution environments, and federated learning divide the work between them, and where does the encrypted inference proven by THOR and GL fit inside a product you can deploy? We'll break it down right here on this blog next week.